A hybrid SQL and YAML economy plugin for Axolotl-PM, powered by SimpleSQL.
[!WARNING] Stable v1.1.1 includes a PHP 8.4 nullability correction for bundled libasynql. Stable v1.1.0 introduced confirmed balance callbacks. The beta.2 prerelease PHAR passed a two-client offline protocol test of /pay Target 5: both players received the expected messages, SQLite stored 995 for the sender and 1,005 for the target at revision 2, and /money still returned 995 after a server restart. A headless client also exercised the callbacks through the example consumer: /reward and /fine saved their updates to SQL, and the balance persisted after shutdown. These tests do not cover a live Bedrock game UI or a production MySQL deployment.
---
Storage and API
SimpleEconomy uses SimpleSQL for asynchronous SQL persistence and a YAML mirror. It exposes balance methods and transaction events for other plugins. The synchronous balance API can expose an in-memory change before a database save succeeds. Admin balance commands wait for SQL confirmation before reporting success or updating the leaderboard. If a save fails, they restore the previous session balance when no newer change has intervened; a persistent backend fault can still leave a recovery snapshot that needs operator attention. /pay sends to another online player through a single two-row SQL write; both visible balances and success events change only after SQL confirms it. Use isolated test data while evaluating gameplay and storage behavior.
---
Features
- 6 commands - /money, /pay, /setmoney, /addmoney, /reducemoney, /topmoney. - Name prefix matching - type /money nh and it finds NhanAZ - Offline player support - check and modify balances of players who aren't online - Leaderboard - paginated /topmoney with async cache rebuild - 14 languages - English, Vietnamese, Korean, Russian, Spanish, Ukrainian, Chinese, Indonesian, Turkish, French, Portuguese, German, Japanese, Italian - ScoreHud integration - built-in scoreboard tags, no extra plugin needed - Transaction events - other plugins can listen to, or even cancel, economy transactions - Currency formatting - $1,000,000 (default) or $1.5M (compact) - SQLite & MySQL - switch with one line in config
---
Installation
From GitHub Actions
The build workflow uses DevTools to generate and validate a standalone PHAR when its checks pass. The workflow pins exact tool, dependency and Axolotl-PM source revisions. Its default GitHub run title identifies the triggering commit or pull request.
The same job runs PHPStan at maximum level against pinned Axolotl-PM server source. ScoreHud, SimpleSQL and libasynql source are included for symbol discovery. It also analyzes and builds a pinned SimpleEconomyExample revision, then boots both PHARs with an isolated test plugin to check persistence, paired writes, injected SQL failures and example console commands. The artifact verifier checks the reported SHA-256, plugin and SQL resources, private virion API classes and dependency licenses before upload. See the Actions page for the exact revisions and result of each run.
For isolated evaluation, extract SimpleEconomy.phar from a verified artifact and place it in your test server's plugins/ folder. The PHAR contains the required virions.
The workflow uploads an artifact for 14 days. It does not create a tag or GitHub Release for every commit.
From source
1. Clone this repository 2. Put the SimpleSQL and libasynql source packages directly inside virions/ 3. Follow the DevTools build documentation and the pinned repository workflow to build the project root
The exact CI dependency revisions are pinned in .github/workflows/build.yml, while devtools.yml declares the compatible virion versions.
The pinned libasynql source needs the narrow compatibility patch in .github/patches/ before DevTools can safely shade it. The workflow checks that the patch still matches the pinned revision and fails instead of applying it ambiguously.
When the workflow passes, its artifact includes build-metadata.json with the exact PHAR hash and resolved dependencies. Keep the last known working PHAR and back up player data before replacing it. Rolling back the PHAR does not roll back SQL or YAML data. A successful build and PHPStan run does not establish gameplay or live SQL compatibility.
Upgrading from v1.0.0
Back up the SQL database, YAML mirror and configuration before upgrading. The published v1.0.0 PHAR did not start in a standard Axolotl-PM 5.49.1 runtime because its bundled libasynql attempted to load DEVirion. A controlled test could load the exact PHAR only with a development-only DEVirion PM5 loader and deterministic plugin load order; this does not prove that an unmodified production v1.0.0 installation can upgrade directly.
For a limited storage check, a test database was created with the SQLite schema embedded in that release. A separate YAML document used the revision and data fields written by its SimpleSQL code. The beta PHAR read the seeded balances of 1,234 and 3,456, then persisted 1,240 and 3,460 after admin updates. Those beta.1 SQLite/YAML fixtures do not cover every legacy dataset or MySQL. Keep a data backup and a previously working PHAR for rollback.
The exact v1.0.0 PHAR was also exercised against a synthetic SQLite database made from its embedded schema. With the development loader described above, it read balance 1,234 and saved 1,240; the beta.2 PHAR then read 1,240 and saved 1,250. This verifies that controlled SQLite data path, not a stock-server upgrade, every legacy dataset or production database. The current source also passed a limited MySQL compatibility probe in CI run 38385798697, using an isolated InnoDB database with the exact v1.0.0 table definition and synthetic balance 1,234; it persisted 1,240 at revision 2. That CI job does not establish compatibility with every existing database.
---
Commands
Command Description Permission Default --- --- --- --- /money [player] Check your balance, or someone else's simpleeconomy.command.money Everyone /pay Transfer to another online player after both balances are saved in one SQL statement simpleeconomy.command.pay Everyone /topmoney [page] View the richest players simpleeconomy.command.topmoney Everyone /setmoney Set a player's balance simpleeconomy.command.setmoney OP /addmoney Add money to a player simpleeconomy.command.addmoney OP /reducemoney Remove money from a player simpleeconomy.command.reducemoney OP
Balances are nonnegative integers. Balance commands accept decimal amounts and round them down without converting through a floating-point number. They reject scientific notation and amounts outside PHP's integer range. /setmoney accepts zero; /pay, /addmoney and /reducemoney require an amount greater than zero. Payments also reject self-transfers, insufficient funds and recipient balance overflow.
Tip: Player lookup commands support name prefix matching. For example, /money st can find online player Steve.
Tip: Admin commands (/setmoney, /addmoney, /reducemoney) work on offline players too.
---
Configuration
After first run, edit plugin data/SimpleEconomy/config.yml:
The plugin requires integer values for config-version and default-balance, positive integers for topmoney-per-page and leaderboard-size, a bundled language code, valid currency settings and a database mapping. Invalid values stop startup instead of being silently converted. Back up config.yml and player data before editing storage settings.
Supported Languages
Code Language --- --- eng English vie Tiếng Việt kor 한국어 rus Русский spa Español ukr Українська zho 简体中文 ind Bahasa Indonesia tur Türkçe fra Français por Português deu Deutsch jpn 日本語 ita Italiano
All language files are saved to plugin data/SimpleEconomy/lang/ - you can edit them freely
Versions
Each version is the exact build a moderator reviewed, downloaded from BedrockNexus.
Fix the PHP 8.4 nullable-result compatibility issue in the bundled libasynql adapter. This release is built from commit 3987d6330a92e46ce9921e0a5cb01dce4510a99d; tag workflow run 38551970445 passed PHPStan at maximum level, API 5.0.0 smoke, Axolotl-PM 5.49.1 runtime checks, persistence/example-command checks, and MySQL InnoDB paired-transfer checks. The attached PHAR and metadata are the exact artifact uploaded by that successful tag run; SHA256SUMS.txt covers both files.
