The bridge takes a company's GLEIF-issued vLEI credential — the same identity standard banks and regulators use off-chain — and turns it into an on-chain attestation bound to the company's wallet, so any smart contract on Ethereum can read it permissionlessly.
Every step in the journey involves some subset of these actors. They each have a single, narrow job — that's what makes the system auditable.
Nine steps, end to end. The whole thing finishes in seconds — minus the on-chain confirmation.
The user — typically a treasury or compliance signer at the legal entity — opens the bridge in their browser and connects an Ethereum wallet. The bridge UI pins the chain to Sepolia; nothing happens here yet except the wallet handing over its address.
The user attaches the CESR file — the cryptographically signed envelope GLEIF issued to them — and fills in the KERI AID, LEI, and credential type. The browser holds it; nothing leaves yet.
The wallet pops up an EIP-712 typed-data prompt tying the user's KERI AID and vLEI SAID together with a fresh nonce. Signing this is the user's explicit permission for the bridge to attest about them — without this signature, no attestation gets minted.
The form-data hits POST /api/register. The bridge recovers the signer from the EIP-712 message — it must match the submitted EVM address — and checks the nonce table: each address has a monotonic counter, so an old signature can never be replayed.
The bridge sends the CESR bytes to the GLEIF reference verifier — a Docker sidecar that knows how to parse and validate KERI signatures. It polls until the verifier returns valid, invalid, or times out. Only valid moves on.
With the credential validated cryptographically, the bridge cross-checks against the public GLEIF registry. This is the canonical "who is this entity, today?" lookup — the same source banks and regulators use.
All three checks have passed. The bridge writes a row keyed by (evmAddress, chainId) with status pending_attestation, then responds 202 Accepted to the user immediately — they don't wait on Ethereum confirmation in the request.
Fire-and-forget, the bridge encodes the schema fields and submits an attestation transaction via the EAS SDK, signed by the bridge's attester wallet. The transaction is the only thing that ever moves on-chain.
Inside the EAS contract, the schema's resolver hook fires. It rejects any caller other than the bridge's immutable wallet — that's the on-chain guarantee. Once the receipt lands, the bridge writes the EAS UID back to the row, the audit log gets an "issued" entry, and the user's browser polling unblocks.
A trusted attester is only as good as the rules around it. Two on-chain guarantees keep this one honest.
At deployment, the schema is paired with an AttesterResolver contract that hard-codes a single wallet address. No upgrades, no admin keys, no allowlist edits.
// AttesterResolver.sol address public immutable bridgeWallet; function onAttest(Attestation calldata attestation, uint256) internal view override returns (bool) { if (attestation.attester != bridgeWallet) revert UnauthorizedAttester(); return true; }
Before the bridge attests anything, the user signs an EIP-712 typed message binding their EVM address to a specific KERI AID and vLEI SAID, with a monotonic nonce. Without this signature, no attestation can be issued.
// EIP-712 domain { name: "vLEI-to-EAS Bridge", version: "1", chainId: 11155111 } // types Registration { keriAid: string, vleiSaid: bytes32, nonce: uint256 }
Identity changes. Companies merge, lapse, get renamed. Three background loops keep on-chain state honest about off-chain reality.
For every active registration, re-presents the KERI AID to the verifier. If the credential is no longer valid, the row enters pending_revocation.
Pulls the LEI record from GLEIF. LAPSED, RETIRED, ANNULLED, CANCELLED trigger on-chain revocation. Renames are quietly patched in the DB.
Picks up any stuck pending_attestation or pending_revocation. Up to 3 attempts with backoff before terminal failure.