aere-network/aere-research
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4a0b48588c
aere-research/research/specs/spec-antimev-mempool.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

323 lines
32 KiB
Markdown
Raw Blame History

# AERE Anti-MEV Design: Threshold-Encrypted Mempool and Batch-Atomic Fair Settlement
Subsystem specification. Status as of 2026-07-11. Chain ID 2800 (Hyperledger Besu QBFT, 0.5-second blocks, seven validators, one operator).
## 0. Honesty banner (read first)
This document describes two complementary, **application-layer, opt-in** anti-MEV subsystems that AERE has built and, in part, demonstrated on chain 2800:
1. **AereShutterMempool** (V0 orchestration, V2/V3 threshold-BLS): a Shutter-style threshold-encrypted mempool that hides transaction contents until after an epoch's ordering is fixed.
2. **AereSettlement + AereSolverRegistry + AereVaultRelayer**: a CoW-style batch-atomic settlement DEX where users sign gasless orders and an authorised solver settles the whole batch in one transaction.
What this is **not**, stated plainly so no reader is misled:
- This is **not** base-consensus MEV protection. AERE runs Hyperledger Besu QBFT. A QBFT chain cannot gain a protocol-level encrypted mempool or enshrined proposer-builder separation (PBS) without a client fork. Both subsystems live entirely in smart-contract and off-chain-service space. Validators still sign classical QBFT and order the underlying commit/settle transactions like any other transaction.
- The threshold-encrypted mempool subsystem (V2/V3) is a **proof-of-concept**. Its contracts were deployed to chain 2800 and exercised end-to-end, but they are **not** registered in the canonical SDK address registry (`aerenew/sdk-js/src/addresses.ts`). Their addresses come only from repository deployment artifacts and are labeled as such throughout. Treat them as in-development, not production-registered.
- The batch-settlement contracts (AereSettlement stack) **are** in the canonical registry and were deployed 2026-05-31, but the off-chain solver service, the order-book API, and the front-end intent toggle that would make them a live product are **not yet deployed** (roadmap items recorded in the deployment manifest). On-chain, the settlement contract enforces atomicity and each user's own limit price; it does **not** enforce a uniform clearing price or capture surplus. Those are solver-trust and Phase-2 items, detailed in section 6.
- Both subsystems depend on a **single trusted coordinator/sequencer role** and (for V2/V3) a **trusted-dealer Shamir setup**. The solver set is a **permissioned allowlist** with a single bootstrap solver today. These are real centralisation weaknesses, called out in section 8.
Every contract address quoted below is either verbatim from `sdk-js/src/addresses.ts` (marked CANONICAL) or verbatim from a repository deployment artifact under `contracts/deployments/` (marked POC-ARTIFACT). No address is invented.
---
## 1. Threat model and design goals
Maximal Extractable Value (MEV) on a public chain is extracted in the gap between when a transaction is broadcast and when it is finally included and ordered. A party that can see pending transaction contents and influence ordering can front-run, back-run, and sandwich user trades. On AERE the primary ordering authority in that gap is the QBFT block proposer and, for the batch-settlement path, the solver that assembles a batch.
AERE attacks the problem from two directions at once:
- **Hide the contents** so that whoever orders transactions cannot tell what they contain until ordering is already fixed. This is the encrypted-mempool subsystem.
- **Remove the intra-batch ordering surface** so that a set of trades clears together, atomically, in one transaction, leaving no slot for an inserted sandwich. This is the batch-settlement subsystem.
Design goals, in priority order:
1. A proposer or sequencer must not be able to reorder or front-run based on plaintext it saw before the ordering was committed.
2. Any accepted decryption key must be provably the real threshold key, not a forgery, so decryption cannot be produced early or by a minority.
3. Liveness must not be held hostage by a single withheld reveal.
4. A user's downside must be bounded by its own signed limit, regardless of solver behaviour, and enforced atomically.
Non-goals for the current phase: trustless data-availability sampling, a distributed key generation (DKG) that removes the dealer, permissionless bonded solvers, on-chain uniform-price verification, and surplus capture. All are named in the roadmap (section 9).
---
## 2. Architecture overview
```
┌─────────────────────────────────────────────┐
user (gasless) │ ENCRYPTED MEMPOOL (opt-in, app-layer) │
───────────────► │ AereShutterMempool V2/V3 (PoC on 2800) │
ciphertext + │ commit → order → threshold-decrypt → reveal│
commitment └───────────────┬─────────────────────────────┘
│ (optional executor hook,
│ NOT wired to settlement today)
▼
┌─────────────────────────────────────────────┐
user (gasless) │ BATCH SETTLEMENT (opt-in, app-layer) │
EIP-712 order │ AereSettlement + Registry + VaultRelayer │
───────────────► │ solver assembles batch → settle() atomic │
└─────────────────────────────────────────────┘
```
The two subsystems are conceptually a pipeline: encrypt order flow so the ordering party is blind, then settle the resulting batch atomically. **Honest note:** they are independent contracts today. AereShutterMempool V2/V3 expose an optional `executor` address that receives `execute(uint64,uint256,bytes)` calls on reveal, but AereSettlement does **not** implement that interface, so nothing wires the mempool's reveal path into the settlement contract at present. Integrating the two (mempool executor to a settlement adapter) is a roadmap item. Each subsystem is described independently below.
---
## 3. Subsystem A1: AereShutterMempool V0 (orchestration, code-only)
Source: `aerenew/contracts/contracts/mempool/AereShutterMempool.sol`. Compiled artifact present; **no deployment record exists** in `contracts/deployments/`, so V0 is treated as a code-only reference stage that V2/V3 supersede.
V0 establishes the on-chain commit/reveal skeleton without real threshold cryptography. Its stated model:
- **Keyper epochs.** The Foundation opens a keyper epoch (`openEpoch`) carrying a Merkle root of keyper BLS pubkeys and a hash of the aggregated public key. Opening a new epoch implicitly closes the prior one. At most one epoch is open at a time.
- **Ciphertext commitment.** Anyone submits an encrypted envelope with `commit` (or `commitForEpoch` to pin the expected epoch). Storage records the submitter, a SHA-256 hash of the ciphertext blob, an off-chain URI (ipfs/https), the block, and the epoch. `envelopeId = keccak256(epochId, ciphertextHash, sender)`.
- **Key release.** After `startBlock + REVEAL_DELAY_BLOCKS`, the Foundation posts the epoch decryption-key commitment (`releaseDecryptionKey`).
- **Reveal.** `markRevealed` checks that the submitted plaintext binds to the committed ciphertext and released key via `keccak256(abi.encodePacked(plaintext, releasedKey)) == ciphertextHash`, then flags the envelope decrypt-eligible.
The V0 invariant is timing-based: ciphertexts are visible but undecipherable at block N, ordering is finalised by consensus at block N, and the key is released only at block `N + REVEAL_DELAY_BLOCKS`, so post-hoc reordering gains nothing.
The contract records several audit fixes in-source, worth citing because they show the failure modes that motivated V2:
- MED #31: the constructor now requires `revealDelayBlocks >= 1` (a zero delay would defeat protection).
- HIGH #6: `commitForEpoch` lets a caller pin the expected epoch, so a reordered `openEpoch` cannot silently attach a ciphertext to the wrong keyper key and make it permanently undecryptable.
- HIGH #4: `commit` refuses to overwrite an existing envelope slot (no double-reveal via re-commit).
- HIGH #5: `releaseDecryptionKey` is one-shot per epoch (no key overwrite).
- HIGH #3: `markRevealed` is gated to the Foundation and requires the actual plaintext bytes, so nobody can forge a `Revealed` event with an arbitrary plaintext hash.
**Honest limitation of V0.** The "decryption key" is a keccak placeholder, not a real threshold key. The Foundation is the sole releaser and revealer. V0 is orchestration plumbing, not cryptographic anti-MEV. V2 replaces the placeholder with a real threshold-BLS scheme verified on-chain.
---
## 4. Subsystem A2: AereShutterMempool V2 (threshold-BLS, PoC deployed)
Source: `aerenew/contracts/contracts/mempool/AereShutterMempoolV2.sol`.
POC-ARTIFACT address (from `contracts/deployments/shutter-mempool-v2.json`, **not** in the canonical SDK registry): `0x135100D523edA8D0AdC70e08af905dE5042A9310`, deploy tx `0x87ad0d549c396bd5a002b6f9d984483ee3e16567261ff552fd3ce83fb00d3471`, deploy block 8934371, coordinator `0xbeB33D20dFBBD49eC7AC1F617667f1f02dfd6465`.
### 4.1 Cryptographic construction
V2 implements Boldyreva threshold BLS over the BLS12-381 curve and verifies it on-chain with the EIP-2537 pairing-check precompile at address `0x0f` (0x00...0f). EIP-2537 is live on chain 2800 via the Pectra ruleset (BLS12-381 precompiles at 0x0b through 0x11). The contract comment records that the precompile was probed live on 2800: a valid pairing identity returns 1, garbage input reverts.
Notation used in the contract and in this spec:
- Committee master secret `s`, Shamir `(t, N)`-shared off-chain by a dealer.
- Group public key `PK = s * g2` in G2. This is the epoch encryption public key.
- Keyper public keys `P_i = s_i * g2` in G2. These are the published verifiable-secret-sharing (VSS) commitments.
- Epoch identity `H1 = hashToCurve(epoch tag)` in G1.
- Epoch decryption key `DK = s * H1` in G1. This is the threshold signature over the epoch tag.
- Keyper share `sig_i = s_i * H1` in G1.
- `DK` is reconstructed off-chain from `t` shares by Lagrange interpolation, then verified on-chain.
Two on-chain pairing equalities, both expressed as a product-equals-identity so the single `0x0f` call decides them:
- Share validity: `e(sig_i, g2) == e(H1, P_i)`, checked as `e(sig_i, g2) * e(-H1, P_i) == 1`.
- DK validity: `e(DK, g2) == e(H1, PK)`, checked as `e(DK, g2) * e(-H1, PK) == 1`.
A share or a reconstructed DK that fails its pairing reverts, so a keyper cannot post an inconsistent share and no forged DK is ever accepted. Point encodings follow EIP-2537: a G1 point is 128 bytes, a G2 point is 256 bytes, and the two-pair pairing input is `2 * 384 = 768` bytes. The helper `_pairingCheck2` concatenates the four operands, staticcalls `0x0f`, and returns true only when the 32-byte output decodes to 1.
### 4.2 Epoch lifecycle and phases
An epoch moves through `Phase { None, Open, Ordered, Finalized }`:
1. **Committee registration.** `registerKeypers(addrs, pubkeys, t)` is one-shot and coordinator-only. It stores each keyper's address and 256-byte G2 public key and sets `threshold = t`, `keyperCount = N`.
2. **Open.** `startEpoch(epochId, pk, h1, h1neg)` publishes the epoch encryption key `PK`, the epoch identity `H1`, and its negation, and sets the epoch `Open`.
3. **Submit.** While `Open`, anyone calls `submitEncrypted(epochId, ciphertext, commitment)`. The full ciphertext blob (`U(256-byte G2) || C(payload XOR mask)`) is emitted for off-chain availability; only the binding commitment `keccak256(abi.encode(plaintext, opening))` is stored, and duplicates revert. The sequencer sees only ciphertexts.
4. **Order.** `commitOrdering(epochId, orderingRoot)` is sequencer-only and moves the epoch to `Ordered`. It commits a Merkle root over execution positions and **must** happen before any decryption share exists.
5. **Shares.** `submitDecryptionShare(epochId, keyperIndex, share)` reverts while the epoch is still `Open` or `None` (this is the no-early-decrypt guard) and reverts unless the share passes its on-chain pairing check. Each keyper index can submit once.
6. **Finalize.** Once at least `t` valid shares exist, `finalizeEpoch(epochId, dk)` accepts the off-chain Lagrange reconstruction only if it passes the DK pairing check, and moves the epoch to `Finalized`.
7. **Reveal and execute.** `revealAndExecute(epochId, index, plaintext, opening, proof)` walks the committed ordering strictly in sequence (`index == nextExecIndex`), checks the commitment was actually submitted and not already executed, verifies Merkle membership of `(epochId, index, commitment)` against the committed ordering root, and confirms the plaintext opens the commitment. It then advances the cursor and optionally forwards the plaintext to the configured `executor` as a best-effort `execute(uint64,uint256,bytes)` call (a failing consumer does not roll back the reveal record).
### 4.3 Anti-MEV invariant (V2)
1. Users submit ciphertexts plus a hiding, binding commitment while the epoch is `Open`; the sequencer sees only ciphertexts.
2. The sequencer commits an ordering (a Merkle root over positions) **before** any decryption share can exist; `submitDecryptionShare` reverts until ordering is committed.
3. Keypers post `t` valid shares; anyone reconstructs `DK` off-chain; the reconstruction is pairing-verified on-chain at `finalizeEpoch`.
4. Reveal walks the committed ordering strictly in order; a plaintext that does not open its committed value reverts, and an out-of-order reveal reverts.
Because ordering is fixed while contents are still encrypted, the party that fixes ordering cannot base that ordering on plaintext. Reordering after the fact is impossible: the ordering root is already committed, and reveals must follow it.
### 4.4 Keyper accountability
`reportInconsistentShare(epochId, keyperIndex, allegedShare)` lets anyone flag a keyper whose off-chain share is inconsistent with its on-chain VSS commitment `P_i`. The function reverts if the alleged share actually passes its pairing check, so false accusations are impossible. This emits a `KeyperFlagged` event only; it is a detection primitive, not slashing. Economic slashing of misbehaving keypers is not implemented.
### 4.5 Honest scope and assumptions (V2, from source)
- The symmetric unmasking step (hashing the GT pairing element to a byte mask for XOR) is done **off-chain** by the executor, because the `0x0f` precompile returns only a pairing-equality boolean and cannot output a GT element to hash. On-chain, the plaintext-to-commitment binding is a keccak commitment; DK correctness itself is fully pairing-verified on-chain, so decryption is deterministic and cannot be produced before `t` keypers act.
- `PK`, `P_i`, `H1`, and `H1neg` are published by the committee dealer at registration and epoch start. A malformed published point only breaks liveness (an honest DK or share would fail its pairing); it cannot let a non-committee actor forge `DK`, which still requires the master secret `s` that only `t`-of-`N` shares reconstruct.
- The PoC uses a **trusted-dealer Shamir setup**. A production system would run a DKG so no single party ever holds `s`. This is the single most important cryptographic caveat.
### 4.6 V2 known weakness (fixed in V3)
`revealAndExecute` advances the cursor only on a successful reveal. A single committed position whose plaintext or opening is never revealed (griefed, lost, or malformed) stalls every later position in that epoch forever. There is no skip and no timeout. V3 fixes exactly this.
### 4.7 V2 on-chain demonstration (from deployment artifact)
The V2 deployment artifact records an end-to-end run on chain 2800: a 3-of-5 committee, epoch `8934372` finalized with `shareCount` 3, an ordering root over 2 committed envelopes, and two reveal/execute transactions (`0x552f6779...c7bb`, `0x30f2d141...dc0c`), with `nextExecIndex` reaching 2. The recorded `dkHash` is `0xbb4f9385bf208ea729a5f353434ed126212e377847db7211ac0cfe7e906f3892`. These values are transcribed verbatim from `shutter-mempool-v2.json`; they evidence that the pairing-verified threshold path executed, not a production traffic claim.
---
## 5. Subsystem A3: AereShutterMempool V3 (liveness fix, PoC deployed)
Source: `aerenew/contracts/contracts/mempool/AereShutterMempoolV3.sol`.
POC-ARTIFACT address (from `contracts/deployments/shutter-mempool-v3.json`, **not** in the canonical SDK registry): `0x0C0b0560fcaa534fc30D29ae1D248CC1675281df`, deploy tx `0x72f333214cc61836c334a4e82548175f658db39416f103f5124c9917b40c7fa1`, deploy block 8952902, reveal window 60 seconds, coordinator `0xbeB33D20dFBBD49eC7AC1F617667f1f02dfd6465`.
V3 is byte-for-byte the V2 threshold-BLS design (same 3-of-5 committee shape, same commitment binding, same out-of-order reject, same no-early-decrypt guarantee) plus one liveness fix for the reveal-timeout DoS described in 4.6.
### 5.1 The reveal-window escape hatch
- `finalizeEpoch` now stamps a per-epoch `revealDeadline = block.timestamp + REVEAL_WINDOW`, where `REVEAL_WINDOW` is an immutable constructor parameter (60 seconds in the PoC deployment).
- `skipUnrevealed(epochId, index)` advances `nextExecIndex` past the current head position, but only when all four conditions hold: the epoch is `Finalized`, `index == nextExecIndex` (skip strictly at the head), `index < envelopeCount` (there is a position to skip), and `block.timestamp > revealDeadline` (the window has closed). It records `skippedPosition[epochId][index]` and emits `PositionSkipped`.
Because skip only ever acts on the head and a successful reveal advances the head atomically, the head is by construction the still-unrevealed position: a position that was already revealed sits behind the cursor, so skipping it reverts `OutOfOrder`. Revealing is never gated by the deadline; `revealAndExecute` keeps working after the window closes, so a late-but-honest opener can still land its position. Skip is only an escape hatch for a position nobody reveals.
### 5.2 Permissionless-reveal invariant
The liveness argument rests on a protocol invariant that the ciphertext must embed its own opening: the encrypted blob decrypts under `DK` to `(plaintext || opening)` such that `keccak256(abi.encode(plaintext, opening))` equals the committed commitment. This makes reveal permissionless: once `DK` is reconstructed, any holder of the decryption key can open any committed position and call `revealAndExecute`. A well-formed position is therefore always revealable by anyone, so `skipUnrevealed` only ever fires on a position whose opening was genuinely withheld, lost, or malformed, never to censor a revealable transaction. The tradeoff is a little worst-case latency: a stuck position is only skippable after `REVEAL_WINDOW` elapses.
### 5.3 V3 on-chain demonstration (from deployment artifact)
The V3 deployment artifact records the liveness fix exercised on chain 2800: epoch `8952903` finalized (`dkHash` `0xc435edc7fa0eff0f4d2a43556c7d5321294befb67988a03b546d261ddc06081b`, `revealDeadline` 1783700920), position 0 deliberately left unrevealed to simulate a withheld opening, an early `skipUnrevealed` reverting `SkipTooEarly`, then a post-deadline skip (`0x3ee66f74...43ca`) followed by reveal of position 1 (`0x39f75472...fa29`), with `finalNextExecIndex` reaching 2. Transcribed verbatim from `shutter-mempool-v3.json`. This demonstrates that one stuck position no longer stalls the epoch, which was the V2 DoS.
### 5.4 V3 residual weaknesses
The same trusted-dealer, off-chain-unmasking, and single-coordinator caveats from 4.5 carry over unchanged. V3 fixes liveness, not decentralisation. Keyper slashing is still detection-only.
---
## 6. Subsystem B: AereSettlement, solver, and relayer (CoW-style, canonical)
Sources: `aerenew/contracts/contracts/dex/AereSettlement.sol`, `AereSolverRegistry.sol`, `AereVaultRelayer.sol`.
CANONICAL addresses (verbatim from `sdk-js/src/addresses.ts`):
- `AereSettlement` = `0x9C2957b1622567B4802E4AFd4c42FB2ec70dE875` (Tier-1.9 batch-auction DEX, deployed 2026-05-31)
- `AereSolverRegistry` = `0xDBD29332a9993d2816EF0bD240288E03a8103f3B`
- `AereVaultRelayer` = `0x9FCA122e87E36D7cba20DbEA7b9b7354A4Cece91`
The settlement-stack deployment artifact additionally records a bootstrap solver `0xE04587e0c6da6a30a24EFe7d59701A2BfFb706d9` and Foundation owner `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`.
### 6.1 What it is
A simplified port of CoW Protocol's GPv2 stack. Users sign EIP-712 `Order` structs off-chain (gasless). An authorised solver collects open orders and submits the whole batch atomically via `settle(orders, signatures, executions)`. MEV protection comes from atomicity: because the whole batch executes in one transaction, no actor can insert a sandwich between two orders in the batch.
The `Order` struct carries `user`, `sellToken`, `buyToken`, `sellAmount` (exact, fill-or-kill in v1), `minBuyAmount` (the user's own slippage floor), `validTo` (unix deadline), and `salt` (per-user replay nonce). The `Execution` struct carries just `executedBuyAmount`, the solver's claim of what it will deliver.
`orderHash` builds the EIP-712 digest under the domain `EIP712("AereSettlement", "1")`. The contract inherits `Ownable`, `ReentrancyGuard`, and `EIP712` from OpenZeppelin.
### 6.2 The settle() flow
`settle` is `onlySolver` (allowlist-gated) and `nonReentrant`. It requires equal-length arrays and a non-empty batch. For each order it:
1. Checks `block.timestamp <= o.validTo` (not expired).
2. Requires `executions[i].executedBuyAmount >= o.minBuyAmount` (the user's floor is respected).
3. Recovers the EIP-712 signer with `ECDSA.recover` and requires `signer == o.user`.
4. Requires the order hash is not already `filled`, then marks it filled (replay protection).
5. Pulls `sellAmount` from user to solver through `AereVaultRelayer.transferFromUser` (users approved the relayer, not the settlement contract).
6. Pushes `executedBuyAmount` of `buyToken` from solver to user via `safeTransferFrom` (the solver must have approved the settlement contract for the buy token, or supply liquidity via internal coincidence-of-wants matching).
If any step in the loop reverts, the entire batch reverts, so a user can never be pulled from without receiving at least its `minBuyAmount`. `cancelOrder` lets a user mark its own order consumed on-chain; `isOrderFillable` is a view for open-order checks.
### 6.3 AereVaultRelayer and AereSolverRegistry
`AereVaultRelayer` follows the GPv2VaultRelayer pattern: users approve the relayer once per token (typically MaxUint256), and only the single authorised `settlement` address may call `transferFromUser`. Separating allowances from the settlement contract lets the settlement contract be upgraded without users re-approving. The owner can rotate the settlement address.
`AereSolverRegistry` follows GPv2AllowListAuthentication: an owner-curated `isSolver` allowlist with `addSolver`/`removeSolver`. Phase 1 (current) is an owner-curated allowlist; Phase 2 (not built) is intended to add permissionless bonded-solver entry with slashable AERE stake.
### 6.4 What settle() does and does not guarantee (critical honesty section)
On-chain guarantees that hold today:
- **Atomic batch execution.** No sandwich can be inserted between orders in the batch, because they share one transaction.
- **Per-order limit protection.** Every filled order delivers at least its signed `minBuyAmount`, or the whole batch reverts.
- **Signature and replay safety.** Each fill requires a valid EIP-712 signature from `o.user`, and each order hash can be filled at most once.
What the contract does **not** enforce, despite the docstring's description of finding a "uniform clearing price":
- **Uniform clearing price is not verified on-chain.** The contract checks each order against its own `minBuyAmount` only. It does not check that all orders in a pair cleared at one common price. Uniform-price fairness is a solver behaviour, not a contract invariant. A solver could fill different users of the same pair at different effective prices as long as each clears its own floor.
- **No surplus capture and no protocol fee.** Unlike CoW, this contract has no fee parameter and no surplus accounting. Any price improvement above `minBuyAmount` accrues wherever the solver directs it, not to users or to a protocol sink, on-chain. There is no wiring to `AereSink` (`0x69581B86A48161b067Ff4E01544780625B231676`) for MEV or surplus redistribution in this contract today.
- **No partial fills, no ERC-1271 signatures, no balance modes, no dynamic fees.** The source explicitly states these are omitted and that audit-grade hardening is deferred to Phase 2.
The practical security posture is therefore: **atomicity plus your own limit price protect you from the worst MEV, but you are trusting the permissioned solver for fair (uniform, surplus-returning) pricing above your floor.** That is a meaningful and honest distinction from a fully trust-minimised CoW deployment.
### 6.5 Off-chain solver and relayer service (roadmap, not deployed)
The settlement-stack deployment artifact lists the operational pieces that would make this a live product, all recorded as next steps rather than done:
- Rotate the bootstrap solver to a dedicated solver address.
- Deploy an `aere-cow-solver` Docker container running the default solver.
- Stand up an order-book API at `api.aere.network/cow` storing open orders in a separate explorer-db schema.
- Add an MEV-protected (intent) toggle to `/swap.html` alongside the direct AereSwap mode.
- Phase 2: bonded-solver registry for permissionless entry.
None of these off-chain services is confirmed deployed in the repository artifacts. The on-chain contracts are live; the surrounding solver and order-book infrastructure is in development.
---
## 7. How the two subsystems relate
The intended composition is: encrypted mempool blinds the ordering party to order flow, and batch settlement removes the intra-batch ordering surface. In a fully integrated design, decrypted orders from an epoch would be handed to a settlement executor that clears them as a batch.
**Honest current state:** the two are not integrated on-chain. AereShutterMempool V2/V3 can call an optional `executor.execute(uint64,uint256,bytes)` on reveal, but AereSettlement exposes `settle(...)`, not that interface, and no adapter connects them. A user today would use either the encrypted-mempool PoC or the batch-settlement stack, not a wired pipeline. Building a mempool-to-settlement executor adapter is a named roadmap item.
---
## 8. Consolidated honest limitations and security posture
1. **App-layer, opt-in, not base consensus.** Neither subsystem changes QBFT. Validators sign classical QBFT and can still censor or reorder the underlying commit and settle transactions at the base layer. The encrypted mempool protects transaction **contents** from being front-run; it does not stop a proposer from censoring or reordering ciphertext-commit transactions (though reordering opaque ciphertexts yields no MEV, since the proposer cannot see what is inside). This is not enshrined PBS and not a protocol-level encrypted mempool.
2. **Centralised operator and validator set.** Chain 2800 runs seven validators under one operator, one client (Besu). The encrypted-mempool coordinator and sequencer default to a single address (`0xbeB33D20dFBBD49eC7AC1F617667f1f02dfd6465` in the PoCs). A single sequencer commits ordering. This is a trust assumption, not a decentralised guarantee.
3. **Trusted-dealer key setup (V2/V3).** The threshold master secret is Shamir-shared by a dealer in the PoC. Until a DKG replaces the dealer, one party transiently holds `s`. A live product must not ship on a trusted dealer.
4. **Keyper accountability is detection-only.** Inconsistent shares can be flagged on-chain but are not economically slashed.
5. **Permissioned solvers, single bootstrap solver.** The settlement allowlist is owner-curated with one bootstrap solver today. Permissionless bonded, slashable solver entry is unbuilt (Phase 2).
6. **Uniform pricing and surplus are off-chain trust.** As detailed in 6.4, the settlement contract enforces atomicity and per-order floors only.
7. **PoC status of the encrypted mempool.** V2/V3 are demonstrated but not promoted to the canonical SDK registry, not audited externally, and carry no production traffic claim. V0 is code-only.
8. **No external audit.** The in-source audit-fix annotations reflect internal review. There is no third-party audit of these contracts.
Stating these plainly is deliberate. For a chain with thin usage and a small validator set, credibility comes from precise scoping, not from overclaiming that app-layer opt-in tooling is base-layer MEV resistance.
---
## 9. Roadmap (in development, not yet live)
- **DKG for the keyper committee** to remove the trusted dealer, so no party ever holds the master secret `s`.
- **On-chain (or precompile-assisted) symmetric unmasking.** The V0 source names a proposed decryption precompile at `0x102`; this is a proposed, not-live capability and would need a client fork on a scratch fork, not mainnet 2800. Today unmasking is off-chain and only DK correctness is verified on-chain.
- **Keyper slashing** built on the existing `reportInconsistentShare` detection primitive.
- **Mempool-to-settlement executor adapter** so a decrypted epoch feeds AereSettlement as a batch (section 7).
- **On-chain uniform-price verification and surplus capture** in the settlement path, with surplus routed to users or to `AereSink`.
- **Permissionless bonded-solver registry** with slashable AERE stake (Phase 2 of AereSolverRegistry).
- **Promotion of the encrypted-mempool contracts into the canonical SDK registry** once the trusted-dealer and audit gaps close.
- **Off-chain solver and order-book service deployment** (aere-cow-solver, `api.aere.network/cow`, `/swap.html` intent toggle).
- **External audit** of the full anti-MEV stack.
---
## 10. Address and artifact appendix (verbatim)
CANONICAL, from `aerenew/sdk-js/src/addresses.ts`:
| Contract | Address |
|---|---|
| AereSettlement | `0x9C2957b1622567B4802E4AFd4c42FB2ec70dE875` |
| AereSolverRegistry | `0xDBD29332a9993d2816EF0bD240288E03a8103f3B` |
| AereVaultRelayer | `0x9FCA122e87E36D7cba20DbEA7b9b7354A4Cece91` |
| AereSink (fee sink, referenced, not wired here) | `0x69581B86A48161b067Ff4E01544780625B231676` |
| Foundation (owner) | `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3` |
POC-ARTIFACT, from `aerenew/contracts/deployments/` (NOT in the canonical SDK registry; treat as proof-of-concept, in-development):
| Contract | Address | Source artifact |
|---|---|---|
| AereShutterMempoolV2 | `0x135100D523edA8D0AdC70e08af905dE5042A9310` | `shutter-mempool-v2.json` |
| AereShutterMempoolV3 | `0x0C0b0560fcaa534fc30D29ae1D248CC1675281df` | `shutter-mempool-v3.json` |
| PoC coordinator/deployer (both) | `0xbeB33D20dFBBD49eC7AC1F617667f1f02dfd6465` | both artifacts |
| Settlement bootstrap solver | `0xE04587e0c6da6a30a24EFe7d59701A2BfFb706d9` | `settlement-stack.json` |
AereShutterMempool V0 (`AereShutterMempool.sol`) is code and compiled artifact only, with no deployment record, and is superseded by V2/V3.
Precompile dependency: EIP-2537 BLS12-381 pairing check at address `0x0f`, live on chain 2800 under the Pectra ruleset (BLS12-381 precompiles at 0x0b through 0x11).
Contract sources of record:
- `aerenew/contracts/contracts/mempool/AereShutterMempool.sol` (V0)
- `aerenew/contracts/contracts/mempool/AereShutterMempoolV2.sol`
- `aerenew/contracts/contracts/mempool/AereShutterMempoolV3.sol`
- `aerenew/contracts/contracts/dex/AereSettlement.sol`
- `aerenew/contracts/contracts/dex/AereSolverRegistry.sol`
- `aerenew/contracts/contracts/dex/AereVaultRelayer.sol`
Reference in New Issue View Git Blame Copy Permalink