Start building.

Three ways into the substrate: an SDK-only sign-in flow for relying parties, a typed protocol SDK for builders, and direct contract integration for teams that want the raw surface. All thirty-five contracts are live on Base Sepolia testnet today, pre-audit, no real value at stake. Exactly the environment to build in.

Choose your path

Path	You are	On-chain footprint	Start
Sign in with Adunai	A relying party, lender, landlord, telco, marketplace	None. No contracts to deploy, no writes.	The grant flow
@adunai/sdk	A protocol builder, wallets, remittance, savings, agent tooling	Reads and writes to the primitives; contracts optional	SDK quickstart
Direct contracts	A Solidity team integrating at the contract layer	Your own contracts against the live registry	Contract registry

1 · Sign in with Adunai, for relying parties

If you verify people rather than build wallets, this is the whole integration: an OAuth-shaped grant flow where the user approves scoped disclosure in their identity client, and you read only what was granted, verifying issuer signatures locally against your own trust policy. SDK-only. Nothing to deploy, no tokens to hold. Read Sign in with Adunai first; it is the handshake both SDK surfaces share.

2 · @adunai/sdkfor protocol builders

The protocol SDK is a typed TypeScript client for every primitive, identity, handles, attestations, selective disclosure, recovery, payments, savings, the agent network. Apache-2.0, viem-based, strict types, testnet-guarded by construction (mainnet is rejected at client creation in Phase 0). It lives in the protocol repository today; npm publication lands with the Phase 1 public release. In Phase 0 you build from the repo, that is the honest install story, and the quickstart reflects it.

3 · Direct contract integration

For teams working in Solidity, the contract registry lists all thirty-five contracts with addresses, categories, and Basescan verification. The architecture is documented in the whitepaper: identity-first, with payments downstream, a 0.05% protocol fee on routed transfers, and recovery primitives (guardian quorum; a 60–90-day timelocked abandonment claim, vetoable by the current key or registered guardians) that your integration should respect rather than bypass.

Build against Base Sepolia today

The testnet surface is not uniform, and the status page is the live board. Two facts matter most: ProtocolConfig's five-token launch whitelist (USDC, USDT, EURC, cbBTC, WETH) is live, while PaymentsRouter's routing whitelist ships dormant and arms through the 14-day timelock. Identity, attestation, disclosure, and recovery flows are fully exercisable now; payment routing is a governance action away.

First verification in minutes

1. Clone the protocol repository and install the SDK workspace.
2. Point the client at Base Sepolia, the SDK refuses mainnet in Phase 0.
3. Resolve a DID, then read a consented attestation through the grant flow.

The full walkthrough, with code, is the @adunai/sdk quickstart.

Reference implementations

The reference implementations document the floor, they do not compete with builders. aID is the reference identity client, behind Sign in with Adunai. A reference wallet is held open for Phase 1+ (Charter §8.6); a design preview is public now, showing how a consumer wallet composes the primitives, handles, attestation onboarding, group savings, recovery handoff. The Foundation names no commercial builders in its documentation, holds no equity in any, and picks no winners, the substrate is the same for everyone.

What ships when

Surface	Today · Phase 0	Next
Contracts	35 live on Base Sepolia testnet	Mainnet after the external audit, never before it
@adunai/sdk	In the protocol repository, Apache-2.0	npm publication with the Phase 1 public release
Docs & API reference	This set, the working minimum	Full API surface documented in Phase 1
Payment routing	Dormant; token whitelist live	Arms via the 14-day timelock
Bug bounty	Not yet, disclosure channel open	Phase 1+
Ecosystem grants	Launching; no awards made yet	Operating as the program opens

What can change under you

Builders should know the upgrade path before depending on a contract. Every protocol upgrade runs the same gauntlet: an RFC with a 14-day public comment window, Technical Advisory Council review, approval by 5 of 9 signers of the multi-sig, directors, technical advisors, and ecosystem representatives, then a 14-day OpenZeppelin timelock before execution. A bounded emergency pause exists (Charter §4.3: 7 of 9 signers, fourteen days maximum unless community ratification extends it), and emergency patches may bypass the RFC but never the timelock. On-chain voting is the Year-3 roadmap direction, not a live mechanism. The full constraint set is the Charterthirteen Articles, including what the Foundation is prohibited from ever doing.