ADR-021: ONCHAINID claims whose validity is A-REX trust, computed live

A company's identity claim (KYB) signed by an issuer that A-REX trusts becomes an ONCHAINID claim through a claim issuer contract that answers isClaimValid from the A-REX trust list at the moment it is asked, so ERC-3643 identity registries accept it while, and only while, A-REX trusts its signer.

Context

ERC-3643 decides who may hold a token with ONCHAINID: each holder's wallet points to an identity contract (ERC-734 keys, ERC-735 claims), and the token's identity registry requires claims of given topics signed by claim issuers it trusts. T-REX's IdentityRegistry.isVerified reads the claim from the identity and asks the claim's issuer contract isClaimValid(identity, topic, signature, data); ONCHAINID's Identity.addClaim asks the same question before it stores a claim. Neither looks at anything else.

A-REX has its own trust model: trusted issuers per topic (IARexAttest.isTrustedIssuer(topic, issuer)), set by the token's administrator, with revocation semantics fixed by ADR-019 (only the issuer, or a revoker it delegated, revokes). Companies onboarded on A-REX are checked (KYB) by issuers A-REX trusts. Without a bridge, a company that wants to hold or trade ERC-3643 tokens must be checked again by an ONCHAINID claim issuer, and a withdrawal of trust on one side is not seen on the other.

Issue

How can a company's A-REX identity standing be presented as ONCHAINID claims that ERC-3643 registries accept, without a second source of truth that can drift from A-REX trust?

Assumptions

• ERC-3643 registries and ONCHAINID identities validate claims only through isClaimValid on the issuer (T-REX 4.1.6, ONCHAINID 2.2.1, verified in their source).
• KYB claims are about companies. The claim data needs no personal data: a hash of the evidence, the ISO 3166-1 numeric country of registration, an expiry.

Constraints

• No personal data on-chain (ADR-008); a claim stored in an identity is public.
• Revocation is the issuer's (ADR-019).
• ONCHAINID claim format: signature over keccak256(abi.encode(identity, topic, data)) with the Ethereum signed-message prefix, scheme 1 (ECDSA), claim id keccak256(abi.encode(issuer, topic)).

Alternatives considered

Decision (proposed)

ARexClaimIssuer (arex-contracts contracts/reference/interop/) implements the claim-issuer part of ONCHAINID's IClaimIssuer:

• isClaimValid(identity, topic, sig, data) is true only if all of these hold at that moment:
  1. topic is mapped to an A-REX topic (setClaimTopic(claimTopic, arexTopic); the natural mapping is claimTopic = uint256(arexTopic), for example uint256(keccak256("AREX:KYB")));
  2. data is abi.encode(bytes32 evidenceRef, uint16 country, uint64 expiresAt) and has not expired;
  3. the signature is ONCHAINID's format, recovered without malleable signatures;
  4. the signature has not been revoked here;
  5. the trust source (IARexAttest.isTrustedIssuer(arexTopic, signer)) trusts the signer.
• It never reverts for a bad claim: it answers false.
• revokeClaim(claimId, identity) reads the claim from the identity and revokes it if the caller is its signer or a revoker the signer named (setRevoker). revoke(identity, topic, sig, data) does the same for a claim not stored in an identity. revokeClaimBySignature reverts: a signature alone does not prove who signed it.
• A wallet links itself to an identity on which it holds a MANAGEMENT key (linkIdentity); identityOf(wallet) and countryOf(wallet) answer the ERC-3643 adapter's identity and investorCountry (ADR-020).
• The trust source is fixed at deployment. Which A-REX topics are bridged, which claim topics they become and which trust source is used are policy (ADR-019): an implementation's profile, the company and the registry owner who decides to trust the bridge.

A registry owner trusts the bridge as a claim issuer for a topic (T-REX TrustedIssuersRegistry.addTrustedIssuer). By doing so it trusts whoever administers the bridge's trust source to choose KYB issuers, and it can read that source (trustSource()) before deciding.

Argument

Both consumers ask exactly one question of a claim issuer, so answering it from A-REX state makes the A-REX trust list the only list. A distrust in A-REX invalidates every claim its issuer signed in every registry in the same block, with no process to run and nothing to forget. Keeping the claim format identical to ONCHAINID's means the company's claims are signed with the same tools, stored in an ordinary ONCHAINID identity, and verifiable off-chain by anyone who checks the signature and asks the bridge.

Consequences

Positive

• A company checked once on A-REX can be verified by any ERC-3643 registry that trusts the bridge.
• Distrust, expiry and revocation take effect immediately and everywhere.
• No personal data: the claim is a hash, a country and a date.

Negative

• Every verification costs an external call to the trust source (about 3,000 to 16,000 gas per isClaimValid).
• A registry owner must trust the bridge's trust source; the bridge cannot make a weak trust source strong.
• Claims are public in the company's identity, as all ONCHAINID claims are.

Obligations it creates

• Implementations publish which trust source a bridge reads and who administers it.
• Issuers revoke with revokeClaim / revoke, not by deleting keys.
• The conformance clause IC-5 of interop/ERC-3643.md holds (the bridge holds no role in the token).

Implementation and evidence

Related decisions

• ADR-008: no personal data on-chain
• ADR-019: capabilities in the standard, policy in profiles; revocation by the issuer
• ADR-020: ERC-3643 compatibility