ADR-022: An EAS mirror that only publishes what A-REX says, under chain-independent schemas

Certificates and lot records of an A-REX token are published as Ethereum Attestation Service attestations by a mirror contract that copies the live A-REX record, revokes its copy when A-REX revokes, distrusts or changes the record, and uses two resolver-free revocable schemas whose UIDs are the same on every chain.

Context

EAS is the public-good attestation layer on Ethereum and most of its L2s (deployed at fixed addresses per chain, predeployed at 0x4200…0021 on OP-stack chains). Verifiers, indexers and explorers (easscan) read it without knowing anything about the issuer's own contracts. interop/EAS.md described two ways to connect EAS to IARexAttest (an EAS resolver writing into A-REX, and an IARexAttest reading EAS); both make EAS a source of A-REX state. What companies ask for is the reverse: their A-REX certificates and lots verifiable by anyone on EAS, without A-REX software.

Issue

How can A-REX certificates and lot records be published on EAS so that a verifier using EAS alone is never told something A-REX does not currently say?

Assumptions

• EAS 1.4.0 semantics (eas-contracts 1.9.0): only the attester revokes; an attestation's UID is fixed; a schema UID is keccak256(abi.encodePacked(schema, resolver, revocable)); expiry is enforced by readers.
• Everything published is already public on the token and its attestation registry.

Constraints

• No personal data (ADR-008, ADR-019 originRef rule).
• ADR-019: revocation belongs to the issuer of an attestation. The mirror never revokes an A-REX attestation; it revokes its own copy when the A-REX record no longer holds.
• The token and registry are unchanged.

Alternatives considered

Decision (proposed)

ARexEASMirror (arex-contracts contracts/reference/interop/), one per token and attestation registry:

• Schemas (no resolver, revocable; registered by the mirror's constructor if missing):

  Record	Schema	UID (every chain)
  Certificate	address token,uint256 batchId,bytes32 topic,address issuer,bytes32 ref,uint64 issuedAt,uint64 expiresAt	0x455d976381bd36a20458eb8852e9dcd8c8f87f5ca164817acedb1ad17255615b
  Lot record	address token,uint256 batchId,address issuer,uint64 createdAt,bytes32 commodity,bytes32 unit,uint64 producedAt,uint64 expiresAt,bytes32 originRef,bytes32 metadataHash,string uri,uint8 status,uint256[] parents	0x235bf40b884c6f30eff0d51c33c54e81874329261f553466f8f5d5511c071ed9

• publishCertificate(id, topic) requires isAttested(id, topic) and attests a copy of getAttestation(id, topic) with recipient = the token and expirationTime = the A-REX expiresAt. publishLot(id) attests a copy of batchOf(id) and parentsOf(id). Both are idempotent: an unchanged record returns the existing UID.

• syncCertificate(id, topic) revokes the copy when the certificate is revoked, expired or its issuer is no longer trusted, and replaces it when it changed. syncLot(id) replaces the copy when the record changed (status, metadata). Anyone may call them; they can only make the mirror more accurate.

• isCurrent(uid) is true only if uid is the mirror's current copy and equals the live A-REX record.

• The mirror holds no role in the token and is not a trusted issuer anywhere: it reads A-REX and never writes to it.

• Whether a company mirrors, which records, and on which chains, is policy (ADR-019).

A verifier accepts an attestation when its schema is one of the two above, its attester is the mirror the token's issuer published, it is not revoked or expired, and (if it cannot tolerate the sync delay) isCurrent(uid) is true. The mirror refuses at construction an attestation registry that names another token.

Argument

Making the mirror the attester is what lets revocation follow A-REX: EAS lets only the attester revoke, so a mirror that attests can also withdraw, and it withdraws only when A-REX says the record no longer holds. Copying only live records means the mirror cannot be used to publish a false certificate, whoever calls it. Resolver-free schemas give UIDs that the standard can fix today, before any deployment, and that are the same on every chain.

Consequences

Positive

• Certificates and lots verifiable with EAS alone, on every chain where EAS is deployed, with standard tooling.
• Revocation, distrust and expiry in A-REX reach EAS on the next sync, and immediately through isCurrent.
• Lineage (parents) travels with the lot record.

Negative

• About 470,000 gas per certificate copy and 640,000 to 690,000 per lot record copy (data stored on chain by EAS).
• Between an A-REX change and the next sync, an EAS copy is stale; an implementation must sync on the A-REX events (AttestationRevoked, TrustedIssuerUpdated, Attested, BatchStatusChanged, BatchMetadataUpdated).
• Verifiers must check the attester: anyone can attest under a resolver-free schema.

Obligations it creates

• Implementations publish the mirror's address with the token (in the lot passport, DPP or metadata) and sync on the A-REX events above.
• The conformance clauses EM-1 to EM-4 of interop/EAS.md hold for any implementation.

Implementation and evidence

Related decisions

• ADR-008: no personal data on-chain
• ADR-009: attestations in a companion contract
• ADR-019: capabilities in the standard, policy in profiles; revocation by the issuer
• ADR-020: ERC-3643 compatibility
• ADR-021: ONCHAINID claim issuer