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; measured mean block interval 0.5175 s over the 2,000 blocks to head 11,810,041 on 2026-08-01; seven validators, f=2, commit quorum 5 of 7, one operator).
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):

The table below gives the genesis-v2 allocation and, next to it, the balance actually held by each address today. **These are two different numbers and this spec previously printed only the first.** Balances read with `eth_getBalance` at head block 11,810,041 on `https://rpc.aere.network`, 2026-08-01.

| Allocation | Allocated at genesis | Held at head 11,810,041 | Address |
|---|---|---|---|
| Strategic Investor (sold off-chain) | 100,000,000 | 100,000,000 | `0xaee2f3989f0AB23296Fa3b92247fe67587141311` |
| Foundation (chain admin / contract owner) | 180,000,000 | 179,999,989.9987 | `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3` |
| Mining Reserve | 1,400,000,000 | 1,400,000,000 | `0x038f59A40ceeCd599A4588E4B0ff4642a0fbfFB8` |
| Ecosystem Reserve | 560,000,000 | **0.6999958** | `0xB6a364F47d21DC2CbEB803565c111c1026e11C75` |
| Team Reserve | 420,000,000 | 420,000,000 | `0x7968C438204a78B4e032fcFFd9A56Edb15fdCCdf` |
| Airdrop Reserve | 140,000,000 | 140,000,000 | `0x261913fA73D6F109382F1aE98Ff6822ff03628B1` |
| **Sum of the six addresses above** | **2,800,000,000** | **2,239,999,990.6987** | |

**Correction of 2026-08-01: this table did not add up, and now it says so.** An earlier revision printed the allocation column and the sentence "Total 2,800,000,000 AERE, capped" directly beneath it, with no balance column. A reader who checked the Ecosystem Reserve address against the chain found under 1 AERE there and no explanation anywhere in this document.

The supply cap is unchanged and is not in question: 2,800,000,000 AERE, fixed at genesis-v2 on 2026-05-07, with no consensus-level minting on chain 2800 and no path in any contract in this spec that re-mints. What changed is location, not quantity. The Ecosystem Reserve allocation was moved off its genesis address, which is why that row reads under 1 AERE and why the six addresses fall 560,000,009.3 AERE short of the cap. Of that difference, 559,999,999 AERE is held at a **single separate account** on chain and the remaining 10.3 AERE is the fee spend of these six wallets since genesis. That last figure is a reconciliation of the allocation column against the balance column, not a traced sum of transactions, so treat it as **NOT MEASURED** as an independent number.

The receiving account is deliberately not named in this document. Nothing about the sum is hidden by that: the cap, the six balances, the shortfall and the amount held elsewhere are all printed above, and the arithmetic closes. Two things this spec also does **not** state, because they are not measured here: when the movement happened, and why. Public nodes retain roughly 500 blocks of state (measured at head: `eth_getBalance` 300 blocks back answers, 512 blocks back returns null), so the move cannot be re-derived from state through the public RPC today. Bringing that balance under the same governance handover as the rest of the protocol is an open roadmap item.

**Ownership: verified, not assumed.** Every Ownable contract in this spec is owned by the Foundation account `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3` (a single-key Foundation-controlled account, not a deployed multisig). Re-read at head on 2026-08-01: `owner()` returns that account on `AereCoinbaseSplitter` `0xb4b0eCe9…`, `AereCoinbaseSplitterV2` `0x8C1A48eF…`, `AereStakingV2` `0x1D95eF6D…`, `AereLockedStaking` `0x21108c28…`, `AereGovernanceStaked` `0x8D77C888…` and `AereLendingOracle` `0xc0f18A56…`. `AereSink`, `sAERE`, `AereFeeBurnVault`, `WAERE` and `AereSwapRouter` expose no `owner()` at all, consistent with the "no owner, no admin" claim made for them below. This paragraph is accurate as written; it was re-verified rather than carried forward.

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. This arithmetic holds because coinbase reward `R` is native AERE, which the splitter wraps to WAERE, so the sink takes the no-swap branch and merges BURN and BUYBACK into one transfer. For a **non-AERE** inflow the BUYBACK leg cannot execute at all, because `AereSink.DEX_ROUTER()` is `0x…0001` and immutable; see Section 2.1. The `0.0825 R` figure is therefore correct for the coinbase path and must not be generalized to arbitrary fee tokens.
- 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: `aere-contracts/contracts/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`, 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).

> **MEASURED, AND IT CHANGES THIS PARAGRAPH. The live sink is wired to neither.**
>
> Read on `AereSink 0x69581B86A48161b067Ff4E01544780625B231676` at head block 11,810,041:
>
> - `DEX_ROUTER()` returns `0x0000000000000000000000000000000000000001`
> - `ORACLE()` returns `0x0000000000000000000000000000000000000000`
>
> Both are **immutable**. An earlier revision of this paragraph named `AereSwapRouter 0x7526B2E5526EfA84018378b60F2844Dad77523D8` and `AereLendingOracle 0xc0f18A567067F1B84BDf75eDEbFaDdCBb70A4C49` as the sink's router and oracle. The sink is connected to neither, and because both fields are immutable, it cannot be connected to them without redeploying it.
>
> The consequences are exact and they are not small:
>
> 1. The **BUYBACK bucket, at 4,000 bps the largest of the three, cannot execute for a non-AERE token.** There is no reachable router to swap through. Confirmed alongside: `BURN_BPS() = 1500` and `BUYBACK_BPS() = 4000`, so the 15 / 40 / 45 split itself is real and correctly stated everywhere in this document.
> 2. The **oracle-derived sandwich floor described above is not active.** With `ORACLE()` at the zero address, the documented `_computeOracleFloor` path degenerates to the fallback of 1, which accepts any non-zero output. The protection is described in this spec and is not running.
>
> What still works exactly as written: the AERE and WAERE inflow path, which is the normal case, takes the no-swap branch, merges BURN and BUYBACK into one transfer to the burn vault, and needs neither router nor oracle. That is the path that has actually carried volume.
>
> This is a wiring gap on a contract whose immutability is, correctly, the credibility anchor of the whole design. Immutability cuts both ways: nobody can change the split under holders, and nobody can fix this without a redeploy and a rewire of fee sources. Both halves are true and both belong in the same paragraph.

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: `aere-contracts/contracts/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: `aere-contracts/contracts/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. **See "the bond is not slashable once a validator leaves" below before relying on the word bond.**

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`, and **only while the validator is still active**; see the bond note at the end of this section).
- `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 earns no reward; slashed AERE stays in the pool as surplus backing rewards, with no admin withdrawal of principal.

> **The self-stake is not a slashable bond once the validator chooses to leave. Correction of 2026-08-01.**
>
> An earlier revision of this line, and of the `SLASH_RATE_BPS` bullet above, described the self-stake as "a slashable bond". Read against the live `AereStakingV2` source, that overstates the guarantee, and the gap is the whole point of a bond.
>
> - `slash(address, string)` requires `v.active` and removes `SLASH_RATE_BPS = 500` bps of `v.selfStake`.
> - `deregisterValidator()` is permissive. It sets `v.selfStake = 0`, sets `v.active = false`, and pushes the **entire** self-stake into `unbondQueue`.
> - `slash` never touches `unbondQueue`.
>
> So the punishable amount is whatever the validator has left in `selfStake` at the moment the owner acts, and the validator decides that, unilaterally, by deregistering first. A bond that the bonded party can withdraw from the reach of the penalty is not a bond; it is a deposit with a notice period. The penalty is, in the operative sense, optional for the person being penalised.
>
> The accurate statement is: **`slash` removes 5% of a validator's self-stake for as long as that validator remains active, and stops being able to reach the self-stake the moment they deregister.** The 7-day unbonding queue delays withdrawal; it does not preserve slashability.
>
> Two measured facts that bound how much this matters today, and they are the reason this is written up rather than escalated: `totalStaked()` on `0x1D95eF6D…` is **0** and the contract's balance is **0** at head. Nobody has staked anything, so nobody is currently relying on this bond. That is a reason to fix the wording and the contract before there is stake, not a reason to leave the wording as it was.
>
> Confirmed by reading at head: `SLASH_RATE_BPS() = 500`, `UNBONDING_PERIOD() = 604800` seconds, which is 7 days exactly.

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.

**Read that diagram as the design, not as a measured flow.** Three things bound it, all measured at head block 11,810,041 on 2026-08-01.

1. **The BUYBACK leg is drawn for a non-AERE inflow and cannot run for one.** `AereSink.DEX_ROUTER()` is `0x…0001` and immutable. For AERE and WAERE inflows, the normal case, the diagram is correct because that path never swaps.
2. **Almost nothing has gone through it.** `AereCoinbaseSplitter` (V1) reports `totalBurned() = 137,352,594,046,167,719` wei, which is 0.137352594046167719 AERE. That is the entire lifetime figure.
3. **"Burned" in that counter means "routed to the burn vault", not "destroyed".** `AereFeeBurnVault 0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` holds exactly 0.137352594046167719 AERE at head, byte-identical to the counter, and the zero address holds 0. So the full amount the counter calls burned is still sitting in the vault. The vault is a permanent endpoint with no withdrawal path, so the AERE is out of circulation in the economically meaningful sense, and it has not been destroyed in the ledger sense. Anyone reading `totalBurned()` should know which of those two they are being told. Both numbers are public and they agree; the label is what needed fixing.

## 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. Measured at head on 2026-08-01: lifetime `totalBurned()` is 0.137352594046167719 AERE, all of it currently held by `AereFeeBurnVault`.
- **The sink's buyback bucket and sandwich floor are not wired.** `AereSink.DEX_ROUTER()` is `0x…0001` and `ORACLE()` is the zero address, both immutable. The 40% buyback bucket cannot execute for a non-AERE token, and the oracle-derived minimum-output floor is not active. Section 2.1 has the detail. Fixing it means redeploying the sink and rewiring fee sources; there is no setter, by design.
- **The validator self-stake stops being slashable at deregistration.** `deregisterValidator()` moves the whole self-stake into the unbonding queue and `slash` does not reach the queue. Section 6.1 has the detail. `totalStaked()` is 0 today, so nobody is relying on it yet.
- **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` |