Architecture at a glance
How Everstrat's contracts fit together — the Registry-centric design, which contracts are immutable, and what each component does.
Testing phase — treat as a test protocol
Everstrat is deployed on Ethereum mainnet (chain id 1), but it is in a testing phase and should be treated as a test protocol. Entry is invite-gated and the software is experimental.
Registry-centric design
Every Everstrat contract resolves its peers and enforces role permissions through a single
Registry contract. Instead of hardcoding addresses, each contract asks the Registry: "give me the
current address of the Controller" or "does this caller hold KEEPER_ROLE?" The Registry's address is
the one fixed reference every other contract points to. The Registry itself is immutable — it is
deployed directly, with no proxy, so the anchor every peer resolves through can never change its
logic. What it stores — peer addresses and role grants — is configuration that ADMIN_ROLE manages
behind the 48-hour timelock.
This design means:
- Upgradeable contracts can be replaced at their proxy without touching any other contract's configuration. Other contracts just query the Registry at call time.
- Roles (ADMIN, KEEPER, SECURITY, MINTER, …) are all managed in one place, making permission audits straightforward.
- Pause controls are per contract. Registry pause gates its own guarded mutations; it does not pause every peer. AMM claims and eligible cancellations remain callable during AMM pause.
One registry. A connected protocol.
The Registry is the shared address and role authority. The main path moves ETH from AMM to Controller to StrategyManager; token, queue, swap, and valuation paths branch from it. Keeper operations and individual role checks are omitted here.
Contract roles
| Contract | Upgradeable? | What it does |
|---|---|---|
| Registry | No (immutable) | Protocol address book and role authority. Every contract resolves peers and checks roles through it; its logic is fixed, while the addresses and roles it stores are admin-configurable. |
| AMM | No (immutable) | User entry and exit point. Runs the bonding curve, mints/burns EVE, manages immediate vs. queued exits. |
| EVE | No (immutable) | The ERC-20 token that represents your proportional share of the protocol's NAV. |
| Controller | Yes (UUPS proxy) | Receives deposited ETH from the AMM. Authenticated keeper executors drive distribution to strategies, withdrawal from strategies, and redemption-queue operations. |
| StrategyManager | Yes (UUPS proxy) | Registers strategies, routes funds in and out, and computes total NAV by aggregating each strategy's navInETH(). |
| ExitQueue | Yes (UUPS proxy) | Manages batches of queued redemption requests when the AMM lacks free ETH to pay immediately. |
| Oracle | Yes (UUPS proxy) | Wraps Chainlink ETH/USD and strategy-asset price feeds. Used for token valuation, bootstrap validation, and USD views. Entry/exit depend indirectly on it through NAV. |
| Converter | Yes (UUPS proxy) | Shared DEX swap and WETH wrap/unwrap module used by strategies. Centralises routing so strategies don't each integrate a DEX directly. |
| UniCLStrat | No (immutable) | The registered strategy family. Deploys pooled ETH into a Uniswap V3 concentrated-liquidity position and reports NAV back to the StrategyManager. |
Immutable vs. upgradeable
The distinction is intentional:
- Immutable contracts (AMM, EVE, UniCLStrat, Registry) are "code is law." Their logic cannot change after deployment. Because AMM and EVE are the trust anchors users interact with directly — and the Registry is the anchor every contract resolves through — making them immutable limits the attack surface for governance actions.
- Upgradeable contracts (Controller, StrategyManager, ExitQueue, Oracle, Converter) can be
improved to fix bugs or add features. Upgrades require
ADMIN_ROLE, which in production is intended to be held by a 48-hour TimelockController — meaning the community has time to react before a change takes effect.
For the full role breakdown and governance model, see Trust & governance.
The money flow in brief
Deposit. You call the AMM with ETH. The AMM mints EVE at the current premium price and forwards your ETH to the Controller.
Deployment. A Mimic function calls an allowlisted keeper executor, which calls Controller, which routes ETH through the StrategyManager into registered strategies. Strategies deploy capital into yield sources (currently Uniswap V3 concentrated liquidity via UniCLStrat).
Accounting. Each strategy continuously tracks its NAV in ETH. The StrategyManager aggregates these into a total NAV that the AMM uses to price entries and exits.
Exit. You send EVE to the AMM. At the dated snapshot, new exits queue: EVE is escrowed, keepers price and process the batch, and you then claim ETH. The redemption queue explains when an immediate exit is possible.
Where to go next
- Deep per-contract reference: Contracts
- Immutable vs. upgradeable governance split: Trust & governance
- How the bonding curve prices entry and exit: Pricing & the bonding curve
- How queued exits work in detail: The redemption queue, in depth
Last updated on