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:

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.