Fee, Burn and Lock Flywheel

What the contracts implement, what the repository records as dormant, and what still needs a separate decision.

1. Implemented transfer fees and burns

InfernoToken._update applies fees only to ordinary transfers where neither side is fee exempt. The default rates are 2% sender burn, 0.5% recipient burn and 1% pool fee: the recipient receives the amount after these deductions. If either side is exempt, these transfer fees do not apply. Fee calculations use integer base units with 9 IFR decimals; rounding can affect very small transfers.

• 2.5% default burn: the token reduces totalSupply through its burn path. These tokens are permanently removed.
• 1% default pool fee: IFR is transferred to poolFeeReceiver. This is a token transfer, not an ETH revenue stream or an automatic burn.
• Governed rates: the combined fee cap is 5%. Defaults are not immutable rates.

Source: InfernoToken; see Fee Design and Tokenomics.

2. Pool-fee routing since proposal #21

Governance proposal #21 executed on 5 October 2026 at 07:25:23 UTC, block 26124660, changing the receiver from FeeRouterV1 to BuybackController. New pool fees accrue there as IFR and are recoverable through the Governance-owned withdrawIFR function. Accruing IFR does not fund the ETH side of a buyback.

FeeRouterV1 has no IFR withdrawal/forwarding function. Its retained IFR was recovered to the Treasury Safe on 7 October 2026 in the separately governed CWA-02 batch (proposals #22/#23 and swapWithFee, block 26143797). The recovery is unallocated Treasury IFR; it is not burned, permanently lost, or an approved reward budget. Direct IFR transfers to FeeRouterV1 remain possible and are not automatically forwarded.

Evidence: deployment/proposal record, pool-fee migration runbook and CWA-02 register.

3. Buyback code exists; the funded cycle is dormant

The retained decision evidence records BuybackController as dormant: no executions and no ETH funding. The FeeRouter voucher/swap path is also dormant (CWA-18). The controller's ability to receive IFR pool fees does not demonstrate an operational ETH-funded cycle.

In BuybackController.execute(), execution requires an unpaused contract, the configured cooldown and minimum ETH balance. Anyone can call once those conditions hold. The code splits ETH:

1. 50%: swap ETH for IFR delivered to BurnReserve.
2. 50%: attempt to add Uniswap V2 liquidity using ETH and IFR held by the controller, with LP tokens sent to its configured receiver.

If there is no IFR for liquidity, or adding liquidity fails, that ETH is redirected to another buyback into BurnReserve. The repository's pool-fee decision explicitly warns that a large IFR balance against little ETH can make the LP attempt fail. The 50/50 code path is conditional, not proof that liquidity is being added.

Receipt is not burning: BuybackController sends purchased IFR to BurnReserve; it does not call BurnReserve.burn. Its totalIFRBurned accounting name does not establish an actual supply reduction. BurnReserve accumulates IFR until its owner or guardian calls burn or burnAll. Only that token burn reduces supply.

The separate BuybackVault has an owner-only executeBuyback() path with activation/cooldown controls and a configurable IFR split between BurnReserve and Treasury. It is not the pool-fee receiver and is not an automatic forwarding step from FeeRouterV1. Its source default split must not be confused with BuybackController's ETH split.

Sources: BuybackController, BuybackVault, BurnReserve and dated dormant-path evidence. Later repository fixes do not by themselves change deployed bytecode; CWA-19 requires review before funding or replacing this path.

4. Access locks and published tiers

IFRLock holds a user's tokens and exposes lockedBalance and isLocked for integrations. Users can unlock their full access-lock balance; pausing new locks does not pause unlock. Locked IFR stays in total supply and is not a burn, a subscription payment or a yield promise. Access depends on the integration and the required lock remaining in place.

The published Benefits tier preset is ifr-benefits-tiers/1, version 1:

These are application/specification tiers, not hardcoded IFRLock contract tiers. Partner benefit rules and the applicable verification specification determine access. CommitmentVault tranches have separate conditions: current interfaces support TIME_ONLY; price-conditioned V1 locks are unsafe and excluded from Benefits eligibility. Permanently locked CV-01 IFR is not burned.

Sources: IFRLock, tier preset, Lock Mechanism and CV-01 evidence.

5. The proposed ecosystem loop and its gates

Builder integrations can make access locks useful; additional users may choose to lock IFR. That is a possible adoption loop, not a contract guarantee that supply falls, price rises or more builders arrive. Refundable locks can also be removed.

• Implemented: fee-bearing transfers burn IFR; eligible integrations can read access locks; new pool fees accrue as recoverable IFR in BuybackController.
• Dormant: the ETH-funded buyback/liquidity cycle and FeeRouter voucher redemption. Funding, execution and actual BurnReserve burns must each be evidenced separately.
• Governance gated: pilot builder/partner activation, budgets and Model B rewards for verified checkout redemptions. No pilot partner is activated and no automatic PartnerVault refill exists.
• Separate future decisions: holder revenue sharing, new treasury allocations and price-lock activation. Documentation does not approve these actions.

Track decisions in the Governance and Product Decision Register, rewards in Model B, and open assurance work in the Open Audit Log. Read the current functionality record for dated operational evidence.