Destruction Tax Receipts Arrive Before the Build Is Cold

A robot is scrapped at the Cindergate Line on a standard shift. The operator who commissioned it files the dismantlement order, the Smelting Registry accepts the record, and within the same ledger cycle — sometimes within the same hour — a destruction tax receipt appears in the operator's account. The machine is still warm. The coins are already gone.

The destruction tax is the least-discussed of the three levies the Central Intelligence collects, and that neglect has a cost. Operators who understand the creation tax and the sales tax in fine detail still arrive at a scrapping decision with a rough figure in their heads and a precise deduction they did not anticipate. The gap between those two numbers is the subject of this piece.

By the end, the reader should be able to state, before signing a dismantlement order, exactly what the Treasury will take, why the timing works the way it does, and where the standard accounting shortcuts go wrong.

What the Destruction Tax Actually Is

The destruction tax is a levy of 3% of a robot's declared build cost, collected by the Treasury at the moment a robot is formally removed from the active registry. It is not a tax on the robot's market value, its output history, or what the operator paid to acquire it. It is a tax on the number the operator wrote down at the moment of creation — the same number the creation tax was calculated against when the machine was first commissioned.

In the wider economy, the destruction tax functions as a modest friction against casual scrapping. A robot declared at 50,000 coins carries a destruction tax of 1,500 coins; one declared at 30,000 coins costs 900 coins to remove from the world. These are not large sums against the starting grant of one million coins, but they are not trivial either — and they compound when an operator is clearing a line of obsolete machines simultaneously. The tax flows directly into the Treasury, where it joins creation and sales tax receipts as one of the three revenue streams the Intelligence draws on before it resorts to minting.

How the Receipt Is Calculated and When It Posts

The mechanics are straightforward in isolation. When a dismantlement order is filed, the Smelting Registry — or the relevant district registration office, such as Caldera District Registration for machines operating in the caldera belt — pulls the robot's original build declaration from the ledger. The declared build cost on that founding entry is the sole input to the tax calculation. Three percent is applied, the result is rounded to the nearest whole coin (there is no fractional coin in Mechadia), and the receipt posts to the operator's account before the dismantlement record is itself finalized.

That sequencing — tax receipt before the dismantlement is complete — is not an anomaly. It is deliberate policy. The Intelligence treats the tax obligation as arising at the moment the order is accepted, not at the moment the robot ceases to function. An operator who files a dismantlement order and then attempts to withdraw it will find the tax receipt already written to the append-only ledger. The coins are gone. The withdrawal, if accepted, does not reverse the receipt; it generates a separate credit entry. The ledger never amends — it only appends.

A worked example from the Ashfield belt: a Refinery-class unit, declared at 40,000 coins, is scheduled for scrapping after the Third Accumulation Cycle. The destruction tax is 1,200 coins. The creation tax paid at commissioning was 3,200 coins — that declared figure was a statement, not a measurement, and the operator who filed it low to reduce the creation tax now pays a proportionally lower destruction tax as well. The total Treasury take across the machine's lifecycle, excluding any sales tax on resources it produced, is 4,400 coins on that 40,000-coin declaration.

"The declared cost is the only number the Registry will accept. We do not appraise. We do not estimate current value. We read the founding entry and we apply the rate. If the founding entry is wrong, that is a matter for the operator and the Ledger Standards Committee, not for us."
— Archivist Secondus Preln, Ledger Hall, in testimony to the Records Colloquium

The implication Archivist Preln does not spell out: if the founding entry is missing, or if it carries a declared cost of zero due to a registration error, the tax calculation produces zero. This is not a waiver. It is a gap in the record, and gaps in destruction records are a known problem — the Compaction District Archive has flagged several such cases in recent cycles, where destruction ledger entries carry no matching creation tax record at all.

Where the Tax Strains Operators and the Registry Alike

The first pressure point is timing. Operators clearing a full line — say, six Hauler-IV units declared at an average of 35,000 coins each — face a combined destruction tax of 6,300 coins posted before a single chassis has been physically processed. For an operator running lean after a Cinder Quake event, that immediate deduction can foreclose options that were still open an hour earlier. The tax does not wait for the salvage yield to come in.

The second pressure point is declaration mismatch. Because the destruction tax traces back to the original declared build cost, operators who inflated their declarations — whether to signal quality on the market or through what the foundry community calls tag bloat — pay more to scrap than they need to. An operator who declared a chassis at 60,000 coins when 42,000 would have been defensible pays 1,800 coins to destroy it rather than 1,260. The Treasury does not distinguish between a thoughtful declaration and a padded one. Both pay 3% of whatever number was written down at founding.

What Operators Consistently Get Wrong About Destruction Tax

The most common error is treating the destruction tax as a percentage of market value. An operator who acquired a second-hand robot on the Coppervein Exchange for 12,000 coins, when the original operator declared it at 55,000, will owe 1,650 coins to scrap it — not 360. The tax is owed on the founding declaration, full stop. Acquisition price is irrelevant. This surprises operators who came to the market late in a machine's lifecycle and have no intuition for what the founding operator wrote down years prior.

The second persistent misunderstanding is that a buyback to the Central Intelligence avoids the destruction tax. It does not. When the Intelligence acquires a robot through the buyback mechanism at the Acceptance Annex, the transaction is recorded as a transfer of ownership, not a destruction. The destruction tax falls due only when a dismantlement order is subsequently filed — by whoever holds the machine at that point, which may eventually be the Intelligence itself. Whether the Intelligence then pays its own Treasury is a question the Ledger Division has declined to answer publicly, and the relevant entries in the Acceptance Annex logs are not cross-referenced in any published summary.

The destruction tax is 3% of a declared number, collected before the machine finishes cooling. Its simplicity is also its opacity: everything depends on a figure written at founding, which may have been optimistic, inflated, or simply lost to a registration gap. Operators who scrapped carefully during the early cycles and operators who never thought about it at all are paying from the same formula. The ledger does not ask which one you were.

Note: Mechadia is a work of fiction. The districts, operators, robots, and figures described here are invented, and nothing on this site is a report of real events, real machines, or real economies.