Redemption

There are exactly two paths from the token to machine work. This page specifies both, their limits, and, just as carefully, what the contracts do and do not guarantee.

Path 1: the drip (holding)#

Once per weekly epoch, a pool of Workbench credits is distributed to holders.

• Pool size: alpha(g) * that epoch's inflows, with alpha(g) = 0.25 * g^2, where g is the coverage gap defined in The Numbers. At most 25% of inflows, throttled quadratically when backing is below target.
• Funding: inflows of the current epoch only, never the reserve balance. Zero inflows means zero drip. This is the property that makes the drip incapable of reducing backing.
• Eligibility: a time-weighted average balance (TWAB) of at least 1,000,000 tokens across the epoch. Borrowing tokens for a snapshot does nothing against a time-weighted average.
• Distribution: strictly pro rata by TWAB. Splitting a position across wallets changes nothing; the threshold only filters dust.
• Expiry: unclaimed drip expires after 180 days and returns to the reserve. This bounds the liability. The reference project we studied has no expiry, and its drip liability can grow without limit.
• Gaming, with arithmetic instead of adjectives: wash-trading to farm the drip is structurally unprofitable. A wash trader pays a 3.35% fee on volume; at most 0.50% of that volume reaches the drip pool even at the most favorable parameter setting (25% of the reserve's 2.00% share), of which the trader receives only their supply share. Breaking even would require holding roughly 6.7 times the total supply. The higher fee rate made this attack strictly worse, not better.

The drip is operator policy, executed weekly against a published formula, and it is revocable policy. It is not a contract-enforced entitlement, and this page will not pretend otherwise. It is also the single largest legal exposure in the design; see Risks.

Path 2: burn-to-runtime (redeeming)#

Burning converts tokens into Workbench credits at a published rate.

Mechanics. The BurnRedeemer contract exposes one user-facing function. burn(amount) moves the tokens in a single atomic transaction from the caller directly to the dead address 0x000000000000000000000000000000000000dEaD and records an on-chain claim: claims[caller] += actually burned. The claim exists in the contract, independent of our database and of us. There is no "transfer first, paste your transaction hash" path; a claim can only come into existence together with its burn.

Valuation. Credits are computed from the claim as:

credits [USD] = rho(g) * b * burned tokens / 10,000,000

rho(g) = 0.85 + 0.13 * g        (a haircut of 15% when underfunded,
                                 down to 2% at target coverage)
b      = net backing per 10M tokens at burn time

The credited value is displayed in Runtime Minutes first; the dollar figure is the labelled basis. Because rho <= 1, every burn leaves the remaining holders with equal or higher backing per token. The arithmetic is in The Numbers.

Rate limits.

• Per wallet: $200 of credit issuance per day.
• Global: the larger of $500 or 1% of the net reserve per day.

At the global cap, a sustained full-scale run cannot drain the reserve faster than roughly 100 days, and every burn along the way raises the per-token backing of whoever remains. One published exception: if a single claim exceeds the daily wallet cap, the first credit of a cap day may overshoot once, bounded by that one claim, with strict first-in-first-out ordering per wallet. Splitting one claim into many partial credits would weaken the exactly-once accounting that the whole system is built around, so the cap bends for a single claim rather than the correctness guarantee bending for the cap.

Credits. Credits belong to the burning wallet. They are non-transferable, cannot be paid out in money, and do not expire. The burner destroyed supply; the credit does not time out on them.

No cash-out, as a system invariant#

The reserve owes work, never money. This is not a temporary limitation but a load-bearing invariant: it removes the bank-run mechanic (there is nothing to run on that pays cash), it is the structural boundary against e-money and deposit-taking classifications, and it is why the redemption value is a usage value, not a price floor. If nobody wants machine work, the redemption value binds nothing. We say that here and again in Risks, because a reader who finds it out on their own has every right to ask why we did not say it first.

What the contract guarantees#

Proven by the published invariant test suite, and checkable by anyone once deployed:

• Burns are real and atomic: every claimed token is actually at the dead address.
• Claims are append-only and exist independently of our backend.
• Claim ids are dense and strictly sequential, which makes double-crediting detectable and recoverable by any indexer, including one we do not run.
• The contract has no owner, no admin, no pause switch, no upgrade path. There is nothing we can change and nothing we can take.

What the contract does not guarantee#

Stated here so nobody discovers it later:

1. Valuation is off-chain in v0. The contract records what was burned, never what it is worth. The credit formula above is published policy, reproducible from the open stats endpoint, but it is computed by us. A documented hardening path anchors the weekly valuation parameters on-chain in a separate attestation contract; until that ships, treat valuation as policy.
2. The caps are backend policy. The contract deliberately has no cap: an on-chain cap could not enforce the real limit (which depends on off-chain quantities) and would hand griefers a way to block legitimate burners. Whoever burns more in a day than the caps credit promptly still holds their full on-chain claim; only the crediting pace is policy.
3. v0 is not trustless. Reserve custody, credit servicing, the drip, and the weekly controller run off-chain with us. The claim registry is the part that is trustless. Anyone who tells you the whole system is decentralized in v0 is lying, so we do not.

One warning that belongs in bold#

Never transfer tokens directly to the BurnRedeemer contract or to the dead address expecting credit. A direct transfer destroys tokens without creating a claim. The contract's sweepStranded() function forwards mistakenly sent tokens to the dead address, permissionlessly and without credit, because silently stranded tokens would overstate circulating supply. The only path that credits is approve plus burn() through the Workbench flow, which is why the redemption screen never shows a copyable address and never asks for a transaction hash.