Ecosystem who builds on Adunai.
Adunai is foundation-stewarded substrate. The value lives in what builders compose on top of it. The protocol provides identity, attestation, payments, savings, and reputation primitives; builders turn those primitives into products. Anyone can build, without asking, across eight categories. The Foundation does not pick winners.
Build without asking
Registration is permissionless: any address can create a DID, claim a handle, read an attestation, or call a contract. There is no gatekeeper, no allowlist, and no approval queue between a builder and the protocol surface. The thirty-five contracts are live on Base Sepolia testnet, and the TypeScript SDK (@adunai/sdk, Apache-2.0) lives in the repository today. The SDK is not yet published to npm; that lands with the Phase 1 public release. Until then, builders integrate from source.
The Foundation's role is narrow by design: maintain the protocol surface so every category can compose, and enforce the architectural guarantees, builder neutrality, identity portability, and multi-tier recovery, that stop any single builder from capturing the substrate. The Foundation holds no equity in any builder. See the Charter for the authority boundary.
The eight builder categories
The addressable ecosystem is organized into eight categories spanning roughly sixty archetypes. The full taxonomy, with example flows and per-archetype phase gating, lives in the use cases document.
| Category | Who builds here | Primitives composed |
|---|---|---|
| Financial products | Consumer wallets, merchant tools, lending, payroll, business banking, treasury management | IdentityRegistry, PaymentsRouter, SavingsRegistry, GroupSavings |
| Identity and credentialing | Identity wallets, KYC tooling, sign-in-with-Adunai integrators, portability tools | IdentityRegistry, HandleRegistry, AttestationsRegistry, AttesterRegistry |
| Credential issuers | Banks, employers, universities, telecoms, healthcare institutions issuing verifiable claims | AttestationsRegistry, AttesterRegistry, IdentityAttestations |
| Trust, reputation and vouching | Lenders, landlords, marketplaces, visa consultants consuming reputation for counterparty risk | VouchingRegistry, ReputationExport, SelectiveDisclosure |
| Compliance and regtech | KYC providers, sanctions and PEP screeners, travel-rule reporting, jurisdictional profiles | ComplianceCompleteness, TravelRule |
| Agent and cash networks | Cash-in / cash-out agents, liquidity providers, dispute intake, settlement forwarding | AgentRegistry, AgentSettlement, AgentLiquidityPool, ComplaintRegistry |
| Savings and lending | Goal-based savings, rotating group savings (chama, susu, njangi, stokvel, esusu), microfinance | SavingsRegistry, GroupSavings, ReputationExport |
| Institutional and DPI | Central banks, large banks, NGOs, government agencies integrating via middleware | All of the above, through Layer 4 integrations |
A naming discipline runs through the whole surface: protocol primitives use generic functional names (GroupSavings, not a cultural term), and product layers brand culturally where the local word is the right one for the user. The cultural names live where the user lives, not in the contract layer. Institutions integrate the same primitives, typically at larger scale and through middleware rather than direct SDK calls, the way they already integrate card networks and mobile money. See institutions.
Reference implementations: the floor, not the favorites
The Foundation publishes reference implementations as developer scaffolding, not as consumer products it intends to win with. aID is the reference identity client: a forkable demonstration of what the substrate enables, open-source and fork-friendly. It is the most capable interface to an Adunai identity, but it is not the canonical entry point. Identity lives at the DID layer in the protocol, not at the app layer.
A separate reference wallet is held open as a Phase 1+ surface. A public design preview exists, showing the intended shape of a consumer wallet built on the substrate. It is a design preview, not a shipped implementation. These references set a floor for what a competent build looks like; they do not privilege any builder. If a reference implementation is imperfect, a commercial builder can still ship. If no builder ever forks the references, they remain useful on their own terms.
You can always leave
Builder neutrality is meaningless if a user cannot leave a builder, so portability is enforced by code rather than by goodwill. If a builder that custodied a user's key becomes hostile or unavailable, the user can file an abandonment claim: a 60 to 90 day timelock, vetoable during the window by the current key or any registered guardian, that writes a key override on expiry. GuardianRegistry and AbandonmentRegistry are non-upgradeable, non-pausable, and role-free by design, so no surface, not even the Foundation, can block a user's exit. This is what makes "no single builder can lock you in" a property of the protocol.
Consent, and its limits
Benign, identity-scoped attestations require the subject's EIP-712 consent before they attach to a DID. That consent is genuine, not decorative. The limit worth stating plainly: regulatory and adverse records, AML flags, sanctions matches, PEP designations, and authoritative negatives, are issued without consent by design, because compliance surfaces cannot depend on the subject agreeing to be flagged. Builders in the compliance and regtech category should design around this distinction from the start.
Real deployed builds
Not yet. Adunai is in Phase 0: the contracts are live on testnet and pre-audit, payment routing ships dormant until a timelock-governed arming, and there are no real users or volume. Ecosystem grants are launching, with no awards made. As builders ship on the substrate, they will be surfaced here honestly, named as they arrive, not before. We would rather show an empty shelf than a staged one.
Ready to start? Read the build guide and the SDK reference, wire up Sign in with Adunai, and check grants and current status. The whitepaper covers the full ecosystem thesis; the home page is the shortest path in.