Home › Wiki › Taxes and Contraband

Taxes and Contraband

How faction tax is taken, how the three tax policies work, and what a contraband ban does and does not stop inside a faction's claims.

Where the money is taken

Tax moves coins between pots. It never creates them and it never destroys them: what leaves your side of a transaction arrives in a faction treasury, and the ledger books it as faction income, so a full recount of the money supply still balances. A treasury fed this way is what pays for claims, buffs and upgrades.

Which faction takes the cut depends on the transaction, not on where you happen to be standing. The rule is "your own faction taxes you", and there is exactly one defined exception: the regional shop, where the land and the market belong to the owner.

/pay runs account to account rather than wallet to wallet, so coins sitting loose in your wallet cannot be sent until you deposit them with /bank deposit. The insufficient-funds message quotes the full requirement, and a payment is never made in part. If you want to hand someone money with no tax and no fee at all, use physical cash: withdraw a note and pass the item over.

The three tax policies

Every faction runs exactly one of three policies. The Owner chooses it, everyone else lives under it, and any member can read what it currently is.

What a progressive schedule actually costs

Brackets are marginal. Each band of a payout is taxed at its own rate; the whole payout does not jump to the top rate the moment it crosses a threshold. The fair default schedule is 0% up to 2,000, then 5%, then 12% from 8,000, then 18% from 25,000.

On a 10,000 payout that is nothing on the first 2,000, 5% of the next 6,000 and 12% of the last 2,000: 540 coins, an effective 5.4%. The same schedule on 30,000 takes 3,240, an effective 10.8%. The effective average is then clamped against the safety ceiling, so a schedule steep enough to be absurd still cannot over-tax you.

The presets

Five named presets replace the current policy wholesale, running from the lightest touch to a steeply progressive schedule: LAISSEZ_FAIRE, MINIMAL, STANDARD, PROGRESSIVE_FAIR and PROGRESSIVE_STEEP. The preset screen in the tax GUI shows eight cards: those five, plus three that seed a whole Rules set instead of a rate, for a wealth tax, a luxury tax and a wartime schedule. The shipped wealth-tax card charges 3% of whatever a payer's net worth exceeds 200,000.

Switching to Rules is not a free swap

Rules is a different tax world, and the difference is worth knowing before an Owner opts in. The faction tax-reduction buff, which discounts Flat and Progressive income tax, is not applied under Rules: the rules are the whole authority. The safety ceiling is the Rules ceiling rather than the Flat one.

Because of that, merely opening the rule list on a Flat or Progressive faction shows a preview of the equivalent rule set that is never saved. The conversion is written to disk only when the Owner makes a genuine edit, so browsing can never quietly change what your faction charges you.

Anatomy of a rule

A Rules policy is an ordered list. Each rule pairs a condition, which says when it applies, with an amount, which says what it takes. A handful of switches decide how it sits among the others.

What the five actions do

Destination is modelled, saved and printed, but the coins credit the actor's own treasury today. Cross-faction tariffs and regional stacking are not wired to a money move yet, so REDIRECT to another faction is a line on the receipt rather than a transfer. Read it as a plan, not a payment.

When every rule has run, the total is clamped against the original transaction amount rather than against whatever a DEDUCT left of it. That is the difference between a ceiling that holds and one a clever rule order can walk around.

What a condition can read

Conditions read a snapshot of the transaction and the person making it: the amount, the transaction type, the actor's faction rank, their wallet, bank balance and net worth, the job, region and world, the item and its category, and the faction's economic metrics such as inflation, purchasing power, stability and growth. The economic metrics return neutral values until the economic simulation is armed, so a rule keyed on inflation sits dormant rather than misfiring.

An unknown variable name resolves to 0 or to an empty string. A typo therefore never crashes a rule; it produces a rule that quietly never matches, which is exactly what the simulator is for.

The formula sandbox, and what happens when a rule breaks

An amount can be a plain rate, a fixed fee, or an expression. Expressions support +, -, *, / and %, plus the functions min, max, clamp, floor, ceil and abs. Division and modulo by zero return 0 rather than throwing, so a rule that divides by a metric which happens to be zero yields nothing instead of breaking the payout.

The parser is deliberately small, and it is hard-limited in three ways before your expression is ever evaluated. Conditions are parsed under the same caps.

Every one of those turns a pathological input into a reported parse error. That is the whole point of counting nodes during the parse: an over-long source is refused while it is being read, not after it has already been turned into a structure too large to walk.

A broken rule takes only itself down

A rule tracks its amount error and its condition error separately. If either half fails to compile, that single rule switches itself off and the error is echoed back to whoever typed it. Nothing else in the set is disturbed, and the remaining rules keep collecting normally. The same isolation applies when a saved rule set is loaded again: a rule that no longer compiles comes back disabled and visible rather than silently dropped, so it can be read and repaired instead of vanishing.

Two syntax traps worth knowing

Commas are argument separators inside an expression, so grouping commas corrupt a condition. Write amount > 5000, never amount > 5,000. Everything the GUI writes for you is already comma-free, and the grouping commas you see on a card are display only.

List conditions accept both shapes: item IN (a, b) and item IN [a, b]. Only the square form used to parse, and a player who reached for the natural parentheses got a set containing the literal bracket character, which compiled cleanly and then never matched anything. A mismatched closer such as IN [a, b) is now a reported parse error rather than a rule that swallows the rest of your condition.

The simulator and the commands that explain the policy

The simulator answers one question: what would this rule set actually charge? It runs a transaction through the same evaluation the real charge runs, prints every rule that fired with its share, and gives the effective rate at the end. No money moves and nothing is saved.

In the GUI, the simulator screen lets you cycle the transaction type, step the amount, and optionally cycle an item through the palette. In chat, /faction tax test does the same for Elder and above, which means a faction's officers can audit a policy they cannot change.

The warning that matters most

If you select an item against a transaction type that carries no item in play, the preview card adds a warning saying so. Without it, the simulator would happily render a plausible 30% hit for a job payout on a Cannabis Bud, and an Owner would build a rule against revenue the engine can never collect. The warning is display only. It does not touch the maths, so what the card shows and what the engine would do still agree exactly.

A second honesty note, from the same principle: a couple of transaction types are selectable in the editor and can never match, because the money routes behind them pass no evaluation context at all. Salary and company profit are the two.

Who can do what

/faction tax explain is answered before the command even looks up your faction. The person most in need of "what is faction tax?" is often someone deciding whether to join one at all, and they would otherwise be told they are not in a faction. The GUI is left-click only throughout, and there is no typed input anywhere in it, so Bedrock players drive every control.

Taxing a single good, and the eight categories

A rule can name a specific good. That is how a faction puts a luxury or vice rate on one product without touching everything else it taxes.

Items are identified by one key space shared with contraband. A Blacklight custom resolves to its registry id, such as bl_cannabis_bud; anything vanilla resolves to its namespaced key, such as minecraft:diamond. Keys are lower-cased and independent of stack size, so one bud and a stack of sixty-four carry the same key. A null or empty hand resolves to an empty key, which matches no rule and no ban, which is the correct answer for "no item was involved".

Three condition shapes are available. item == bl_cannabis_bud for one good, item IN (a, b) for several, and item_category == HERB for a whole bucket. In the GUI you never type any of them: Conditions, then Match a specific item, then click the goods you want and apply.

Herbs are matched on the key before any other check, which is why the cannabis bud does not fall through into FOOD despite being built on an edible base item. The picker and the live tax path run through the same classifier, so an item_category rule matches exactly the set you saw when you built it.

The catalogue you pick from lists the herb chain first, then every registered Blacklight custom, then around 45 curated vanilla staples. It is curated on purpose: a full material list would be over a thousand entries in a 28-cell grid, and most of them are never traded. The tax item picker and the contraband editor read that one catalogue in the same order, so you can never tax something you cannot ban, or ban something you cannot tax.

Contraband: prohibition without confiscation

A faction can outlaw a good inside its own claims. This is not a tax and no coins move: it is a refusal. On that faction's land the banned item cannot be used in the ways below, and outside that land it is an ordinary item again.

Nothing is ever confiscated and no money moves anywhere in the feature. Taking items off a player for walking across a border would be trivially weaponised, since a faction could ban a common item and farm travellers, so prohibition here is refusal only.

A ban applies to everyone on that land, including the banning faction's own members, who are the people who wrote the law, and including staff. There is no bypass anywhere in the three enforcement points. Staff who need to work around a ban lift it rather than ignore it.

Holding contraband never blocks a block. Chests, doors and furnaces open normally while a banned item sits in your hand. A ban targets what you do with an item, not what you carry, and right-clicking an interactable block with a banned snack opens the block rather than emitting a refusal for something you never attempted.

A retroactive ban freezes rather than deletes. Listings created before the ban stop trading instead of quietly continuing, and the items stay where they are.

Reading and editing the ban list

Any member can read their faction's contraband list from the faction hub, and the overview book shows it too. Everyone should be able to read the law they live under. Editing is Mod and above, tied to the same authority as kicking, which makes the faction's enforcement staff its legislature.

The editor sorts banned entries first so the current law is always on page one, and a ban on an item that is no longer in the shared catalogue still renders, so it can always be lifted. Staff can switch enforcement off across the whole server; if they do, the ban lists survive untouched and only enforcement stops.

Ceilings, receipts and the audit

Four promises hold across the whole system, and they are worth reading as a member rather than as an Owner.

The price you are shown is the price you are charged. Tax is always inside the number on the label. Under a Rules policy the rate can depend on who is buying, so the shop label is quoted through the same evaluation and the same context the charge will use. The receipt then echoes the amount actually withdrawn rather than re-quoting afterwards, because a second quote would read a wallet that has already been debited.

Every policy has a ceiling.

Tax is named at every payout. Every player-earned coin runs through one funnel with a declared taxable decision per source, so there is no untaxed side door and no bespoke tax hiding in a corner. Twenty-eight payout sites bind their result and eleven files render the receipt through one renderer. An untaxed payout prints "no tax" rather than a zero, which keeps "untaxed" readable as different from "not disclosed".

A privacy call sits inside that: your faction's cut of your payout is your income tax, and under a Rules policy the rate is derivable from it. So server-wide and faction-wide announcements keep the headline figure and the tax clause goes only to the earner.

Income and consumption are taxed differently. The faction tax-reduction buff applies only to income: job pay, sales, expedition and bounty rewards, savings interest and dividends. Consumption and fees pay the un-reduced rate. That split is also what keeps a shelf price identical for every viewer, since two members with the same faction but different buffs still see the same number on the same item, even though their income tax differs.