Progressive income tax on player income

Goal

Tax what players earn at progressive, marginal rates, as requested by the DemocracyCraft Department of Commerce and Congress. Today Treasury taxes wealth (the weekly balance tax) and, optionally, Vault deposits at a flat per-plugin rate (tax.source-income-tax, disabled on DC). There is no tax that rises with how much a player earns.

What the tax should do

• Marginal brackets: each rate applies only to the slice of income between its floor and the next floor. Crossing a floor must never raise the tax on income already earned.
• Per period: income adds up over a configurable accounting period (e.g. 30 days) and resets for everyone at the same moment.
• Collected as income arrives, not as one bill at the end of the period, so players are never handed a bill they can't pay. The per-payment amounts for a period must add up to the tax on that period's total income.
• Configurable exemptions: source accounts (e.g. starting-balances, Eco admin adjustments), plugins, and switches for player-to-player payments and ChestShop proceeds. ChestShop already has a sales tax, so its proceeds are probably exempt by default.
• Off by default, tunable and validated on /treasury reload.

What counts as income (must be covered)

Every route by which money reaches a player, not just one code path. Measured on prod over 2026-09-17 → 10-17, players received about $197M:

• Business → player through treasury-rest-api: ~$54M (27%). The REST API has its own transfer engine (TransferService), separate from the plugin's LedgerServiceImpl, so a tax hooked into only one engine misses this.
• Firm → its own founder: ~$45M (23%). A firm account's owner_uuid is whoever created it, so treating "moves between accounts the player owns" as non-income exempts owners taking money out of their own firm. Decide explicitly how firm withdrawals and owner draws are treated.
• Salaries, government payouts, /pay (now tagged Treasury-Pay, PAR-145) and Vault deposits from other plugins (e.g. Essentials, PostmanPat, BountyHunters).

Constraints

• Must not put payments at risk. The ledger stays deadlock-free by locking accounts in ascending account_id order (LedgerServiceImpl.transferInternal). Collecting the tax must not break that ordering, add a server-wide hot lock on the government account, or make a payment fail because the tax step failed. Cover payments running at the same time with an integration test.
• No replayed payment is taxed twice.
• No chat message per taxed payment: add the type to EconomyNotifierImpl.SILENT_TAX_TYPES or summarise per period. Notifications and tax-cycle stats fire only after commit.

Open policy questions (for Commerce/Congress)

• Does this replace tax.source-income-tax or sit alongside it? Two income taxes with different rules is confusing, so prefer one.
• Should firm owner draws count as income, or should firm profits be taxed separately?
• Bracket floors, rates and period length. For scale: with floors of 5k at 3% and 20k at 5% per 30 days, the measured month gives about 3.5k earners (665 over $5k, 412 over $20k) and roughly $4.8M of tax, even before closing the two gaps above.
• Should the period follow calendar months or a fixed length?

Visibility

Players and admins can see the brackets, the period and when it resets, and a player can see their own income and the tax paid so far this period: /tax, TaxApi, the published economy config (PAR-80) → REST TaxConfigResponse → explorer taxation page (PAR-92).

Acceptance

• Taxes income at marginal rates per period across both transfer engines, with the exemptions above configurable.
• Firm owner draws are handled per the policy decision.
• No deadlock or payment failure introduced: there is a concurrent-payment IT.
• Visible in /tax, the REST API and the explorer. Admin config docs updated.

Related: PR #51 (a proposed implementation from a community contributor).