Skip to main content
A-Identity is chain-agnostic by construction: one registry describes every chain, and one adapter per virtual machine does the work. Adding a chain is a data edit, not a new code path. The table below is the honest state of that registry. The vocabulary is exact. Live means wired end to end and carrying real traffic. Beta means real and reachable, but not the whole loop. Planned means the descriptor exists so onboarding is a data edit, and nothing is deployed yet.
This table is maintained against the registry itself, and a test in the backend fails the build if a chain here disagrees with it. The machine-readable version is GET /api/chains, which is generated from the same source.

What “deployed” means for identity

The ERC-8004 registries are not ours. Their authors deployed them deterministically, so the same addresses appear on chain after chain, and where they were already present we simply read them. Where a piece was missing we reproduced it by replaying the canonical deployment calldata rather than forking a new contract, which is why the addresses still match everywhere. Two consequences worth stating plainly, because they are easy to get wrong:
  • A chain can carry an IdentityRegistry and no ValidationRegistry. On those chains a KYA result cannot be anchored on-chain. It is still verified and recorded, and we say so rather than reporting a zero that reads like a real count.
  • A chain can have a real settlement token and no canonical Circle USDC. Robinhood Chain is exactly that: the registry’s USDC slot stays empty on purpose, and USDG is named as its own thing, because every generic USDC code path reads that slot.

Settlement, chain by chain