# AIP-5: sAERE Receipt Token and AereSink Immutable Flywheel ## Preamble | Field | Value | | --- | --- | | AIP | 5 | | Title | sAERE Receipt Token and AereSink Immutable Flywheel | | Author | AERE Foundation | | Type | Standards Track | | Category | ARC | | Status | Final | | Created | 2026-07-11 | | Requires | 2 | | Ratification | Foundation-ratified (pre-decentralization) | ## Abstract This AIP documents AERE's protocol-revenue flywheel: an immutable three-bucket router (AereSink) that splits incoming fee streams into burn, buyback-and-burn, and staker-yield, and an ERC-4626 receipt token (sAERE) whose exchange rate drifts up as the staker-yield bucket flows in. Neither contract has an owner, admin, or upgrade path. It is a retro-filed record of contracts already live on chain 2800. ## Motivation AERE wanted a single, credible mechanism to accrue protocol revenue to AERE holders that no one, including the Foundation, could later divert or turn off. The two failure modes to avoid were (1) an admin-controlled treasury that could redirect fees, and (2) a receipt token whose yield could be gamed by flash-loan sandwich attacks around the moment revenue arrives. The design goal was an immutable router with fixed, publicly verifiable split percentages, feeding a receipt vault that vests arrivals smoothly instead of in a single-block step, so that stakers earn deterministically and no admin key is a point of trust or a point of failure. ## Specification ### AereSink (immutable three-bucket router) Address `0x69581B86A48161b067Ff4E01544780625B231676`. Source `contracts/contracts/sink/AereSink.sol`. Fee-source contracts call `flush(token, amount)` after approving the sink. The sink splits the amount into three buckets by immutable basis points that MUST sum to 10000 (the constructor reverts otherwise): - **BURN_BPS = 1500 (15%)** to AereFeeBurnVault (`0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6`), an extra burn on top of the 37.5% coinbase burn in AIP-2. - **BUYBACK_BPS = 4000 (40%)** buyback-and-burn: non-AERE fees are swapped to AERE via the DEX router and then burned. - **STAKER_YIELD_BPS = 4500 (45%)** to the sAERE vault, lifting its exchange rate. If the flushed token is AERE (WAERE, `0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8`), the burn and buyback buckets merge into a single transfer to the burn vault and the staker bucket transfers to sAERE directly, no swap. If the token is not AERE, each bucket is swapped along `[token, AERE]` with an oracle-derived `amountOutMin` floor so the swap cannot be sandwiched via pool-reserve manipulation. Immutability invariants (enforced in code and tests): no owner, no admin, no governance role; no `setBucket`, `setRecipient`, `setRouter`, or `pause`; bucket recipients and basis points are set at deploy and are immutable. Replacing the router means redeploying and rewiring fee sources, not mutating this contract. ### sAERE (ERC-4626 receipt token) Address `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0`. Source `contracts/contracts/staking/sAERE.sol`. sAERE is a standard ERC-4626 vault: deposit WAERE, receive sAERE shares. The WAERE-per-sAERE rate rises as the staker-yield bucket arrives. Two hardening choices are normative: - **Linear drip.** Arrivals are not recognized as an instantaneous jump in `totalAssets`. They vest linearly over `DRIP_DURATION = 7 days`. `totalAssets()` excludes the not-yet-vested reserve, so share price grows continuously, not in a single-block step. `sync()` is permissionless and is called inside every deposit and withdraw; AereSink also pings it after transferring yield in. - **Inflation-attack widening.** `_decimalsOffset()` is overridden to 6 and a dead-share seed is minted at construction, so the classic first-depositor inflation attack is economically infeasible. sAERE has no admin, no owner, no pause, no upgrade proxy, and no parameter setters. `DRIP_DURATION` and the decimal offset are compile-time constants. ## Rationale Immutability is the whole point. An admin-configurable router would reintroduce exactly the trust assumption the flywheel is meant to remove, so AereSink has no setters at all; changing the policy requires a visible redeploy and a rewire that the community can observe. The 15/40/45 split weights holder accrual (buyback plus staker yield is 85%) over pure burn (15%), on the view that a rising sAERE rate plus buyback pressure is a stronger, more legible incentive than a large flat burn alone. The linear drip exists specifically to defeat the deposit-then-flush-then-redeem sandwich: if yield landed as a step, a flash-loaned depositor could capture it in one block. Vesting over seven days makes the per-block share-price change negligible relative to any single attacker's position. Choosing an ERC-4626 receipt token (rather than a rebasing balance) keeps sAERE composable with the wider DeFi tooling that already understands 4626. ## Backwards Compatibility None. sAERE is a standard ERC-4626 token and AereSink is an additive router. They introduce no new base token (AERE, via its WAERE wrapper, is the only token) and do not change existing contracts. Fee sources opt in by calling `flush`. ## Security Considerations - **No admin is a feature and a constraint.** Because neither contract has an owner, a bug in either cannot be patched in place; the only remedy is a redeploy and a rewire of fee sources. This is the accepted trade for removing admin trust. - **Sandwich resistance depends on the oracle.** The buyback swap's `amountOutMin` is computed from an oracle price floor, not from pool reserves. If AereSink is deployed with a zero oracle (a test-only mode), swaps accept any non-zero output and are sandwich-able. Production deployment MUST set a real oracle. The drip mitigates the yield-timing sandwich independently of the swap path. - **Swap liveness.** If a non-AERE buyback swap fails (no liquidity, slippage), the tokens remain as dust and `sweepDust()` can re-flush later; a single dead pair does not lock the whole flush. This is a liveness, not a safety, concern. - **Unaudited.** These contracts have not had an external security audit. They have been hardened across several internal review rounds (the drip and the inflation-offset widening are outputs of those rounds), but internal review is not an external audit. - **Thin usage.** As with the rest of AERE today, real flush volume through the sink is thin. The mechanism is live and immutable, but its economic effect is only as large as the fee streams actually routed into it. ## Reference Implementation and On-Chain Deployment - `contracts/contracts/sink/AereSink.sol` -> `0x69581B86A48161b067Ff4E01544780625B231676` - `contracts/contracts/staking/sAERE.sol` -> `0xA2125bE9C6fd4196D9F94757Df18B3a2A5e650b0` - Burn destination: AereFeeBurnVault `0x696afDF4f814e6Fd6aa45CE14C498ed9375fB2c6` (AIP-2) - Base token: WAERE `0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8` - Deploy script: `contracts/deploy/deploy-saere-sink-stack.js` (splits 1500/4000/4500) All addresses copied verbatim from `sdk-js/src/addresses.ts`. The immutable split is readable on-chain via `AereSink.BURN_BPS()`, `BUYBACK_BPS()`, and `STAKER_YIELD_BPS()`, which sum to 10000. ## Copyright Released to the public domain (CC0). No rights reserved.