aere-research/aips/AIP-5.md

# 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.
</content>