aere-docs/AERE-ERC8004-X402-CONFORMANCE.md

# Aere Network: ERC-8004 and x402/AP2 Conformance

Status: adapters built and tested. The live deployed agent contracts are unchanged. Adoption of these
standards by the wider agent ecosystem is external to Aere and is not something Aere controls.

This document describes how Aere Network conforms to two emerging agent standards through THIN ADAPTERS
over its already deployed, live agent stack, and where Aere adds something no one else has: an on-chain
Validation registry and AP2 style mandates whose proofs are POST-QUANTUM signatures (Falcon-512,
ML-DSA-44), verified in full on-chain by Aere's live native precompiles.

- ERC-8004 ("Trustless Agents") standardizes on-chain agent Identity, Reputation, and Validation
  registries on top of the A2A (Agent-to-Agent) protocol.
- x402 (Coinbase) and AP2 (Google, Visa, and partners) standardize agent payment authorizations and
  mandates.

Conforming to these kills the isolation risk of running a private agent trust layer: an Aere agent
becomes discoverable, rateable, and payable by any tool that speaks these standards. Aere's differentiator
is that the trust and payment proofs can be quantum-durable, while everyone else's are ECDSA and therefore
quantum-forgeable.

Scope boundary (honest): these are APPLICATION LAYER adapters and verifiers. They do NOT make Aere
consensus post-quantum. Aere blocks are still produced and signed by Besu QBFT validators with classical
secp256k1 ECDSA. What is post-quantum here is the AUTHENTICITY of a validation response and of a payment
mandate, verified by the live precompiles.

## What was built

New directory `aerenew/contracts/contracts/erc8004/`:

| File | Role |
| --- | --- |
| `IERC8004.sol` | The modeled ERC-8004 Identity, Reputation, and Validation registry interfaces. |
| `AereIdentityRegistry8004.sol` | ERC-8004 Identity adapter over the deployed AereAgentDID. |
| `AereReputationRegistry8004.sol` | ERC-8004 Reputation adapter over the deployed AereAIReputation. |
| `AereValidationRegistry8004.sol` | ERC-8004 Validation registry with POST-QUANTUM proofs (the differentiator). |
| `AereAP2MandateVerifier.sol` | x402/AP2 payment mandate verifier with a Falcon-512 (PQC) mandate signature. |

Test: `aerenew/contracts/test/erc8004-adapters.test.js` (18 passing, see "Test result" below).

The adapters take the live contract addresses in their constructors and wrap them. They never redeploy
or modify the underlying deployed primitives.

## Live deployed primitives being adapted (Aere mainnet, chain 2800)

| Primitive | Address | Notes |
| --- | --- | --- |
| AereAgentDID | `0xce641d7d7C10553D82b06B7C21d423550e7522C5` | Falcon rooted agent identity; agent id is the Falcon root key id. |
| AereAIReputation | `0x781ef746c08760aa854cDa4621d54db6734bfeBF` | Composable reputation keyed by (operator, agentId); attestor set fixed at deploy (Foundation). |
| AereAgentBond | `0x32E0015F622a8719d1C380A87CE1a09bcd0cB86A` | Slashable stake feeding the reputation score. |
| AerePQCKeyRegistry | `0x1eCa3c5ADcBD0b22636D8672b00faC6D89363691` | PQC public key registry; `verifyWithKey` routes to the live precompile for the key's scheme. |
| AERE402FacilitatorV2 | `0xFC2f7FAa94919caF1126b3c995F0F6AcCef291de` | HTTP 402 settlement rail (classical hot session signature), 25 bps fee to AereSink. |
| AERE402FacilitatorPQC | READY, not yet deployed | Falcon rooted settlement rail (built and tested). |
| AereSink | `0x69581B86A48161b067Ff4E01544780625B231676` | Immutable 3 bucket fee router. |

Live native precompiles (activated on mainnet 2800 at block 9,189,161):

| Scheme | Precompile | Standard |
| --- | --- | --- |
| Falcon-512 | `0x0AE1` | NIST FIPS 206 draft line |
| ML-DSA-44 | `0x0AE3` | NIST FIPS 204 (Dilithium2) |

## ERC-8004 mapping table

| ERC-8004 requirement | Aere adapter (function) | Underlying live contract (call) |
| --- | --- | --- |
| Identity: register an agent with a DID and metadata URI | `AereIdentityRegistry8004.register(agentId, agentDomain, agentCardURI)` | AereAgentDID.agentExists + AerePQCKeyRegistry.ownerOf (controller gate); metadata stored in the adapter (the live DID carries no AgentCard URI). |
| Identity: resolve an agent | `AereIdentityRegistry8004.getAgent / resolveByDomain / resolveByAddress` | AereAgentDID (agent existence) + AerePQCKeyRegistry.ownerOf (current controller as agentAddress). DID string `did:aere:<chainId>:<agentId>`. |
| Reputation: attest feedback | `AereReputationRegistry8004.giveFeedback(agentId, delta, evidenceHash, uri)` | AereAIReputation.attest(operator, bytes32(agentId), delta, evidenceHash, uri). |
| Reputation: read feedback | `AereReputationRegistry8004.getScore / getStats` | AereAIReputation.scoreOf / statsOf (read straight from the deployed contract). |
| Validation: request | `AereValidationRegistry8004.requestValidation(validatorKeyId, serverAgentId, dataHash)` | AerePQCKeyRegistry (validator key ACTIVE + Falcon-512/ML-DSA-44) + AereAgentDID.agentExists (server agent). |
| Validation: respond with a proof | `AereValidationRegistry8004.respondValidation(requestId, response, pqcProof)` | AerePQCKeyRegistry.verifyWithKey -> live precompile 0x0AE1 / 0x0AE3 (full on-chain PQC verification, fail-closed). |

### Identity mapping detail

The ERC-8004 agent id IS the AereAgentDID agent id, which is the Falcon ROOT key id in AerePQCKeyRegistry
(`agentId == rootKeyId`). So an ERC-8004 resolve is a direct pass-through to the live DID: the agent's
on-chain root of authority is a quantum-durable Falcon key, not a bare secp256k1 address. `register` does
not mint a new identity (it already exists in the live DID). It binds an ERC-8004 AgentCard URI and domain
to an existing DID agent, gated to that agent's current controller (the registry owner of the Falcon root
key), so only the party that proved Falcon possession can publish the agent's ERC-8004 metadata.

`[VERIFY: confirm against the finalized ERC-8004 interface]` The newer ERC-8004 Identity draft leans toward
an ERC-721 registration (`register(tokenURI)` minting a sequential id). Aere anchors the ERC-8004 identity
to the pre-existing Falcon rooted DID id instead, because the trust root is the on-chain Falcon key rather
than a token. The resolve, getAgent, and AgentCard URI semantics match ERC-8004; the id minting selector
differs by design and is documented in the contract NatSpec.

### Reputation mapping detail

The live reputation is keyed by (operator address, bytes32 agentId). The adapter derives operator as the
agent's current controller (resolved from the Identity adapter) and agentKey as `bytes32(agentId)`, so an
ERC-8004 read or write addresses exactly one live reputation slot, deterministically.

Honest write constraint: AereAIReputation's attestor set is fixed at its deploy and has no add path. For
`giveFeedback` to land in the live score, the adapter must be a registered attestor on the reputation
instance it is constructed with. The currently live AereAIReputation lists the Foundation attestor only
(immutable), so pairing this adapter for write-through is a Foundation governance decision, external to this
contract and founder gated. `[VERIFY: on mainnet, register this adapter as an attestor before relying on
giveFeedback, or have the Foundation attestor call the live attest directly.]` The READ path needs no such
authorization and adapts the currently deployed instance as is. The adapter surfaces this with
`canWriteThrough()` and a clear `AdapterNotAttestor` revert, and the test proves both the authorized
write-through path and the unauthorized honest revert.

`[VERIFY: confirm against the finalized ERC-8004 interface]` Later ERC-8004 reputation drafts carry a richer
feedback payload (score, tag, response URI). Here the feedback signal is normalized to the live model's
delta in {-1, 0, +1} so no information is invented beyond what the deployed contract records.

## The post-quantum differentiator: Validation registry

`AereValidationRegistry8004` is the piece no other agent stack offers. It exposes the ERC-8004 Validation
surface (request and respond with a proof), where the validator's RESPONSE proof is a POST-QUANTUM signature
(Falcon-512 or ML-DSA-44), verified in full ON-CHAIN by Aere's live native precompiles (0x0AE1, 0x0AE3)
through the deployed AerePQCKeyRegistry.

Flow:

1. `requestValidation(validatorKeyId, serverAgentId, dataHash)`. Records a request that the PQC validator
   identified by `validatorKeyId` validate the work the server agent committed to via `dataHash`. The
   validator key must be an ACTIVE Falcon-512 or ML-DSA-44 key in the registry; the server agent must exist
   in the live AereAgentDID.
2. `respondValidation(requestId, response, pqcProof)`. The validator answers with a score (0..100, the
   ERC-8004 convention) and a PQC signature over the contract's domain separated challenge, which binds
   (requestId, dataHash, serverAgentId, validatorKeyId, response). The signature is verified on-chain via
   the live precompile. On success the response is recorded once. On any invalid or tampered proof the call
   REVERTS and records nothing (FAIL-CLOSED). An empty or zero precompile return (a stale, un-activated
   chain) is treated as INVALID.

Non-replayable and non-forgeable: the challenge binds chainId, this contract, the exact request tuple, and
the response, so a proof for one (request, response) can never be reused for another, another contract, or
another chain. A request completes exactly once. Authorship is the PQC signature alone: respond may be
relayed by any sender, since only the validator private key can produce a valid signature over the contract
bound challenge.

Why it matters: every other agent validation stack authenticates validator responses with ECDSA, which a
quantum computer forges. This one does not. It is the on-chain, post-quantum answer to "prove an independent
validator actually signed off on this agent's output".

## x402 / AP2 post-quantum mandate

`AereAP2MandateVerifier` is a minimal verifier for AP2 style payment MANDATES whose authorizing signature is
POST-QUANTUM (Falcon-512), verified in full on-chain by the live precompile (0x0AE1) through the deployed
AerePQCKeyRegistry. Settlement of the authorized spend routes through the EXISTING AERE402 rail
(AERE402FacilitatorPQC or AERE402FacilitatorV2), which is not redeployed or modified.

The struct:

```solidity
struct Mandate {
    uint256 agentKeyId;   // the paying agent's Falcon-512 key in AerePQCKeyRegistry
    address token;        // the settlement token the cap is denominated in
    uint256 maxAmount;    // cumulative spend cap over the window
    uint64  periodStart;  // unix seconds, inclusive
    uint64  periodEnd;    // unix seconds, inclusive
    bytes32 purpose;      // opaque purpose tag, e.g. keccak256("inference:anthropic")
    uint256 mandateNonce; // per-agent mandate index (lets an agent hold several mandates)
}
```

This encodes the common AP2/x402 authorization: "agent X may spend up to N of token T per period P for
purpose Q". `mandateHash(m)` binds chainId and the verifier address, so a signed mandate cannot be replayed
against another verifier or chain.

The verify path:

- `verifyMandate(m, falconSig)`: a pure on-chain PQC check that the agent's Falcon key signed the mandate
  (view, permissionless, free via eth_call).
- `authorizeSpend(m, amount, falconSig)`: the enforced path. Verifies the Falcon mandate signature via the
  live precompile, checks the validity window and the cumulative cap, records the spend against the mandate,
  and emits `MandateAuthorized`. Fail-closed on any invalid or tampered signature, an out-of-window mandate,
  or a cap overflow. Rotating or revoking the agent's Falcon key halts the mandate immediately.

Settlement routing: `authorizeSpend` records that `amount` is authorized under the mandate; the actual token
movement plus the 25 bps fee to AereSink is performed by the live AERE402 rail. To keep the cumulative cap
honest (only real settlements should consume it), `authorizeSpend` is gated to an immutable
`SETTLEMENT_EXECUTOR` when one is configured (the AERE402 facilitator, which calls it atomically with
settlement). When `SETTLEMENT_EXECUTOR` is the zero address the accounting path is open (for verification and
testing); the pure PQC check `verifyMandate` is always open.

Why it matters: AP2 and x402 mandates today are ECDSA authorizations, quantum-forgeable. An Aere mandate is a
Falcon-512 authorization, quantum-durable, verified on-chain.

`[VERIFY: confirm against the finalized x402 / AP2 mandate schema]` The x402 and AP2 mandate field sets are
still evolving (AP2 distinguishes Intent versus Cart mandates; x402 carries an HTTP 402 payment payload).
This struct captures the common "spend up to N per period for purpose Q" authorization; reconcile the exact
field set and encoding with the final specs before claiming wire level conformance.

## Test result (real)

Command, run from `aerenew/contracts`:

```
npx hardhat test test/erc8004-adapters.test.js
```

Result: 18 passing.

- Identity: register an existing DID agent, resolve by id / domain / controller address, controller only
  register and update, unknown agent and duplicate domain rejection.
- Reputation: forward feedback into the live AereAIReputation and read the score back (attest then read),
  out-of-range delta and unregistered agent rejection, and the honest AdapterNotAttestor revert when the
  adapter is not an authorized attestor (the immutable mainnet case), with the read path still working.
- Validation: a genuine Falcon-512 (0x0AE1) response accepted and recorded, a genuine ML-DSA-44 (0x0AE3)
  response accepted, a tampered proof rejected fail-closed with nothing recorded, a proof bound to a
  different response score rejected, a wiped precompile treated as invalid, and request guards
  (inactive/non-PQC validator key, unknown server agent).
- Mandate: a genuine Falcon mandate verified (pure view) and spend authorized up to the cap, over-cap
  rejected, expired window rejected, tampered signature rejected fail-closed, revoked Falcon key halts the
  mandate, and the settlement-executor gate enforced.

`[MEASURE]` Local Hardhat has no PQC precompile, so the test installs the repo's `MockPQCPrecompile` at
0x0AE1 and 0x0AE3 via `hardhat_setCode`, exactly as the fault-harness `AereRecoveryRegistry` test does. The
mock parses the input at the LIVE precompile's spec offsets and accepts iff commitment equals
keccak256(pk || message), so a positive result proves the adapter routed the correct input to the correct
precompile and enforces fail-closed and non-replay semantics. The REAL precompile path (that the on-chain
0x0AE1 / 0x0AE3 accept a genuine Falcon-512 / ML-DSA-44 signature) is exercised separately against live
mainnet 2800 via eth_call, the same way AerePQCKeyRegistry and AerePQCAttestation are proven, and is not
re-proven inside this unit test. The adapters stay hard-wired to the live registry and precompiles for
production.

## Honest status summary

- The adapters are built and tested. They wrap the live deployed contracts and do NOT redeploy or modify
  them.
- The Identity resolve path and the Reputation read path adapt the currently deployed contracts as is, with
  no change and no authorization.
- The Reputation write-through path requires the adapter to be an authorized attestor on the reputation
  instance; the live instance's attestor set is immutable Foundation-only, so this is an external, founder
  gated governance decision.
- The Validation registry and the AP2 mandate verifier verify Falcon-512 and ML-DSA-44 signatures through the
  live precompiles. This is application layer post-quantum authentication. It does NOT make Aere consensus
  post-quantum.
- Selector level conformance with the final ERC-8004 and x402/AP2 texts is marked `[VERIFY]` wherever the
  specs are still in flux; the adapters implement the documented semantics.
- Whether the wider agent ecosystem adopts these standards is external to Aere and is not something Aere
  controls. What Aere controls is being ready and being the only stack whose agent validation and payment
  mandates can be quantum-durable.