aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
main
aere-research/aips/AIP-5.md
Aere Network 4a0b48588c Initial public release 
Aere Network public source. Everything here can be checked against the live
chain (chain id 2800, https://rpc.aere.network).

Scope note, stated up front rather than buried: consensus on chain 2800 is
classical secp256k1 ECDSA QBFT. The post-quantum work in this repository is at
the signature, precompile, account and transport layers. Nothing here makes the
consensus post-quantum, and no document in it should be read as claiming so.
2026-07-20 01:02:30 +03:00

7.2 KiB
Raw Permalink Blame History

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.