aere-research/research/specs/spec-flywheel-economics.md

AERE Token-Economic Mechanisms: Burn, Sink Flywheel, and Staking

Subsystem specification. AERE Network mainnet, Chain ID 2800 (Hyperledger Besu QBFT, 0.5-second blocks). Source of truth for addresses: aerenew/sdk-js/src/addresses.ts. Source of truth for logic: aerenew/contracts/contracts/. Solidity 0.8.23, OpenZeppelin 4.9.6.

Scope and honesty preface

This document specifies the on-chain money mechanisms that make AERE deflationary and that pay stakers:

1. The validator-coinbase burn split (AereCoinbaseSplitter and its V2 successor).
2. The permanent burn endpoint (AereFeeBurnVault).
3. The immutable three-bucket revenue router (AereSink), configured 15/40/45 across BURN, BUYBACK, and STAKER-YIELD.
4. The liquid-staking receipt token (sAERE, ERC-4626).
5. The staking-reward products: delegated validator staking (AereStakingV2, 8% default APR) and fixed-term locked staking (AereLockedStaking, 10 to 30% APY).

Read the following honestly before the mechanism detail:

• Fixed supply, no new issuance. Total supply is capped at 2,800,000,000 AERE at genesis-v2 (2026-05-07). None of the mechanisms below mint tokens. Staking rewards are paid out of pre-allocated genesis reserves that the Foundation seeds into each reward pool, not out of adaptive inflation. This is a deliberate design choice, not an oversight.
• The APRs are a reserve-funded subsidy, not perpetual issuance. Because supply is fixed, the 8% delegated APR and the 10 to 30% locked APYs are finite: they draw down a Foundation-seeded reserve. They are sustainable only as long as that reserve funds them, or, in the long run, as far as real protocol-fee revenue routed through AereSink replaces the subsidy. The intended end-state is that the fee flywheel, not the reserve, pays stakers.
• Realized throughput is thin. The chain runs with seven validators under one operator, one client, and no external audit. Burn and yield volume to date depend on validators actually running the coinbase-forwarder daemon and on real fee flow. This spec states parameters and formulas that are verifiable from source. It does not quote lifetime-burned, TVL, or yield figures; those are to be read live from the contracts' on-chain counters.
• The base-fee framing is precise. AERE's QBFT chain does not run EIP-1559 protocol-level base-fee burning. The "37.5% burn" is applied to validator coinbase rewards by a splitter contract that validators call, operationalizing whitepaper section 3.3 at the coinbase layer rather than in consensus. Where this matters it is stated inline.

Native AERE is the gas and value token. WAERE (0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8) is the ERC-20 wrapper, minted 1:1 by depositing native AERE (WETH9 design). Every ERC-20-facing mechanism below (the sink, sAERE) operates on WAERE; the splitter wraps native AERE into WAERE before routing it to the sink.

1. Fixed-supply foundation

Genesis-v2 allocations (from the registry header, chain 2800):

Allocation	Amount	Address
Strategic Investor (sold off-chain)	100M	0xaee2f3989f0AB23296Fa3b92247fe67587141311
Foundation (chain admin / contract owner)	180M	0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3
Mining Reserve	1.4B	0x038f59A40ceeCd599A4588E4B0ff4642a0fbfFB8
Ecosystem Reserve	560M	0xB6a364F47d21DC2CbEB803565c111c1026e11C75
Team Reserve	420M	0x7968C438204a78B4e032fcFFd9A56Edb15fdCCdf
Airdrop Reserve	140M	0x261913fA73D6F109382F1aE98Ff6822ff03628B1

Total 2,800,000,000 AERE, capped. Every Ownable contract in this spec is owned by the Foundation account 0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3 (a single-key Foundation-controlled account, not a deployed multisig). The economic thesis is monotone: the burn path only ever removes AERE from circulation against this fixed cap, and no path re-mints.

2. The validator-coinbase burn split

2.1 V1: AereCoinbaseSplitter

Address: 0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec (owner = Foundation). Source: AereCoinbaseSplitter.sol.

A validator (or its forwarder daemon) calls splitAndDistribute(validator) or splitToSelf() with accumulated coinbase as msg.value. The contract atomically:

1. Sends burnBps / 10000 of msg.value to AereFeeBurnVault.
2. Sends the remainder back to the validator address.
3. Increments cumulative counters (totalBurned, totalDistributed, and per-caller maps) and emits Burned / Distributed.

Parameters:

• burnBps = 3750 (37.5%), matching whitepaper section 3.3.
• Owner-adjustable via setBurnBps, hard-capped at 5000 (50%). The whitepaper wording is "up to 37.5%"; the 50% cap gives headroom while bounding abuse.
• burnVault is owner-settable (setBurnVault, non-zero required).

The contract is ReentrancyGuard-protected and cannot custody funds across calls: every call fully dispatches msg.value. Anyone can call it (no burn allowlist), which is what lets a public explorer verify the deflation claim in O(1) reads from burnStats().

Note on the word "sealed": the burn rate is not immutable. It is owner-adjustable inside [0, 5000] bps. The truly sealed component of the token economy is AereSink (section 4), which has no owner at all.

2.2 V2: AereCoinbaseSplitterV2

Address: 0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4 (owner = Foundation). Source: AereCoinbaseSplitterV2.sol.

V2 replaces the two-way split with a three-way split that adds the sink bucket, so a slice of every validator reward feeds the sAERE flywheel instead of returning entirely to the validator.

Buckets (basis points, owner-configurable within hard caps):

Bucket	Default	Cap	Destination
burnBps	3750 (37.5%)	MAX_BURN_BPS = 5000	AereFeeBurnVault
sinkBps	1500 (15.0%)	MAX_SINK_BPS = 3000	AereSink (via WAERE)
rebateBps (derived)	4750 (47.5%)	10000 - burn - sink	validator

setBps(_burnBps, _sinkBps) enforces both caps and burn + sink <= 10000; rebateBps is a live-derived view. The sink share is routed by wrapping the native slice into WAERE (IWAERE.deposit), approving the sink, and calling IAereSink.flush(WAERE, sinkAmt) in the same transaction. If the sink call reverts, the whole split reverts and the validator retries.

Sink-rotation safety: the sink address is owner-settable but rate-limited. proposeSink starts a SINK_CHANGE_TIMELOCK = 7 days timer; acceptSink can only fire after it elapses; cancelPendingSink aborts. This gives validators seven days of warning before any sink swap.

Important operational caveat, stated honestly: the V2 constructor leaves sink unset. Until proposeSink + acceptSink wire a live sink, V2 behaves like V1 (the 15% sink slice is folded into the rebate, sinkAmt = 0). This spec documents the configured three-way design; whether the live V2 currently has its sink accepted and pointed at AereSink 0x69581B86A48161b067Ff4E01544780625B231676 is a Foundation operational state to confirm on-chain, not an invariant of the code. Validators migrate from V1 to V2 by repointing their off-chain forwarder daemon; V1 stays deployed and continues to honor V1 burn behavior for any flow still hitting it.

2.3 Deflation math (V2 default, worked)

For a validator coinbase reward R under the V2 defaults and the sink's 15/40/45 configuration (section 4):

• Direct burn: 0.375 R.
• Sink input: 0.15 R. Inside the sink, BURN (15%) plus BUYBACK (40%) are both AERE-destroying, so 0.55 x 0.15 R = 0.0825 R is burned, and STAKER-YIELD (45%) sends 0.45 x 0.15 R = 0.0675 R to sAERE holders.
• Rebate to validator: 0.475 R.

Aggregating:

• Total burned: 0.4575 R (45.75%).
• Total to stakers (sAERE): 0.0675 R (6.75%).
• Rebated to validator: 0.475 R (47.5%).
• Protocol-directed (not rebated): 52.5%.

The "~52.5% net deflation" figure in the V2 source comment counts the entire sink slice as protocol-directed. The stricter, more honest number for actual token destruction is 45.75%, because 6.75% of the reward becomes staker yield rather than being burned. Both are stated so a reader can pick the definition they mean.

All of the above are default and design parameters. burnBps, sinkBps, and the sink's internal split determine the real numbers; the sink split is a deploy-time immutable (section 4).

3. The burn endpoint: AereFeeBurnVault

Address: 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6. Source: AereFeeBurnVault.sol. No owner, no admin.

A stateless sink with no withdraw function and no admin escape hatch. Native AERE arrives via receive() or burn(); ERC-20s arrive via burnToken(token, amount) (pull-via-approval). Counters totalBurnedAERE and totalBurnedToken[token] make deflation queryable in a single read.

Honesty on "obliteration": AERE that enters this vault is permanently removed from circulation because nothing can move it out. It is not literally sent to address(0) until someone calls the permissionless sweepToZero(), which forwards the whole native balance to address(0) (Besu QBFT permits this) and increments totalSentToZero. So there are two honest ways to describe the state: "removed from circulation on a no-withdraw contract" (always true on arrival) and "obliterated to the zero address" (true after sweepToZero). Both counters are exposed. ERC-20 burns stay on the contract forever (no zero-sweep for tokens).

4. The immutable flywheel: AereSink

Address: 0x69581B86A48161b067Ff4E01544780625B231676. Source: sink/AereSink.sol. No owner, no admin, no setters, no pause, no upgrade proxy.

AereSink is the single entry point for any protocol fee stream that should accrue to AERE holders. It splits every inflow across three buckets whose recipients and basis points are set once at deploy and are immutable thereafter. The constructor reverts unless BURN_BPS + BUYBACK_BPS + STAKER_YIELD_BPS == 10000.

Registry-documented deployed configuration: 15 / 40 / 45 (BURN / BUYBACK / STAKER-YIELD). Because these are constructor-set immutables, the specific values are not re-derivable from the source alone; the 15/40/45 figure is the canonical deployed split per the registry and the locked architecture design, and the code guarantees only that they sum to 10000 and can never change.

Buckets:

1. BURN (15%): transferred to AereFeeBurnVault on top of the splitter's 37.5%.
2. BUYBACK-and-burn (40%): non-AERE inflows are swapped to AERE via the DEX router, then sent to the burn vault. When the inflow is already AERE/WAERE (the normal case, since the splitter wraps before flushing), BURN and BUYBACK are merged into a single transfer to the burn vault, because buying AERE with AERE is a no-op.
3. STAKER-YIELD (45%): transferred (or swapped) into the sAERE vault. A raw transfer into an ERC-4626 vault lifts totalAssets without minting shares, so the exchange rate appreciates for all sAERE holders. This is the flywheel's connection from fees to stakers.

Entry point: flush(token, amount). The caller approves the sink, then the sink pulls via transferFrom, computes the three parts (the staker part absorbs rounding residue so no dust accumulates on AERE inflows), and dispatches. After crediting the staker bucket it calls sAERE.sync() (best-effort) so the vault immediately begins linearly dripping the arrival rather than leaving a step-function price jump for a sandwicher to race.

Sandwich resistance on swaps: for non-AERE inflows, amountOutMin is computed from an external oracle price floor (_computeOracleFloor) rather than from the DEX pool reserves, because pool reserves can be manipulated by the same actor in one transaction. The oracle interface is compatible with AereLendingOracle.getPrice (AereLendingOracle at 0xc0f18A567067F1B84BDf75eDEbFaDdCBb70A4C49), normalized to 18 decimals, with an immutable MAX_SLIPPAGE_BPS tolerance. If the oracle is unset or reverts, the swap floor falls back to 1 (accept any non-zero output). The DEX router is the AERE V2-style AereSwapRouter (0x7526B2E5526EfA84018378b60F2844Dad77523D8).

Failure isolation: a failed swap (dead pair, slippage) does not revert the whole flush. The tokens stay as dust, a SwapFailed event fires, and the approval is cleared. Anyone can later call the permissionless sweepDust(token) to re-flush accumulated dust through the same three buckets. flush and sweepDust are both nonReentrant.

Immutability is the point. There is no setBucket, no setRecipient, no setRouter. If the router ever needs replacing, the sink is redeployed and fee sources are rewired. The absence of any admin key is the credibility anchor of the whole flywheel: holders can verify that the 15/40/45 split and the recipients cannot be changed under them.

Honest note on non-18-decimal tokens: the oracle floor math assumes 18-decimal tokens on both sides. A non-18-decimal fee token would be systematically mispriced by _computeOracleFloor; production integrations of exotic fee tokens should add a decimals-normalizing oracle wrapper. In practice the primary inflow is WAERE (18 decimals), which takes the no-swap path.

5. The liquid-staking receipt: sAERE

Address: 0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0. Source: staking/sAERE.sol, an OpenZeppelin ERC-4626 vault over WAERE. No owner, no admin, no pause, no upgrade proxy, no parameter setters.

Depositors lock WAERE and receive sAERE. The WAERE-per-sAERE exchange rate drifts up as AereSink's STAKER-YIELD bucket routes fees in. This is "real yield": it comes from protocol fee inflows, not from issuance, and the provider does not choose whether, when, or how much (once funds arrive they vest mechanically). There is no fixed APR; the rate is whatever the fee flow produces.

Linear drip (audit fix R5, HIGH-1). Yield is not recognized as a step function the instant the sink transfers AERE in. Arrivals are folded into a reward reserve that vests linearly over DRIP_DURATION = 7 days:

• totalAssets() returns the on-contract balance minus the still-unvested reserve, so share price grows continuously with time, not in blocks-sized jumps.
• sync() is permissionless and idempotent; it is also called inside every deposit and withdraw. It detects arrivals since lastObservedBalance and (re)computes rewardRate and periodFinish.
• Grief guard (audit fix R6, HIGH): a fresh drip period only restarts if arrivals are at least DRIP_RESTART_THRESHOLD_BPS = 100 (1%) of the unvested reserve, or there is no active period. Tiny 1-wei-per-block arrivals only top up rewardRate without extending periodFinish, so a griefer cannot indefinitely stall stakers' vesting.

Killing this drip is what defeats the flash-loan sandwich (deposit, flush the sink, redeem in one block): the share price cannot jump within a block.

Inflation-attack moat (audit fix R5, HIGH-4). _decimalsOffset() is overridden from OZ's default 0 to 6, giving a 1e6 virtual-share offset, which is the primary defense against the classic ERC-4626 first-depositor inflation attack. A dead-shares seed is also minted to 0x…dEaD at deploy. Honesty note for implementers: the contract's header comment describes a "1 WAERE" seed, but the compiled constant is DEAD_SHARES_SEED_WAERE = 1000 wei; the effective moat is the 1e6 decimals offset regardless of the seed size, so this documentation discrepancy does not affect safety.

Views for integrators: pricePerShare() (convertToAssets(1e18)), undistributedRewards(), and atomicState() (a single-block snapshot of balance, totalAssets, undistributed, supply, rewardRate, periodFinish, lastObservedBalance) for drift-free invariant checks.

Honest caveat on realized yield: sAERE only appreciates if fees actually flow through AereSink. With thin current usage, realized sAERE yield to date is minimal and should be read live from the exchange rate, not assumed. The mechanism is real and admin-free; the volume is early.

6. Staking-reward products

AERE has three distinct staking surfaces. They are frequently conflated; they are not the same and only sAERE is admin-free real-yield.

6.1 Delegated validator staking: AereStakingV2

Address: 0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC (owner = Foundation). Source: staking/AereStakingV2.sol. This is a bug-fix redeploy of V1 (0xAbDb01d9A4f41792129b2654Fb6DDB9689360DEc, deprecated, 0 validators / 0 staked / 0 balance). Do not use V1.

Model: token holders delegate native AERE to validators and earn APR; validators post a self-stake bond and take a commission on delegator rewards.

Parameters:

• rewardRateBps = 800 (8% APR) default, owner-settable via setRewardRateBps in [1, 10000] bps. The registry flags this: the founder should confirm the intended live APR, since V1's effective rate was mis-scaled to roughly 1.6%.
• MIN_VALIDATOR_SELF_STAKE = 500 ether (500 AERE).
• MIN_DELEGATION = 1 ether (1 AERE).
• UNBONDING_PERIOD = 7 days.
• SLASH_RATE_BPS = 500 (5% of self-stake per slash, owner-only slash).
• MAX_COMMISSION_BPS = 5000 (50% cap on validator commission).

Accrual is timestamp-based: reward = amount x rewardRateBps x secondsElapsed / (10000 x 365 days), which is immune to block-time changes (V1's bug divided by a hardcoded 0.1s-block count, underpaying roughly 5x). Every amount-changing path calls _settle first, so a top-up earns zero retroactive reward. Validator commission is split off gross and credited to commissionAccrued, claimable via claimCommission. Delegators claim via claimRewards; unbonding queues into a 7-day queue drained by claimUnbonded. A validator's own self-stake is a slashable bond that earns no reward; slashed AERE stays in the pool as surplus backing rewards, with no admin withdrawal of principal.

Honest funding caveat, stated in the source itself: rewards and commission are paid from this contract's native AERE balance. Because supply is fixed at 2.8B with no consensus-level minting, the pool must be seeded by the Foundation (out of genesis reserves) until protocol-level reward minting is wired to consensus, which is not built. claimRewards reverts with "pool insufficient (needs foundation top-up)" if the balance cannot cover the claim. So the 8% APR is a reserve-funded subsidy today, not native issuance.

6.2 Fixed-term locked staking: AereLockedStaking

Address: 0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad (owner = Foundation). Source: AereLockedStaking.sol.

Users lock native AERE for a fixed term and earn a fixed APY paid in AERE at maturity. Early exit forfeits all reward and returns principal only.

Tier	Duration	APY (APY_BPS)
0	30 days	10% (1000)
1	90 days	15% (1500)
2	180 days	22% (2200)
3	365 days	30% (3000)

• MIN_STAKE = 1 ether, MAX_STAKE = 100_000 ether per lock.
• Reward = principal x APY_BPS x duration / (365 days x 10000).
• Principal protection: withdraw reverts unless balance >= total + totalPrincipal, so other stakers' locked principal can never be drained to pay a maturity. The reward reserve is balance - totalPrincipal, seeded by the Foundation via receive() (anyone can donate).

Honest sustainability note: a 30% APY on a 365-day lock, funded from a finite Foundation-seeded reserve against a fixed 2.8B cap, is a subsidy with a runway, not a perpetual rate. It is safe (principal is protected, and maturities that the reserve cannot cover simply cannot be withdrawn until topped up), but it is not self-funding until real fee revenue through the sink is large enough to underwrite it. This is the core tension of a fixed-supply chain paying staking yield, and it is by design that the sink flywheel, not the reserve, is meant to be the long-run funding source.

6.3 Governance staking: AereGovernanceStaked

Address: 0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb. Source: AereGovernanceStaked.sol. Not a yield product; included for completeness because it reads staking state. Voting power equals the total AERE a holder has delegated across all validators in the staking contract (stake-to-vote). PROPOSAL_THRESHOLD = 100000 ether, QUORUM_PERCENTAGE = 20% of total staked, VOTING_PERIOD = 7 days, EXECUTION_DELAY = 2 days. The 7-day unbonding period makes vote-borrowing impractical.

7. End-to-end flywheel

validator coinbase reward R
        |
        v
AereCoinbaseSplitterV2  (37.5% burn / 15% sink / 47.5% rebate)
     |            |                     |
     |            |                     +--> validator (0.475 R)
     |            +--> wrap to WAERE --> AereSink.flush()
     |                                     |  (sink 15 / 40 / 45; 55% burn-eq + 45% yield)
     |                                     +--> BURN 15% + BUYBACK 40% --> AereFeeBurnVault
     |                                     +--> STAKER-YIELD 45% --> sAERE (rate appreciates)
     +--> AereFeeBurnVault (0.375 R, permanent)

Net per reward R (defaults): 0.4575 R burned, 0.0675 R to sAERE holders, 0.475 R rebated. The same AereSink is the intended router for other fee streams (fee-monetization, settlement, and similar), so as real usage grows, sAERE yield rises and burn accelerates without any parameter change and without any admin action, because the sink has no admin.

8. Honest limitations and open items

• Sink wiring on V2 is an operational state, not a code invariant. The three-way split is only active once the Foundation runs proposeSink + acceptSink (7-day timelock) pointing V2 at AereSink. Confirm on-chain before quoting the 45.75% number as live.
• Staking APRs are reserve-funded subsidies. No consensus-level reward minting exists; AereStakingV2 and AereLockedStaking pay from Foundation-seeded balances out of the fixed 2.8B. This is honest and on-strategy (no adaptive issuance), but it means the APR is bounded by the reserve until fee flow replaces it.
• Splitter throughput depends on validators. Burn only happens when validators route coinbase through the splitter. With seven validators under one operator, realized burn volume is early; read totalBurned / burnStats() live rather than assuming.
• No external audit. All fixes above are internal audit rounds (R5, R6, and the finding-numbered redeploys). The mechanisms are admin-minimized and reentrancy-guarded, but they have not had a third-party audit.
• sAERE doc discrepancy. The header comment says a 1 WAERE dead-seed; the constant is 1000 wei. Safety rests on the 1e6 decimals offset, so this is cosmetic, but it should be reconciled in a future redeploy or doc pass.
• AERE AereToken.sol note. The native token is AERE itself; AereToken.sol is only a governance-compatibility shim over WAERE. There is no separately mintable ERC-20 AERE.

9. Roadmap / in development

• Consensus-wired reward minting is not built. Long-term, staking rewards should be funded by protocol-level mechanics rather than reserve top-ups. Today this is explicitly a roadmap item (the staking source comments say "until protocol-level minting is wired to consensus"). Any such change must respect the fixed 2.8B cap; adaptive issuance is off-strategy and out of scope.
• Fee-source expansion into the sink. Broadening the set of contracts that flush into AereSink (beyond the coinbase splitter) is the primary lever to make sAERE yield and the burn self-sustaining. This is additive and requires no change to the immutable sink.
• V1-to-V2 splitter migration completion. Once all validators point their forwarder daemons at AereCoinbaseSplitterV2, V1 burnBps can be set to 0 and V1 retired.

Appendix: address registry (verbatim, chain 2800)

Contract	Address
WAERE	0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8
AereCoinbaseSplitter (V1)	0xb4b0eCe9011613A5b84248a9B42a0f309E6F01Ec
AereCoinbaseSplitterV2	0x8C1A48eFA57b66fEE743A00E3899c29ad3Fd27b4
AereFeeBurnVault	0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6
AereSink	0x69581B86A48161b067Ff4E01544780625B231676
sAERE	0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0
AereStakingV2	0x1D95eF6D17aeAB732dF914Ba2d018c270BC155FC
AereStaking V1 (deprecated)	0xAbDb01d9A4f41792129b2654Fb6DDB9689360DEc
AereLockedStaking	0x21108c28A849b05aE6b7a3a5bc435C9Bc897E7Ad
AereGovernanceStaked	0x8D77C888e439C4fADb2e23F1567a0A1965F80bCb
AereSwapRouter (sink DEX router)	0x7526B2E5526EfA84018378b60F2844Dad77523D8
AereLendingOracle (sink swap-floor oracle)	0xc0f18A567067F1B84BDf75eDEbFaDdCBb70A4C49
Foundation (owner of Ownable contracts)	0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3