aere-research/research/specs/spec-identity-compliance.md

# AERE Network Subsystem Spec: Identity and Compliance Stack

Status: mixed (live contracts on mainnet plus in-development pieces, marked inline)
Chain: AERE Network, chain ID 2800 (Hyperledger Besu QBFT, 0.5-second blocks)
Source of truth for addresses: `sdk-js/src/addresses.ts`
Source of truth for logic: `contracts/contracts/compliance/*.sol`, `contracts/contracts/AereIdentity.sol`, `zk-circuits/`

## 0. Honest preamble (read this first)

This stack is the identity and regulatory-compliance layer of AERE Network. Before any of the design below, three facts about the environment it runs in must be stated plainly, because they bound how much trust any reader should place in it:

1. AERE is currently operated by the Foundation as a small validator set (seven QBFT validators, one operator, one client implementation, Besu). It has not had an external security audit. Several of the compliance contracts here have zero or near-zero live usage (for example the privacy pool holds 0 deposits at the time of writing). We treat these as honest facts, not as things to hide.
2. Every piece of this stack lives at the application and account layer. None of it changes consensus. Validators sign classical QBFT messages. The identity and compliance contracts are ordinary EVM contracts that apps opt into.
3. Many of the "trust-minimized" claims below reduce to "trust the AERE Foundation to publish honest roots, and rely on an optimistic challenge window to catch it if it does not." Where that is the case we say so, and we describe exactly what a challenger can and cannot do.

A second theme runs through the whole document and deserves to be named up front: the difference between an inclusion proof and an absence proof. Most of the cryptography here proves that something IS in a set (an address is on a sanctions list, a credential is in an issuer's tree, a note is in a Foundation-attested "clean" set). Proving that something is NOT in a set is a fundamentally harder primitive, and where we do not have it, we say so rather than implying we do.

## 1. Architecture

The stack has three tiers:

- On-chain anchors (the Solidity contracts). These store roots, hashes, commitments, and boolean flags. They never store personally identifying information (PII). The one exception in spirit is `AereIdentity`, whose claims are plaintext booleans on-chain (no PII, but the fact that address X holds a "KYC_TIER_1" claim from attestor Y is public).
- Off-chain attestation and ingestion. The Foundation and third-party issuers run off-chain jobs that build Merkle trees (OFAC list, issuer credential sets, association sets) and publish roots through Foundation-gated calls.
- Zero-knowledge provers. SP1 zkVM (Succinct Labs) guest programs prove attribute statements (over-18, jurisdiction, clean-set membership) off-chain; the resulting Groth16 proofs are verified on-chain through the shared `SP1VerifierGateway` at `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628`.

The contracts, all owned by (or gated to) the Foundation account `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3` (a single-key Foundation-controlled account, not a deployed multisig) where they have an owner:

| Contract | Address | Role |
|---|---|---|
| AereIdentity | `0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1` | DID and revocable-claim registry |
| AereZKScreen (v3) | `0x3A097A459FD26aC79573aCB5adB51430e473C2f1` | ZK attribute-proof anchor |
| AereSanctionsRegistry | `0xb7d235718D99560F6EA4Fc5eAea2F8a306A3Cacf` | OFAC SDN Merkle registry |
| ChainalysisOracleWrapper | `0x1B7Be82C80f368f75Cb3807B1bc05E86A498f85c` | Forwarding sanctions oracle |
| AereForensicEventRegistry | `0x4a7526A068e5DDE9788f6571E4A99095b14C6fff` | Forta-style detection-bot alerts |
| AereTravelRuleHashRegistry | `0xcF0E2e010E6e4506672019b1e570874AEeBC4c84` | FATF Travel Rule hash anchor |
| AereCompliancePoolV2 | `0xB144c923572E5Ac1B6B961C4ccfec36917173465` | Compliant privacy pool |
| AereCompliancePoolSP1Verifier | `0xE2D3fa91b680E835c971761ba75Fde0204AEF95E` | SP1 adapter for the pool |
| AereAttestationGateway | `0x9bdacA8dfF39Fc688e8D3c4bbA13bCFC0580c325` | Regulator-attestation schema registry |

## 2. AereIdentity (live)

Address `0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1`, owner Foundation. Solidity `^0.8.19`. This is the oldest and simplest contract in the stack, deployed 2026-05-07 with the core batch.

It is a lightweight on-chain DID registry, compatible in spirit with W3C DID and ERC-1056. Three primitives:

- Profiles. `setProfile(string uri)` lets any address point at a content-addressed profile document (for example `ipfs://...`). Only the pointer and a timestamp live on-chain.
- Attestors. The owner maintains an allowlist (`isAttestor`) of trusted issuers (KYC providers, employers, communities). `addAttestor` / `removeAttestor` are owner-only.
- Claims. An attestor calls `issueClaim(subject, claimType, expiresAt, evidence)`. `claimType` is a keccak256 tag, for example `keccak256("KYC_TIER_1")`, `keccak256("AGE_OVER_18")`, `keccak256("EMAIL_VERIFIED")`. `evidence` is an optional hash of an off-chain document. Claims are keyed `subject -> claimType -> attestor`, so a subject can hold the same claim type from several attestors independently. `revokeClaim` lets the issuing attestor (and only the issuer) revoke. `hasValidClaim(subject, claimType, attestor)` returns true if the claim exists, is not revoked, and is not expired.

Honest scope and limitations:

- Claims are plaintext booleans on-chain. `AereIdentity` reveals that a given address holds a given claim type from a given attestor. It is a transparency-positive, privacy-negative design. It is appropriate for public credentials (DAO membership, "email verified") and inappropriate for anything a user would want to keep private (residency, exact KYC tier). The zero-knowledge path for sensitive attributes is `AereZKScreen` (Section 3), not this contract.
- The evidence field is a bare hash with no schema. `AereAttestationGateway` (Section 10) is the newer, schema-versioned, inheritance-aware successor for structured attestations; `AereIdentity` remains the simple key-value DID layer.
- Ownership is a single `owner` address (the Foundation), not a per-claim governance model. There is no on-chain dispute path for a bad claim beyond the issuer's own `revokeClaim`.

Roadmap: a thin adapter that lets a dApp read an `AereZKScreen` clearance and an `AereIdentity` claim behind one interface is planned but not deployed. Today they are queried separately.

## 3. AereZKScreen v3: zero-knowledge attribute proofs (live anchor; over-18 program pending Foundation registration)

Address `0x3A097A459FD26aC79573aCB5adB51430e473C2f1` (v3), owner Foundation, SP1 verifier fixed at deploy to the gateway `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628` (SP1 Groth16, selector `0x4388a21c`). Deploy tx `0xf527bdcf1ccdbf41db27237b1004699335078a66f6a04a630554bbd2e1b468f5`, deployed 2026-07-07. This is a Privacy-Pools-style compliance anchor: it records that a user passed an off-chain screen without any of the source data touching the chain.

### 3.1 Model

The Foundation registers "programs." A program is one compliance statement, identified by its SP1 `programVKey` (the verification key of a specific guest circuit). Examples the design targets: an over-18 attribute proof, an EU-jurisdiction / MiCA-eligibility proof, an accredited-investor proof, an OFAC-screen proof. A user runs the corresponding SP1 program off-chain, produces a Groth16 proof, and calls `submitProof(programVKey, publicValues, proof)`. On success the contract stamps `clearedAt[user][programVKey]`. dApps gate access by reading `isCleared(user, programVKey, minTimestamp)`.

The public-values convention is exactly `abi.encode(uint256 chainId, address user, uint256 attestedAt, bytes32 extraDataHash)`, a fixed 128 bytes. `submitProof` enforces the exact length (rejecting trailing-byte spoofs), checks `chainId == block.chainid`, checks `user == msg.sender`, and rejects a proof whose `attestedAt` is in the future or older than the current stored clearance (stale-proof downgrade protection).

### 3.2 The root-binding soundness fix (why v1 and v2 are dead)

This is the most important design decision in the contract, and it is worth being candid that the first two deployments got it wrong.

- v1 `0xE9da9c5F40c2CDfda368885832C59609286e04ee` (dead): declared the SP1 verifier interface as `returns (bool)`. The real SP1 gateway returns nothing and reverts on an invalid proof, so decoding a bool from empty returndata reverted even for valid proofs. `submitProof` could never succeed. Fixed in v2 with a void interface plus try/catch.
- v2 `0x140572e018C0342336dbaAa1713281c15678aFa7` (dead, self-clear hole): the proof commits an `extraDataHash` interpreted as the allowlist Merkle root the screen was checked against. Because the prover supplies that root inside the zkVM, anyone could prove membership in a root of their own making (an "allowlist" containing only themselves), a total soundness break for the compliance claim.
- v3 (live) closes it: each program binds a Foundation-set `authorizedRoot`, and `submitProof` requires `extraDataHash == authorizedRoot` (revert `UnauthorizedRoot` otherwise). The Foundation rotates the root via `setAuthorizedRoot` as the real allowlist changes, and can void an individual clearance via `revoke(user, programVKey)`, which sets a per-user watermark so a clearance whose `attestedAt` is at or below the watermark reads as invalid.

`isCleared` also enforces an optional per-program `expirySeconds`. The contract source explicitly instructs consumers to pass a real `minTimestamp` (for example `block.timestamp - freshnessWindow`), never 0, and to treat clearance as necessary-not-sufficient, ANDing it with a live sanctions check for sanctions-sensitive flows.

### 3.3 The over-18 circuit (real; deep dive)

The guest program lives at `zk-circuits/recursive-aggregation/over18-program/src/main.rs`. It proves in zero knowledge that the prover holds an issuer-attested birth-year credential AND that the birth year implies adulthood, without revealing the birth year.

Mechanics:

- A Foundation-approved KYC issuer publishes a Merkle root of `keccak256(birthYear || user)` leaves for the people it has verified.
- The circuit reads public inputs (chainId, user, attestedAt, root) and private witness (birthYear, Merkle depth, and the sibling path).
- It asserts `birthYear <= MAX_ADULT_BIRTH_YEAR`, where `MAX_ADULT_BIRTH_YEAR = 2008` is a compile-time constant baked into the verification key. This makes the program a dated "adult as of 2026" attribute; it must be recompiled next year to advance the threshold. That is an honest design tradeoff (the constant is part of the vKey, so a stale program cannot silently drift).
- It rebuilds the leaf `keccak256(birthYear.to_be_bytes || user)` and walks the witnessed path to the root, asserting membership. It commits exactly the `AereZKScreen` tuple, with `extraDataHash` carrying the issuer credential-tree root, so the same v3 contract anchors it.

Provenance: this circuit was proven end-to-end and its on-chain SP1 verification key is `0x005aa94ac711bc65d0755b3a94f3622a6e8c76e2cdd708c29869587f633343c5` (it also appears as a leaf in AERE's recursive proof-aggregation demo, alongside the general `zkscreen` program vKey `0x006a211015aee2b90b82d266bef3aa6944551b06c488d86e895489b1dde3e5b7`).

Honest status: the over-18 circuit is real and the proof pipeline works, but registering it as a live program on the canonical v3 anchor (`registerProgram(programVKey, expirySeconds, authorizedRoot, description)`, which is `onlyOwner`) with a Foundation-set `authorizedRoot` is pending a Foundation signature. Until that signature lands, `submitProof` for the over-18 program reverts `UnknownProgram` on the live contract. Mark this as in-development, not shipped.

### 3.4 EU-jurisdiction and other attribute programs (archetype; in development)

The v3 contract is program-agnostic: any SP1 circuit that commits the four-field tuple and binds an authorized root can be registered. The EU-jurisdiction / MiCA-eligibility proof, the accredited-investor proof, and the OFAC-screen proof are described in the contract as the intended program set, and they follow the identical pattern (issuer-attested credential root, in-circuit predicate over a private attribute, `extraDataHash == authorizedRoot`). Of these, only the over-18 circuit has a real guest program in the repository today. The others are archetypes on the same rail and should be presented as roadmap, not as live capabilities.

## 4. AereSanctionsRegistry: the OFAC Merkle registry (live), and the inclusion-vs-absence question

Address `0xb7d235718D99560F6EA4Fc5eAea2F8a306A3Cacf`, `Ownable`, owner Foundation, Solidity `0.8.23`. This is a read-only, public-good sanctions registry. There is no fee and no discretionary interception.

### 4.1 How it works

Each epoch (a 24h cron), an off-chain ingester reads the official OFAC Specially Designated Nationals (SDN) list from `treasury.gov`, extracts crypto addresses where present, builds a keccak256 Merkle tree, and the Foundation publishes the root. Leaf format: `keccak256(abi.encode(address evmAddress, uint16 listId))`, where `listId` distinguishes the source list. The contract reserves `1 = OFAC SDN`, `2 = OFAC SSI`, `3 = EU consolidated`, `4 = UK HMT`, `5 = UN consolidated`; Phase 1 ships OFAC SDN only.

Lifecycle per epoch is optimistic, mirroring the NAV oracle pattern: `Proposed -> (Challenged?) -> Attested`. `proposeSnapshot(epoch, root, sourceUrl, ipfsCid)` is owner-only and records the canonical OFAC URL the root was built from plus an optional IPFS CID pinning the full list. Anyone may `challenge(epoch, reason)` within the 24h `CHALLENGE_WINDOW`; the Foundation may `dismissChallenge`. After the window elapses with no open challenges, anyone may `attest(epoch)`, which freezes the root. History is append-only; attested epochs cannot be rewritten, and there is deliberately no "deSanction" path (removing an address would imply the Foundation is making a sanctions decision, which it is not; it only mirrors the canonical list).

Consumers call `isSanctioned(epoch, evmAddress, listId, proof)`, which returns true only if the snapshot is attested AND the Merkle inclusion proof verifies. `isSanctionedLatest(evmAddress, listId, proof)` walks back from the latest epoch to the most recent attested snapshot, bounded at `MAX_EPOCH_SCAN = 64` to prevent a griefable DoS (a Round-3 audit fix).

### 4.2 Inclusion, not absence (the honest core of this contract)

`isSanctioned` is an inclusion proof. It proves that an address IS on the list at a given epoch. It does NOT prove absence. A standard keccak256 Merkle root supports membership proofs only; proving non-membership would require a sorted or sparse Merkle tree (an SMT), which this is not. Consequently:

- "This address is sanctioned" can be proven trustlessly on-chain (given the proof).
- "This address is clean" cannot be proven by this contract. The best a consumer can do is: no valid inclusion proof was supplied. That is a much weaker, trust-the-published-list statement, and it depends on the caller (or an indexer) to actually attempt the lookup rather than skipping it.

For flows that need a positive "clean" assertion, the design intent is to compose this with a positive-allowlist primitive: the compliance pool's association-set inclusion proof (Section 8) or a ZKScreen OFAC-screen program (Section 3.4). Presenting the sanctions registry alone as "sanctions-clean gating" would overstate it, and this spec does not.

### 4.3 Trust and liveness

The published root is Foundation-attested through a Foundation-controlled key (Ledger-signed); the Foundation control point on chain 2800 is a single-key account today, not a deployed multisig (a Safe multisig is roadmap). The optimistic window lets anyone challenge a bad root, but a challenge only forces a dismissal decision; it does not itself prove the root wrong. The ultimate ground truth is the off-chain OFAC list, and the `sourceUrl` plus `ipfsCid` fields exist so third parties can reproduce and audit the tree. This is honest optimistic security, not trustless.

## 5. ChainalysisOracleWrapper (deployed; inert on 2800 until an upstream is set)

Address `0x1B7Be82C80f368f75Cb3807B1bc05E86A498f85c`, `Ownable`, owner Foundation. Chainalysis publishes a free public `isSanctioned(address)` oracle on Ethereum mainnet and other major chains. This wrapper gives AERE dApps a single stable endpoint with the same interface, forwarding a `STATICCALL` to a configured upstream. On any upstream error (paused, migrated, not present) it returns false rather than reverting, so a consumer is never bricked.

Honest caveat: the Chainalysis oracle is not natively deployed on chain 2800. `upstreamOracle` is settable once by the Foundation via `setUpstream` and frozen by `lockUpstream`. Until an upstream is configured, `isSanctioned` returns false for every address, meaning the wrapper is effectively inert and must not be relied on as the sanctions source. The real on-chain sanctions signal today is the Merkle registry in Section 4. The wrapper is scaffolding for a future Chainalysis (or equivalent) presence on 2800, and it should be labeled as such.

## 6. AereForensicEventRegistry (live)

Address `0x4a7526A068e5DDE9788f6571E4A99095b14C6fff`, `Ownable`, owner Foundation, Solidity `0.8.23`. An open, Forta-style registry where detection bots post structured alerts about suspicious on-chain activity. Bots self-register (`registerBot`), then `emitAlert(botId, subject, alertType, severity, detailUri)`. The alert taxonomy runs 0 (catch-all) through 9 (rug-pull pattern), including 1 (sanctioned-flow), 2 (sandwich/MEV), 5 (bridge exploit), 8 (honeypot). Severity runs 1 (info) to 5 (critical). Consumers read `recentConfirmedAlertCount(subject, minSeverity, windowSeconds)`, bounded at `MAX_RECENT_ITERATIONS = 256` (a Round-3 DoS fix, so an attacker spamming millions of low-severity alerts cannot revert a consumer's in-transaction query).

Honest scope: registration is permissionless, but in Phase 1 only the Foundation confirms alerts (`confirmAlert`), and the read that consumers gate on counts CONFIRMED alerts only. So the trust anchor is again the Foundation. Stake requirements are 0 in Phase 1 (purely reputational); an AERE bond plus staked-community confirmation is described as a Phase 2 item and is not built. This registry is an audit and signaling surface with no custody and no transaction interception.

## 7. AereTravelRuleHashRegistry (live)

Address `0xcF0E2e010E6e4506672019b1e570874AEeBC4c84`, Solidity `0.8.23`, no admin. This is the on-chain anchor for FATF Travel Rule message exchanges (Notabene / IVMS-101 compatible). The Travel Rule requires VASPs to exchange identity payloads for transfers above a jurisdiction threshold (roughly USD 1,000 for the US, EUR 1,000 under EU MiCA). The payloads are confidential and exchanged off-chain over a message bus. This contract anchors only a commitment.

Flow: the originating VASP calls `commit(payloadHash, beneficiaryVasp, threshold)`, storing a keccak256 hash of the IVMS-101 payload, the two VASP addresses, the threshold (USD cents), and a timestamp; the id is indexed under both VASPs for audit retrieval. The beneficiary VASP later calls `acknowledge(id)` to mark receipt and verification, or `dispute(id, reason)` if the on-chain hash does not match what was exchanged. No payload data, and no identity, is ever stored on-chain. The anchor proves the payload existed at a specific block, is append-only, and is auditable by regulators without revealing content.

Design notes and honesty: there is no admin, no Foundation interception, and no custody. The contract is genuinely trust-minimized in the narrow sense that it is just an append-only commitment log; the VASPs self-identify via `msg.sender` and there is no on-chain VASP allowlist, so the registry does not itself vouch that a committing address is a licensed VASP (that verification is off-chain, and can be layered via `AereAttestationGateway`). It is a minimal viable Travel Rule anchor, Phase 1.

## 8. AereCompliancePoolV2: the compliant privacy pool (live; 0 deposits)

Address `0xB144c923572E5Ac1B6B961C4ccfec36917173465`, Solidity `0.8.23`, `ReentrancyGuard`. Deploy tx `0xca77b3a125ac2c9ae3687031e40c7e3e216300158c5785b0583fa231dce5fb85`, block 8910143. It denominates in WAERE (`0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8`) with a fixed `DENOMINATION` of 1 WAERE, `FOUNDATION` set to the Foundation account (single-key, not a deployed multisig), and `VERIFIER` set to the reused SP1 adapter `0xE2D3fa91b680E835c971761ba75Fde0204AEF95E` (program vKey `0x00aa183a...`). `POOL_ID` is `0x100bc0276cfe121913b849d9804a1575cb9894d7db22561eafe9a8ab50f747c8`. It is a fresh pool: `depositCount` is 0. Present it honestly as a working, tested primitive with no real usage yet.

### 8.1 The Privacy Pools + Travel Rule construction

This is Ameen Soleimani / Vitalik-style Privacy Pools, hybridized with a Travel Rule hook. The core is an append-only keccak256 Merkle tree, `TREE_DEPTH = 20` (capacity 2^20 = 1,048,576 notes), with a rolling 256-root history (`ROOT_HISTORY_SIZE = 256`) so a withdrawal can prove against any recent deposit root. `ZERO_VALUE` is `keccak256("aere.compliance-pool.v1.empty-leaf")`. These parameters are byte-for-byte identical to the v1 pool, which is what lets the same off-chain SP1 circuit and the same deployed verifier keep working.

Deposit path: `deposit(commitment, travelRuleHash, complianceProvider, travelRuleUri)`. The `complianceProvider` must be on a Foundation-managed allowlist (`isComplianceProvider`, set via `setComplianceProvider`). The actual leaf inserted is `keccak256(commitment || msg.sender)` (an R5 leaf-binding fix so a deposit note is bound to its depositor). The `travelRuleHash` and `travelRuleUri` carry the off-chain Travel Rule commitment for the deposit, tying this pool to Section 7's regime.

Withdraw path: `withdraw(proof, depositRoot, associationRoot, nullifierHash, recipient, feeRecipient, fee, refund)`. The contract checks the nullifier is unspent, the `associationRoot` is published (see 8.2), and the `depositRoot` is a known recent root, then calls the SP1 verifier over eight public inputs `[poolId, depositRoot, associationRoot, nullifierHash, recipient, feeRecipient, refund, fee]`. The SP1 guest proves: `commitment = keccak256(secret || nullifier)`; `actualLeaf = keccak256(commitment || depositor)`; `depositRoot` is the Merkle root over the deposit tree containing that leaf; `associationRoot` is the Merkle root over the "clean" subset containing that same leaf; `nullifierHash = keccak256(nullifier)`; and recipient / feeRecipient / refund / fee are all bound so a front-runner cannot substitute them.

### 8.2 Inclusion in a Foundation-attested clean set (the honesty crux)

The compliance property is a positive inclusion proof, not an absence proof. To withdraw, a user proves their note is a member of the association root, which is a Foundation-published Merkle root over the subset of deposits judged "clean" (an Association Set Provider model). This is the honest, correct way to do compliant privacy: the user demonstrates they are in the good set, rather than the impossible-to-verify claim that they are not in some bad set. The tradeoff is explicit: the clean set is Foundation-curated, so a user whose legitimate deposit the Foundation omits cannot withdraw with privacy until included. That is a real centralization point and we state it.

Association roots go through an optimistic lifecycle with a bond, matching the sanctions registry philosophy:

- `proposeAssociationRoot(root)` is Foundation-only.
- `challengeAssociationRoot(root, reason)` is permissionless but requires a `CHALLENGE_BOND` of 100 tokens (100 WAERE), capped at `MAX_DISMISSALS_PER_ROOT = 2`.
- The Foundation may `dismissAssociationRootChallenge` a provably-bad challenge within the 24h window (`ASSOCIATION_ROOT_CHALLENGE_WINDOW = 86400`), which burns the bond to the dead address and restarts the publish window.
- `publishAssociationRoot(root)` finalizes after the window with no active challenge; `withdraw` then accepts it.

### 8.3 The F8 fix (why v1 is dead)

The v1 pool `0x79735c31F289F7A4d6Be3E02aaB70B544796D41d` (0 deposits, left on-chain, harmless) had a real bug: `challengeAssociationRoot` pulled the 100-token bond but there was no path to return it to an honest challenger. If the Foundation dismissed, the bond was burned; if the Foundation simply never acted, the root stayed "challenged" forever with the bond locked. An honest challenger who was right always lost 100 tokens.

V2 fixes this. A challenge now resolves one of two ways. DISMISSED: the Foundation dismisses within the window, the bond is burned to `0x...dEaD` exactly as v1 (preserving the anti-grief property, so griefing a valid root still costs the bond). UPHELD: if the Foundation fails to dismiss within the window, anyone can call `reclaimUpheldChallenge`, which refunds the bond to the challenger and permanently rejects the root (`associationRootRejected`), so a questioned set is never published. That is the safe default for a compliance pool. This was demonstrated live on a byte-identical, deployer-owned twin (`0x736c249F458E9d0E0F97cD03427004a40a77337f`, masked-immutable bytecode identity to the canonical): an upheld reclaim refunded 100 and rejected the root (`reclaimTx 0x609d20af...`), a dismissed challenge burned 100 to dead without refund (`dismissTx 0x45d452e3...`), and a dismissed-then-quiet valid root published (`0x41117e01...`).

Residual risk, stated plainly: there is a liveness assumption on the Foundation. It must dismiss baseless challenges within the window, otherwise the challenge stands and the root is rejected (bond refunded). This fails safe toward challengers and is strictly better than v1, but it is not a trustless mechanism, and a Foundation that goes offline can have valid roots rejected by a single unanswered challenge.

## 9. AereCompliancePoolSP1Verifier (live)

Address `0xE2D3fa91b680E835c971761ba75Fde0204AEF95E`. A thin adapter bridging the pool's `IPrivacyPoolVerifier.verify(bytes proof, uint256[] pubs)` interface to the SP1 gateway. It ABI-encodes the eight public inputs into the exact struct the Rust guest commits (`pool_id, deposit_root, association_root, nullifier_hash, recipient, fee_recipient, refund, fee`), then does a low-level `staticcall` to `SP1.verifyProof(PROGRAM_VKEY, publicValues, proof)`, returning true iff it does not revert. Both `SP1` and `PROGRAM_VKEY` are constructor immutables. The off-chain prover is the SP1 program at `zk-circuits/compliance-pool/program`; keccak256 hashing and `TREE_DEPTH = 20` in the circuit must match the contract, which they do.

## 10. AereAttestationGateway (live)

Address `0x9bdacA8dfF39Fc688e8D3c4bbA13bCFC0580c325`, Solidity `0.8.23`, `FOUNDATION` immutable. A unified, schema-versioned attestation registry for regulator judgments (MiCA CASP licence, EU AI Act conformity, SEC 1099-DA broker reporting, FCA / FINMA / MAS equivalents). It is the structured successor to `AereIdentity` claims.

Model: the Foundation publishes append-only `Schema` records (id, spec hash, semver, spec URI). Per schema, the Foundation authorizes specific attestor addresses (`setAttestor`), which may be the Foundation itself or, for some schemas, the customer's own NCA-registered auditor. An authorized attestor calls `attest(schemaId, subject, parentId, payloadHash, validFrom, validUntil, payloadUri)`; only the hash and validity window live on-chain, no PII. Attestations support optional inheritance (a child references a parent, and validity chases the chain, so a revoked or expired ancestor invalidates the child), bounded by `MAX_INHERITANCE_DEPTH = 8`. Two audit fixes are worth noting: HIGH #23 requires a parent to attest the same subject (no fabricating transitive trust across unrelated subjects), and HIGH #24 only overwrites the schema-wide `latestFor` pointer when the prior is invalid or the new attestation is currently valid (no griefing a valid record with an already-expired one). The source estimates `attest()` at roughly 70k to 80k gas cold-path (a source-code estimate, not a measured figure). Revocation is issuer-only and permanent; `isValidNow` and `subjectCurrentlyAttested` are the read paths.

## 11. Trust model summary and inclusion-vs-absence table

The single most important honesty point for this stack: which statements are cryptographically trustless, which are optimistic (trust-plus-challenge-window), and which are plain Foundation attestations.

| Primitive | What it proves | Proof type | Trust anchor |
|---|---|---|---|
| Sanctions registry `isSanctioned` | address IS on OFAC SDN at epoch | Merkle inclusion | optimistic (Foundation root + 24h challenge) |
| Sanctions registry "clean" | (cannot prove absence) | none available | not provided; do not imply it |
| Compliance pool withdraw | note IS in the clean association set | ZK inclusion (SP1) | optimistic; clean set is Foundation-curated |
| ZKScreen over-18 | birth year in issuer tree AND <= 2008 | ZK inclusion + predicate (SP1) | issuer credential root (Foundation-approved issuer); program registration pending |
| ZKScreen EU-jurisdiction / others | archetype, same rail | ZK (roadmap) | roadmap, not live |
| Travel Rule anchor | a payload hash existed at a block | hash commitment | trustless log; VASP identity is off-chain |
| Attestation gateway | a body attested a subject | signed on-chain record | the attestor (Foundation or auditor) |
| Forensic registry | a bot alerted, Foundation confirmed | on-chain record | Foundation confirmation (Phase 1) |
| Chainalysis wrapper | upstream says sanctioned | forwarded call | inert on 2800 until upstream set |
| AereIdentity claim | attestor issued a claim | plaintext on-chain flag | the attestor; no privacy |

Foundation-attested pieces, gathered in one place so nothing is buried: the sanctions Merkle root, the compliance-pool association (clean-set) root, the ZKScreen per-program `authorizedRoot`, the attestation-gateway schemas and attestor authorizations, the compliance-pool provider allowlist, and the forensic-registry alert confirmations are all Foundation-gated. The optimistic challenge windows (sanctions registry, compliance pool) reduce but do not eliminate this trust, and they carry a Foundation liveness assumption. We consider stating this an asset, not a weakness to hide: a compliance stack that pretends to be trustless when it is optimistic is worse than one that is honest about where the trust sits.

## 12. Roadmap and not-yet-live items

- Over-18 program registration on the canonical ZKScreen v3 anchor (a Foundation `registerProgram` call with the authorized issuer root): pending one Foundation signature. The circuit and proof pipeline are real; the live registration is not yet on-chain.
- EU-jurisdiction / MiCA-eligibility, accredited-investor, and OFAC-screen ZKScreen programs: archetypes on the same rail, guest circuits not yet in the repository.
- Chainalysis wrapper upstream: no Chainalysis (or equivalent) oracle deployed on chain 2800; `setUpstream` / `lockUpstream` not yet called.
- Sanctions registry additional lists (SSI, EU, UK HMT, UN): list ids reserved, Phase 1 ships OFAC SDN only.
- Non-membership (absence) proofs: not provided by any current primitive; would require a sparse/sorted Merkle tree, which is a future design item, not present today.
- Forensic registry staked confirmation and AereIdentity-to-ZKScreen adapter: designed, not built.
- External security audit of the whole stack: not performed.

## Appendix: canonical addresses (verbatim from sdk-js/src/addresses.ts)

- Foundation account (single-key, Foundation-controlled, not a deployed multisig): `0x0243A4f47D44b40b65D33f20329dE20D00c6f3C3`
- WAERE: `0x7e84d7d66d5da4cfE46Da67CDEeB05B323e1f5e8`
- AereIdentity: `0x658dD2CD1F798AAb19fEc8FF69A270B2d192CaD1`
- AereZKScreen (v3, live): `0x3A097A459FD26aC79573aCB5adB51430e473C2f1`
- AereZKScreen v2 (dead, self-clear hole): `0x140572e018C0342336dbaAa1713281c15678aFa7`
- AereZKScreen v1 (dead): `0xE9da9c5F40c2CDfda368885832C59609286e04ee`
- AereSanctionsRegistry: `0xb7d235718D99560F6EA4Fc5eAea2F8a306A3Cacf`
- ChainalysisOracleWrapper: `0x1B7Be82C80f368f75Cb3807B1bc05E86A498f85c`
- AereForensicEventRegistry: `0x4a7526A068e5DDE9788f6571E4A99095b14C6fff`
- AereTravelRuleHashRegistry: `0xcF0E2e010E6e4506672019b1e570874AEeBC4c84`
- AereCompliancePoolV2 (canonical): `0xB144c923572E5Ac1B6B961C4ccfec36917173465`
- AereCompliancePool v1 (deprecated, 0 deposits): `0x79735c31F289F7A4d6Be3E02aaB70B544796D41d`
- AereCompliancePoolSP1Verifier: `0xE2D3fa91b680E835c971761ba75Fde0204AEF95E`
- AereAttestationGateway: `0x9bdacA8dfF39Fc688e8D3c4bbA13bCFC0580c325`
- SP1VerifierGateway: `0x9ca479C8c52C0EbB4599319a36a5a017BCC70628`