External attestations

Verified facts about people and institutions already exist on-chain in other attestation systems. An attester that has recorded a fact there should not have to issue it a second time in another format. The identity layer treats a claim as a neutral container: a claim can stand for any verifiable credential, including one that originates outside the protocol, brought in through an adapter.

The adapter model

The register asks one question of a claim's issuer: is this claim valid for this identity, now? Any contract that answers isClaimValid can be the issuer of a claim. An adapter is such a contract. It holds no credentials of its own. It answers from the external system.

Three things make an external attestation count toward eligibility for an asset:

1. The attestation exists in the external system, from an attester the adapter accepts.

2. The investor's identity holds a claim record whose issuer is the adapter and which points to that attestation.

3. The Issuer of the asset lists the adapter as a trusted issuer for the topic.

The register's requirement does not change: a valid claim for the required topic, from an issuer the asset trusts. Where the underlying attestation comes from is a matter for that issuer.

The EAS adapter

The protocol ships one adapter, EASClaimIssuer, for the Ethereum Attestation Service (EAS).

Property	Meaning
Stateless	It stores no claim and no verdict. Every answer is computed from EAS at the time of the call.
Pinned to one EAS and one factory	The EAS contract and the IdentityFactory it reads are fixed at deployment. The adapter's admin cannot point it at another.
Configured per topic	Its admin maps each claim topic to one EAS schema, and lists the attesters accepted for that topic.

Configuration

Function	Effect
setSchemaForTopic(topic, schema)	Binds a claim topic to an EAS schema. Setting the schema to zero unbinds the topic: every claim for it stops being valid.
setAttester(topic, attester, allowed)	Accepts or stops accepting an attester for one topic. Other topics are unaffected.

Both are restricted to the adapter's admin, through an AccessManager. Anyone can attest on EAS under any schema, so the two settings together are what define trust: an attestation counts only if it uses the schema bound to the topic and comes from an attester accepted for that topic.

From attestation to claim

1. The attester attests on EAS. The recipient of the attestation is the investor's ONCHAINID, or a wallet linked to it.

2. The claim record is added to the identity. A key of the identity that holds CLAIM_SIGNER or CLAIM_ADDER calls addClaim, naming the adapter as the issuer. The adapter does not add claims itself.

3. The Issuer trusts the adapter. It adds the adapter's address to the trusted issuers of its asset for the topic, like any Claim Issuer.

4. Validity is read live. At each eligibility check, the registry asks the adapter, and the adapter reads the attestation from EAS.

The claim record mirrors the attestation exactly.

Field of the claim	Value
issuer	The adapter's address
signature	The UID of the attestation, as 32 bytes
data.issuedAt	The time of the attestation
data.validUntil	Its expiration time
data.payload	Its data

The steps and the checks are in 29 Bring an EAS attestation in as a claim. The adapter refuses a record that differs from the attestation in any of these fields. What is stored on the identity is therefore what the attester signed, and not a fabricated payload next to a genuine UID.

How the adapter decides

Status	When
NotIssued	The topic is not bound to a schema. The attestation does not exist, uses another schema, or comes from an attester not accepted for the topic. The record does not mirror the attestation. The recipient is neither the identity nor a wallet linked to it.
BadSignature	The signature field is not a 32-byte UID.
Revoked	The attester has revoked the attestation on EAS.
Expired	The attestation has reached its expiration time.
Valid	None of the above.

The recipient

The adapter accepts an attestation made to:

• The identity itself, provided the IdentityFactory created it.

• A wallet linked to the identity, whether the link is active or has been revoked.

The second rule is deliberate. An attestation is a fact about the person, not about one wallet. If revoking a compromised wallet also cancelled the attestations made to it, an investor would lose its eligibility in the act of protecting itself. A revoked wallet is refused as a recipient by every asset, and the identity keeps its credentials.

Revocation and expiry

There is nothing to synchronize. The adapter reads EAS at every call.

Event	Where it happens	Effect
The attester revokes the attestation	On EAS	The claim is Revoked from the next check.
The attestation expires	On EAS	The claim is Expired from that moment.
The adapter's admin removes the attester for the topic	On the adapter	Every claim backed by that attester for that topic stops being valid.
The adapter's admin unbinds the topic	On the adapter	Every claim of that topic through this adapter stops being valid.
The Issuer stops trusting the adapter	On the asset's TREXRegistry	Claims through the adapter stop counting for that asset.
The owner removes the record	On the identity, with removeClaim	The identity no longer holds the claim.

The adapter has no revocation function of its own. Revocation belongs to the attester, on EAS.

Trust assumptions

Trusting an EASClaimIssuer for a topic means trusting four things.

Trusted party	For what
The EAS contract	The content, the revocation status and the expiry of every attestation
The attesters accepted for the topic	The truth of what they attest
The adapter's admin	The mapping of topics to schemas and the list of attesters
The IdentityFactory	The link between a recipient wallet and an identity

Adapters are governed by Network governance: it decides which adapters exist and who administers them. An Issuer that trusts an adapter should still know who administers it and which attesters it accepts, since that is what its eligibility then rests on.

Limits

• On-chain attestations only. Attestations that exist off-chain in EAS are not read.

• Same chain. The adapter reads the EAS deployment of its own chain and resolves wallets of that chain. It does not read attestations from another chain.

• Not an identity. The adapter answers the claim-validity questions and nothing else. It holds no keys, it holds no claims, and it cannot add a claim to an identity.

Other attestation systems

The same pattern connects any other system: a contract that implements the claim issuer interface and answers isClaimValid from that system. The register and the identity need no change. The guide is under Build.