Adunai, Digital Public Infrastructure for African Economic Life

Version 0.3, Draft for Discussion (updated 2026-07-02: contract surface reconciled to the deployed 35-contract v1 system) Status: Pre-Audit, Pre-Mainnet. Not a solicitation.

Adunai (ah-DOO-nai), derived from "Aduna," the Wolof word for "world" or "earth."

Abstract

The most consequential infrastructure projects of the next decade are not financial products. They are the digital public infrastructures (DPI) that underpin economic life, identity systems, attestation registries, payment rails, and the trust substrate that makes commerce possible at scale. India built one such substrate, Aadhaar plus UPI, across a single jurisdiction. The European Union has eIDAS. Singapore has SingPass. Brazil has PIX and DREX. Africa, the largest economic region without a comparable substrate, has none.

That absence is not for lack of ambition. The African Union, AfCFTA Secretariat, Smart Africa, and dozens of national projects have articulated the need. But no single African government can build continental DPI, every country DPI stops at its border. And 54 sovereign states cannot coordinate at the speed digital infrastructure requires.

This whitepaper introduces Adunai: non-state Digital Public Infrastructure for African economic life, foundation-stewarded with constitutional governance, designed for user sovereignty over identity rather than platform or institutional ownership. Adunai is a permissionless protocol on Base providing identity, handles, attestations, reputation, compliance, recovery, payments, and savings as composable primitives, designed identity-first, with finance downstream as a first-class application.

The category is DPI in the India Stack sense, but the structural distinction is non-state stewardship. India Stack, EU eIDAS, Singapore SingPass, and Brazil PIX/DREX are all state-operated. Adunai is the foundation-stewarded substrate that works across 54 jurisdictions where no single state can coordinate. The architectural choice that makes this possible is foundation-stewardship with constitutional governance. Adunai is not owned by a government, a bank, a fintech, or a sovereign monetary authority. It is governed by an independent foundation under Mauritius law (purpose foundation under the Foundations Act 2012), with a charter that constrains what the Foundation may do over user-controlled state, constitutional limits enumerated in Charter Article VIII. The protocol's primitives are open-source, public, and forkable. The Foundation stewards the substrate; builders compose products on top; users hold their own identity and keys; institutions integrate without ceding sovereignty.

Adunai is identity-first by design. The deployed v1 system is 35 contracts (+ 3 patches), audited as a single bundle before mainnet. Within the 22-contract core bundle, fourteen are identity, trust, attestation, reputation, compliance, recovery, and linkage primitives, seventeen of its twenty-five audit surfaces once the three patches (all identity-side) are counted; the agent-network and delegation additions extend the same identity-anchored trust surface. The remainder handle value transfer, savings, and the cash-in/out agent economy. The protocol is being built as substrate, not as a payment rail with identity bolted on.

This document describes Adunai's positioning as African DPI, the layer-cake architecture by which builders compose on the protocol, the identity-first primitive ordering, the multi-tier recovery and identity-portability architecture, the economic and governance design, the privacy and threat model, and the path from Base Sepolia testnet to mainnet.

1. African Digital Public Infrastructure

1.1 Why African DPI must be foundation-stewarded

India built Aadhaar, UPI, and DigiLocker because a single national government with constitutional authority could mandate participation, run the registry, and absorb the operational cost. The result is one of the most consequential pieces of public infrastructure in modern economic history: a billion-person identity layer, a real-time payment rail moving more transactions per month than Visa globally, and a credential substrate that compresses years of paperwork into seconds.

Africa cannot follow that path. Not because the technical work is harder, but because the political and operational geometry is different.

Fifty-four African countries operate fifty-four sovereign monetary authorities, fifty-four legal regimes, fifty-four financial-services regulators, and a patchwork of identity systems, Nigeria NIN, Ghana Card, Kenya Huduma, South Africa ID, Cameroon CNI, Senegal NIN, and so on, each stopping at the border. Some are mature; some are nascent; none are interoperable. AfCFTA, the African Continental Free Trade Area, operational since 2021 with $3.4 trillion in projected intra-African trade by 2030, has the political mandate to make commerce flow across these borders, but no digital substrate to make it operationally cheap.

The four candidate stewards of continental DPI each fail for structural reasons:

A single government cannot steward infrastructure that crosses its borders. Even the most institutionally capable African states cannot legitimately operate identity, payments, and trust rails for citizens of other nations.
An intergovernmental body (AU, ECOWAS, EAC, SADC) can articulate need and ratify standards but cannot operationally run a software substrate at the velocity infrastructure work requires, these bodies make decisions on multi-year cycles, not multi-week cycles. The AU's Digital Transformation Strategy 2020-2030 is a policy framework, not an operational substrate; Smart Africa Alliance is a multi-stakeholder coordination body, not a contracts-and-keys deployment.
A commercial company can build the technology, but commercial logic eventually demands rent extraction, lock-in, and capture. A continental substrate owned by a private operator becomes either a fragile monopoly or an extractive intermediary, repeating the failure mode of correspondent banking.
A state-owned consortium of operators can move faster than a treaty body but tends toward fragmentation along national lines, because each member's incentive is to preserve its own market position. PAPSS (Pan-African Payment and Settlement System, Afreximbank/AU/AfCFTA-operationalized since 2022) is the most material example of this model: real, in-flight, materially valuable for bank-to-bank cross-border settlement, but architecturally limited to the regulated-bank tier and to payments rather than the full DPI surface (identity, attestations, reputation, savings, compliance). PAPSS and Adunai are complementary, not competitive: PAPSS handles regulated-bank rail; Adunai handles open permissionless substrate. The two can interoperate downstream.

A foundation, independent, non-profit, charter-bound, transparent, is the structural answer to a problem none of the above can solve. It can steward open primitives without owning them. It can engage African central banks as partners rather than competitors. It can outlast any single government, executive, or commercial cycle. It can be constrained by charter from acting against user-controlled state. And it can support builders who compose products on top of the primitives without depending on the Foundation for permission.

The Adunai Foundation is structured for this role. It is not a startup with a foundation tax-wrapper. It is the steward of a public-good substrate, with operational, legal, and architectural separation from the commercial entities that may build on top.

1.2 Adunai as foundation-stewarded substrate

Adunai is what India Stack would look like if no single government had the authority to commission it, and the continent it served chose to build it through an open protocol instead.

The substrate provides:

Identity: every participant holds a DID (decentralized identifier) under a key they control. Registration is permissionless, free, and instant.
Handles: human-readable names resolving to DIDs, with reserved institutional subdomains (.bank.adunai.gov.adunai.health.adunaietc.) gated by Foundation-authorized verifiers.
Attestations: typed, signed claims about a DID, issued by accredited issuers (KYC providers, banks, employers, governments, the protocol itself), with subject-consent and freshness windows enforced on-chain.
Reputation: portable across applications: vouching, transaction history, counterparty signals, all keyed to the DID and exportable with user-signed permission grants.
Compliance: cascade evaluator composing attestations into jurisdiction-scoped profiles (KYC tiers, country-of-residence checks, travel-rule attribution at thresholds).
Recovery: multi-tier social recovery, key rotation, and a planned abandonment primitive that closes the substrate against hostile-builder lock-in.
Payments: stablecoin transfers with protocol-level fee capture, attestation-gated where required, and metadata commitments for off-chain memo binding.
Savings: solo time-locked goal savings and group savings (the primitive that culturally maps to tontine, njangi, susu, chama, and stokvel patterns).
Linkage: the merge primitive that lets a single user consolidate multiple DIDs (multi-SIM, multi-device, diaspora multi-channel) into one identity graph without sacrificing on-chain distinctness.

Each primitive is open-source, deployed under foundation-stewarded governance, and composable with every other primitive and with external protocols. No primitive is reserved to the Foundation. No primitive grants the Foundation authority over user-controlled state.

This is the substrate. What builders make from it is up to them.

1.3 aID as user-facing entrypoint, DID as canonical identifier

Adunai distinguishes carefully between the protocol identifier (the DID) and the user-facing portal (the aID app, plus "Sign in with Adunai" as an OAuth-pattern integration brand).

The DID is canonical. It is a bytes32 reference inside IdentityRegistryderived from a key plus salt, and it is the protocol's stable identifier for any participant. Everything, attestations, reputation, payments, savings membership, linkage, keys to a DID.

The aID app is the most powerful client a user has for interacting with their Adunai identity. It is a portal, not a new identifier layer. There is no "aDID" or alternative protocol identity introduced by aID; the canonical identity is and remains the DID.

"Sign in with Adunai" is the integration brand, analogous in pattern to "Sign in with Apple" or "Sign in with Google." A builder application accepting "Sign in with Adunai" receives a user's DID and the attestations the user chooses to grant, never the user's keys, never the user's underlying credentials. The user remains in control of what is granted, to whom, and for how long.

Bidirectional flow is an architectural guarantee. Two patterns must work equally well, and neither may be privileged:

"Sign in with Adunai": a user with an existing aID arrives at a builder's application and authenticates using their Adunai identity.
"Get your Adunai ID": a user with no prior Adunai relationship onboards through a builder's application (perhaps a Lagos remittance dApp, a Nairobi savings app, or a Yaoundé merchant tool), receives a DID provisioned by the builder, and may later claim the aID experience directly.

The substrate must support both flows without making the aID app a privileged entry point. Users enter the Adunai ecosystem through whatever Adunai-compatible application they encounter first. Identity lives at the protocol level, not at the application level. A builder cannot lock a user in, because the identity the user receives is on the protocol, not on the builder's database.

1.4 Why blockchain substrate

DPI does not require a blockchain in principle. India Stack runs on conventional databases under government operation. But Adunai is not India Stack: it cannot be run by a single national operator without losing legitimacy across 53 other jurisdictions, and it cannot be run by a private operator without becoming a captured intermediary.

A blockchain substrate solves the structural problem in a specific way:

Cross-jurisdictional verifiability. A DID registered on a public blockchain is verifiable to any party in any jurisdiction without requiring trust in a particular operator. A bank in Nairobi can verify an attestation issued in Lagos against the same on-chain commitment that a regulator in Pretoria can check. Verification does not depend on which government you ask.
Permissionless composition. Builders compose on the protocol without requesting permission from any operator. A wallet in Yaoundé and a lender in Accra can both build against the same primitives without coordination, mediation, or revenue-share negotiation.
No single operator to capture. The Foundation cannot turn off the protocol any more than the Ethereum Foundation can turn off Ethereum. Charter and timelock discipline constrain the Foundation's authority architecturally, not by goodwill.
Auditable economic flows. Every payment, every fee, every Treasury withdrawal, every parameter change is on a public ledger that any African central bank, regulator, journalist, or citizen can inspect.

These are architectural properties, not marketing claims. Adunai is built on Base, Coinbase's Ethereum L2, because Base provides low per-transaction cost (cents, not dollars), EVM compatibility, credible neutrality, and growing developer familiarity in African markets. Multi-chain expansion is planned for Phase 2+ (Tron in particular, given its dominant role in informal African stablecoin flows). Adunai does not build its own L1; chain-level decentralization is inherited from the underlying stack.

1.4.1 Asset-permissive substrate with on-ramp reachability

Adunai's protocol primitives are token-agnostic. Any ERC-20 on Base can be whitelisted via Foundation governance through ProtocolConfig (the centralized whitelist contract in the Phase 0 audit bundle). All token-touching primitives, PaymentsRouterTreasurySavingsRegistryGroupSavingsComplianceCompleteness screening, RateOracleAgentRegistry staking, operate uniformly across any whitelisted token. No new contracts are required to support a new asset; whitelist additions and removals flow through TimelockController (14-day delay convention) as Foundation-governance decisions.

The launch whitelist ratified for mainnet Phase 0 close:

Tier 1, Primary payment rails. USDC (Circle-issued; deep liquidity; regulatory clarity), USDT (broadest African P2P usage), EURC (Circle-issued Euro stablecoin for Africa-EU corridors).
Tier 1.5, Bitcoin accessibility. cbBTC (Coinbase Wrapped BTC on Base; ERC-20; redeemable for BTC via Coinbase). Adunai supports Bitcoin via cbBTC; African Bitcoin users can use their existing Bitcoin within Adunai's identity-and-trust + payment-rail infrastructure without selling to fiat first.
Holding/transfer accessibility. wETH on Base (Ethereum accessibility; holding asset, not payment rail).

Deferred to Phase 1+ or Phase 3 (per category): Adunai-issued local-currency stablecoins (cXAF, cNGN, cKES, Phase 3 via IssuerMintBurn); additional wrapped Bitcoin representations (wBTC, tBTC, Phase 1+ if demand); SOL via wrapped representation, DAI, African-project tokens (Yellow Card, Mara), partner-specific tokens, case-by-case via Foundation governance.

On-ramp reachability is a user-experience property realized at the application layer. Builders integrate on-ramp partner APIs to provide native "Top up with Bitcoin" / "Top up with crypto" / "Top up from mobile money" experiences. Conversion happens via the partner; the resulting whitelisted asset arrives in the user's Adunai-controlled Base address. The Foundation does NOT custody non-Base assets and does NOT operate conversion infrastructure, that is partner territory.

Partner ecosystem (a later business-development track, not Phase 0 critical path): Bitnob for BTC → USDC via Lightning Network on African corridors; Coinbase for BTC → cbBTC custody and multi-asset on-ramp; Yellow Card and Mara for pan-African coverage; Onafriq, Bitsika, Quidax, Luno for market-specific reach; MoonPay and Transak for global on-ramp infrastructure.

The architectural-principle / user-experience-property distinction matters. Asset-permissive substrate is what the protocol primitives technically support (any whitelisted ERC-20 works against shipped contracts). On-ramp reachability depends on partner integrations existing and being maintained at the application layer. The two together let African users meet Adunai where they are, Bitcoin holders, USDT holders, USDC holders, mobile-money holders, fiat holders, rather than forcing a single starting asset.

1.5 Identity-first layer cake

Adunai's public-facing architecture organizes into four layers. Each is a distinct surface with its own governance posture; together they form the ecosystem.

Layer 1, Adunai Protocol (foundation-stewarded substrate). The 35 smart contracts + 3 patches deployed on Base under foundation stewardship. Identity, handles, attestations, reputation, compliance, recovery, payments, savings, linkage, delegation, and agent-network primitives. Open-source, timelock-governed; a single external audit of the complete v1 system gates mainnet. The SDK, indexer, and public infrastructure (RPC, schemas, deploy verification scripts) live here.

Layer 2, Reference Implementations (foundation-stewarded, community-owned). Forkable reference clients that demonstrate what the substrate enables. The aID reference identity client. The Adunai reference wallet (held open as a Phase 1+ ratification surface; if developed, distinct from aID). TypeScript SDKs and libraries. The indexer subgraph. The Foundation stewards these codebases as developer scaffolding, not as consumer products. Multiple community instances are expected to coexist and interoperate; the Foundation does not ship a winning consumer product itself in Phase 0.

Layer 3, Commercial Builders (independent, permissionless). Commercial ventures build on the protocol independently, typically consumer-wallet products targeting African users, with institutional consulting optionality as the DPI movement matures. Every builder enters the ecosystem on equal footing, across the eight categories listed in §1.7. No builder has privileged status at the protocol level; if a builder becomes hostile, a user can use the abandonment primitive to leave (see §1.8).

Layer 4, Institutional Implementations (variable structure). Government DPI integrations, central-bank stablecoin partnerships (Phase 3, cXAF, cNGN, cKES under their respective monetary authorities), NGO disbursement implementations, large-bank and insurer integrations. These are not "products built on Adunai" in the same sense as a consumer wallet; they are integrations between institutions and the protocol, typically requiring legal agreements, regulatory engagement, and bespoke technical work.

Each layer is independently viable. The protocol is useful if no Layer 4 integration ever materializes. Layer 3 builders can ship if Layer 2 reference implementations are imperfect. Layer 2 reference implementations are valuable even if Layer 3 builders never fork them. The architecture does not depend on any single layer's success.

1.6 The identity-first contract surface (35 contracts + 3 patches)

Phase 0 ships a complete protocol surface, 35 contracts, all live on Base Sepolia since 2026-07-01, in a single bundled audit engagement. The contracts are ordered identity-first; finance sits downstream.

The list below reflects the audit scope (the abandonment primitive ships as the standalone AbandonmentRegistrythe 22nd contract, not as a GuardianRegistry extension). The per-contract tags below (shipped / shipping / new) record each contract's original build order in the Phase 0 sequence; as of the 2026-07-01 full fresh redeploy, all 35 are deployed together on Base Sepolia. They complete the bundled audit and then deploy together to mainnet in Phase 2.

Identity and recovery (6 contracts). IdentityRegistry (shipped; DID model, key rotation, recovery). HandleRegistry (shipped; human-readable names, institutional tier, with the routing patch through guardianRegistry.resolveCurrentKey). AttestationsRegistry (shipped; typed signed claims, schema registry, issuance policies). GuardianRegistry (shipped; override-pattern social recovery, role-free per Charter §VIII). AbandonmentRegistry (shipped; standalone recovery from a hostile or unavailable builder, 60–90 day timelocked claim, vetoable, non-pausable, role-free). LinkedIdentitiesRegistry (new; duplicate-DID merge primitive). Supporting logic libraries (IdentityLifecycle revocation-aware liveness, KeyResolution override-aware key resolution) are reviewed with their consuming contracts, not counted separately.

Identity lifecycle (4 contracts). AttesterRegistry (shipped; method-ID dispatch, bridged-attester roster including Coinbase/Binance/MetaMask). VouchingRegistry (shipped; vouch/revoke flow, anti-Sybil composition). RevocationRegistry (shipped; DID revocation flow, with the selfRevokeDID cooling-off patch). IdentityAttestations (shipped; per-DID attestation records, freshness, multi-attester support).

Compliance (2 contracts). ComplianceCascade (deployed but deprecated 2026-06-15, superseded by ComplianceCompleteness; retained for coexistence, no production consumer). ComplianceCompleteness (the omission-proof completeness screen that settlement consumers bind). TravelRule (new; FATF originator/beneficiary attribution for cross-border transfers above threshold).

Rates (2 contracts). RateOracle (shipped; hybrid push/pull, EIP-712 signed rates, fixed and treaty pegs). SignerRegistry (shipped; 2-of-3 Foundation signer infrastructure).

Value transfer (3 contracts). PaymentsRouter (shipped; stablecoin transfer, fee capture, metadata commitments, batch transfer). Treasury (shipped; protocol-fee custody, generic ERC-20 receiver, WITHDRAWER_ROLE on timelock). AgentRegistry (shipped; fiat-gateway agent registration, staking, settlement, slashing).

Savings and reputation (4 new contracts). SavingsRegistry (new; goal-based solo savings, time-locked balances, maturity-unlock). GroupSavings (new; rotating-payout group savings primitive, the protocol-level name for what wallets surface culturally as tontine, njangi, susu, chama, or stokvel). SelectiveDisclosure (new; user-signed grant model for attestation read access). ReputationExport (new; portable reputation profile composing SelectiveDisclosure plus AttestationsRegistry).

Protocol config (1 new contract). ProtocolConfig (new; centralized token whitelist, fee caps, timelock disciplines, currency registry; consolidates configuration today split across PaymentsRouter and Treasury).

Compliance completeness (1 contract). ComplianceCompleteness (completeness checks across the compliance cascade).

Scoped delegation (1 contract). DelegationRegistry (N6; scoped key delegation for consumers of identity, with per-consumer delegate hooks).

Agent network (10 contracts). The cash-in/out agent economy: AgentSettlement (N1, the settlement keystone) + N1SettlementConfigInterchange (N2, cross-builder interchange quoting), BuilderPool (N3, DID-keyed builder escrow), AgentLiquidityPool (N4), AgentSwapEscrow (N5), BuilderRegistry (N7), GrantDistributor (N8, ecosystem grant distribution), AgentReputation and ComplaintRegistry (N9, report-and-reputation dispute intake).

Settlement forwarding (1 contract). AgentSettlementForwarder (the gasless settleWithSig forwarder, a separate contract by design; the WithSig paths were removed from N1 for EIP-170 headroom).

Plus the Foundation Safe and the upstream OpenZeppelin TimelockController (both vetted, out of audit bundle but verified at deploy time).

Fourteen of the twenty-two core-bundle contracts, the identity-and-recovery and identity-lifecycle groups, both compliance contracts, SelectiveDisclosureand ReputationExportare not strictly financial. They form the identity-and-trust substrate. The financial primitives (PaymentsRouter, Treasury, AgentRegistry, plus the savings primitives) sit downstream of identity, as first-class applications of it.

The full architecture, scope notes, composition invariants, and per-contract auditor focus are documented separately.

1.7 Builder ecosystem

Adunai is foundation-stewarded substrate; the value emerges from what builders compose on top. The Foundation has organized the addressable builder ecosystem into eight categories spanning approximately sixty archetypes. The categories below summarize the surface.

Financial product builders. Consumer wallets, merchant tools, lending products, savings products, payroll tools, payment-card integrations, business banking, treasury management.
Identity and credentialing builders. Identity wallets, credential issuers' interfaces, KYC tooling, sign-in-with-Adunai integrators, identity portability tools.
Credential issuers. Banks issuing account verification, employers issuing employment attestations, universities issuing educational credentials, governments issuing ID verification, telecoms issuing phone verification, healthcare institutions issuing professional credentials.
Trust and reputation consumers. Lenders consuming attestations for credit decisions, landlords consuming attestations for tenancy, marketplaces consuming reputation for counterparty risk, visa consultants composing immigration-relevant credentials.
Commerce and marketplace builders. B2B SMB tools, marketplaces, agritech platforms, logistics platforms, e-commerce with embedded identity and payments.
Civic and public-sector builders. Government disbursement tools (cash transfer programs, subsidies, social protection), tax authority integrations, regulatory reporting tools, AfCFTA-aligned trade tooling.
Cross-border and immigration builders. Diaspora remittance tools, intercontinental settlement tools, cross-border SMB tools, immigration documentation tools, refugee identity tools.
Developer infrastructure. SDK extensions, indexers, analytics dashboards, dev tooling, Adunai-compatible certification tooling, integration testing harnesses.

Plus an institutional-and-enterprise tier, large banks, central banks, NGOs, government agencies, and international institutions, engaging through Layer 4 integrations.

The Foundation's role is not to pick winners. It is to maintain the protocol surface that lets all of these categories compose, and to enforce the architectural guarantees (builder neutrality, identity portability, multi-tier recovery) that prevent any single builder from capturing the substrate.

1.8 Identity portability and multi-tier recovery

Builder neutrality is meaningless if a user cannot leave a builder. Adunai treats identity portability and multi-tier recovery as architectural guarantees, not as policies the Foundation enforces by goodwill.

Three recovery tiers are supported, with users choosing their preferred configuration at signup and able to upgrade later:

Tier 1, time-locked phone or email recovery (default). Convenient for users new to crypto. Phone/email proof of control triggers a 60–90 day timelock window before key rotation completes. The long timelock is a deliberate anti-takeover measure: if an attacker compromises a user's phone or email, the legitimate user has weeks to notice and veto. This trades immediacy for safety in a way that matches the African mobile-money mental model of "report a SIM swap immediately and the operator can intervene."

Tier 2, social guardians via GuardianRegistry (recommended). Users designate 2–7 guardian DIDs with auto-derived M-of-N majority threshold. Guardians collectively co-sign key rotation. The override pattern preserves the existing IdentityRegistry.controllingKey storage layout while writing currentKeyOverride[did] post-recovery; consumers route through guardianRegistry.resolveCurrentKey(did).

Tier 3, KYC re-verification through multiple attesters (advanced). For users with strong off-chain identity anchoring, multiple Adunai-accredited attesters can co-sign a recovery flow re-establishing the controlling key against re-verified KYC. Useful for institutional and high-assurance contexts.

These tiers compose with two new portability primitives, which close the substrate against hostile-builder lock-in:

Abandonment primitive (GuardianRegistry.initiateAbandonmentnew in Phase 0). The earlier substrate had a gap: if Builder X custodied a user's initial key and never released it, the user could neither set guardians (because that requires the current key) nor escape. The abandonment primitive lets a user initiate unconditional escape from any custodian without requiring pre-registered guardians. Invocation requires user-side proof of DID ownership (the specific proof package is phone/email OTP with hashed commitment, off-chain proof with dispute window, or attestation re-verification by the original attester, or some tiered combination). The timelock is 60–90 days, vetoable during the window by the current controllingKey or any registered guardian. On expiry, the abandonment writes currentKeyOverride[did]and the user gains control. This is the primitive that makes "you can always leave" a property of the protocol, not a promise from a builder.

Linkage primitive (LinkedIdentitiesRegistrynew in Phase 0). African users routinely accumulate multiple DIDs, multiple SIMs across operators, multiple devices in a household, multi-channel diaspora signups, builder-provisioned DIDs that later need consolidation with a self-claimed aID. Without a merge primitive, "your reputation is yours" breaks at the boundary between two DIDs the same human controls. The linkage primitive lets a user record linkDID(primaryDID, secondaryDID, proofs) with mutual signatures (or, when one DID was hostile-recovered through the abandonment primitive, with abandonment-claim proofs). Linked DIDs remain on-chain technically distinct (attestations stay scoped to the issuing DID), but client and SDK layers aggregate across the linkage graph so the user sees one identity with combined history. The graph is capped at five DIDs (covering virtually all real-user scenarios while bounding abuse and DoS surfaces). Linkages are stored as commitments, not plaintext DID pairs, and reveals are gated through SelectiveDisclosure. Unlinking has a 30-day timelock and a notification mechanism. The KYC-tier interaction rule is highest-tier-wins at the client aggregation layer, with anti-fraud mitigations preventing a low-tier hostile-recovered DID from being linked to a high-tier DID purely to inherit compliance status.

Composition between these primitives is audited as a bundle invariant. Abandonment timelock must be at least as long as the selfRevokeDID cooling-off period, so that an adversarial current-key holder cannot preempt a legitimate abandonment by revoking the DID during the window. HandleRegistry routing through resolveCurrentKey ensures that post-recovery, the rightful user can transfer handles, claim institutional tier, and use every signature-gated surface. The linkage primitive must not broaden SelectiveDisclosure grant scopes or create KYC privilege escalation at the protocol layer.

Together these primitives, shipping in Phase 0 ahead of mainnet, produce a substrate in which builders cannot lock users in. The architectural guarantee will be enforced by code, audit, and timelock at Phase 0 close, not by Foundation goodwill.

1.9 Foundation governance aligned with DPI principles

The Foundation is a Mauritius purpose foundation under the Foundations Act 2012, with a charter that constrains it to substrate stewardship. The charter (in particular Article VIII, Protocol Stewardship, and Article VIII §3, Bounded Authority) defines what the Foundation may and may not do.

What the Foundation does:

Stewards the protocol's smart contracts, including upgrades through timelocked multi-sig with public RFC discipline.
Accredits attesters and verifiers for the institutional tier and for accredited-issuance schemas, subject to published standards.
Allocates Treasury funds across operations, ecosystem grants, reserve, and agent-network incentives per its charter and on-chain governance.
Engages African central banks, monetary authorities, AfCFTA bodies, and other institutional partners on substrate integration.
Enforces the "Adunai-compatible" certification standard for builders supporting bidirectional flow (the specific certification governance model is community-stewarded with Foundation oversight; final structure to be finalized later).

What the Foundation does not do (per Charter Article VIII):

The Foundation does not issue currency. African currencies (cXAF, cNGN, cKES, and others) are issued by authorized partners under their respective central bank oversight in Phase 3. Foreign currencies (USDC, USDT, EUR-pegged stablecoins) are integrated through their existing issuers; the Foundation does not compete with Circle or Tether.
The Foundation does not custody user funds. Users hold their own keys.
The Foundation does not act over user-controlled state. Recovery, abandonment, and linkage primitives are role-free; the Foundation cannot un-revoke a DID, cannot force-link two DIDs, cannot cancel an abandonment, cannot rotate a user's key.
The Foundation does not operate fiat. The Foundation does not run mobile-money bridges, agent networks, or licensed payment infrastructure. Operating entities and licensed partners do that work; the Foundation provides the registry, reputation, and dispute primitives that let those operators be discoverable and trust-minimized.
The Foundation does not replace African central banks or monetary authorities. To the contrary: the Foundation engages them as partners, provides regulatory reporting tooling, and is structured so that integration strengthens rather than challenges their authority.

The Foundation multi-sig has nine signers, three Foundation directors, three technical advisors, and three ecosystem representatives, with a 5-of-9 threshold for routine actions and 7-of-9 for signer changes or emergency actions (Charter §3.4), drawn from West Africa (Francophone and Anglophone), Central Africa, East Africa, Southern Africa, North Africa, the African diaspora, and international advisors. The composition ensures time-zone, jurisdictional, and cultural diversity that no single state can compel, and that no single actor can stall.

Governance progressively decentralizes over Phase 2+, with community proposals enabled in Year 2, delegated voting on non-critical parameters in Year 3, on-chain governance for protocol upgrades in Year 4, and full progressive-decentralization patterns mature by Year 5+. This timeline follows patterns proven by Optimism, Uniswap, and Aave, adapted to the DPI-stewardship context.

1.10 Phased roadmap

Adunai's path from Base Sepolia testnet to continental scale is a five-phase progression. Phase milestones are concrete deliverables, not aspirational direction.

Phase 0, Protocol foundation, private testnet (current, Months 0–13). The complete protocol surface, all 35 contracts + 3 patches in §1.6, is live on Base Sepolia (full fresh redeploy, 2026-07-01; 34/35 source-verified). aID reference identity client operational, with privacy primitives deferred to Phase 1. TypeScript SDK first usable version. Cross-border SMB demo end-to-end. Marketing site v1 live. First SMB pilot transaction. Adunai Foundation legal entity in formation under Mauritius law. Pre-seed-close-by-month-2 is a critical-path ratification gate determining which capacity scenario the build executes under.

Phase 1, Wallet privacy primitives, public testnet, individual enablement (Months 13–18). Wallet privacy primitives added: stealth addresses per EIP-5564, per-counterparty DID rotation, selective-disclosure SDK flows via recipient viewing keys. Public testnet open. SDK first public/external version. Developer documentation site live. Bug bounty scaled to Immunefi tier. First 3–5 committed third-party builders integrating against testnet. Seed round closed against testnet traction.

Phase 2, Bundled audit, mainnet launch, off-chain rails, real users (Months 18–26). Single consolidated pre-mainnet audit covering the complete deployed v1 surface, 35 contracts + 3 patches (scope notes per contract within one engagement). Public audit contest. Remediation and re-audit. Continuous bug bounty scaled to TVL. Controlled mainnet deployment with graduated value caps. Off-chain rails operational (mobile-money bridges, fiat-gateway agent network). First real cross-border SMB payments. Initial Layer 4 institutional partnerships operational.

Phase 3, Local stablecoin readiness, ecosystem expansion (Months 26–36). Value caps removed. Local-currency stablecoin partnerships in pilot or operation: cXAF (CEMAC), cNGN (Nigeria), cKES (Kenya), and additional country-level stablecoins as central-bank partnerships develop. Multi-chain expansion (Tron as priority second chain). WAEMU expansion. Progressive decentralization of governance begins per Foundation Charter Article XI. Layer C peer-to-peer attestation relay network scales.

Phase 4+, Continental scale, long-term decentralization (Years 3–5+). Foundation hand-off to community governance underway. Continental footprint with multiple central-bank partnerships operational. Formal verification of critical contracts. Hundreds of community relays across Africa and diaspora. Active engagement with African Union and AfCFTA bodies as institutional infrastructure partners.

The phase milestones, exit criteria, and capacity scenarios are detailed separately.

2. Design Principles

Adunai is designed around nine principles. Every architectural decision in later sections can be traced back to these.

2.1 DPI-substrate first, applications second

Adunai is being built as African DPI, not as an African fintech with identity bolted on. The identity-first ordering of the 22-contract + 3-patch core bundle, the constitutional separation of Foundation authority from user-controlled state, and the layer-cake hierarchy that places commercial builders and institutional implementations downstream of the protocol substrate, are all expressions of this principle. When in tension, substrate stewardship outranks any individual product or commercial outcome.

2.2 Builder neutrality as architectural guarantee

No builder, including any commercial entity launched alongside the protocol, may receive privileged access at the protocol layer. Once Phase 0 closes, users will be able to switch builders without losing identity, attestations, history, or reputation, and hostile or unavailable builders will be recoverable through the abandonment and linkage primitives. The Foundation enforces this through architecture and audit, not goodwill.

2.3 African-first, not Africa-adapted

Adunai is designed primarily for Africans transacting with Africans, with intercontinental flows as a secondary use case. Priority corridors are intra-African (Lagos–Douala, Accra–Abidjan, Nairobi–Addis, Dakar–Bamako), not London–Lagos or New York–Nairobi. User interfaces assume USSD access, intermittent connectivity, low-end Android phones, multilingual users (French, English, Portuguese, Arabic, Hausa, Swahili, Yoruba, Amharic). Integration points prioritize African mobile-money operators, African banks, and African agent networks. Where African design improves global design, it applies globally, but the direction of travel is African-first.

2.4 Central bank partnership as strategic posture

Adunai treats African central banks not as obstacles to route around, but as structural partners in building African monetary infrastructure. The proposition to a partnering monetary authority: "You want modernized payment rails for your currency but lack the technical budget to build them alone. Adunai provides the infrastructure. Your authorized issuer issues a local-currency stablecoin (cXAF, cNGN, cKES) backed 1:1 by reserves you oversee. Your commercial banks integrate. Your central bank gets real-time visibility into flows. You retain full monetary sovereignty." This is not a compliance strategy; it is a design principle.

2.5 Minimal trust surface

The protocol minimizes what must be trusted. Smart contracts are immutable where possible. Upgrade paths use timelocks and multi-sig governance. Oracle dependencies are minimized and multi-source. The Foundation's authority is narrow: stewarding the protocol, not operating it.

2.6 Composability as the platform

Every primitive is designed to compose with every other primitive and with external protocols. Identity attestations feed credit decisions. Payment transactions generate reputation data. Agent settlements link stablecoin and fiat. Trade finance composes with payments. Builders get a unified SDK, not a collection of siloed APIs.

2.7 Regulatory credibility through integration, not absence

The protocol itself is open-source software and outside direct regulation in most jurisdictions. But Adunai is not positioned as "crypto that routes around regulation." Operating entities engage regulators seriously, and the Foundation's deepest regulatory relationships are with African central banks as partners. The goal is legitimate African public infrastructure, not regulatory arbitrage.

2.8 Security before speed

The protocol holds user funds. Security is not a release blocker to be negotiated; it is a prerequisite. Mainnet deployment requires the bundled pre-mainnet audit, public contests, and graduated value caps. This principle overrides commercial pressure to launch.

2.9 Patient infrastructure for generational change

Adunai is not a product to be built in 18 months and flipped. It is public infrastructure for African economic life, and infrastructure is necessarily patient. This shapes organizational choices: capital sources that understand 5–10 year timelines, partnerships that require years of trust-building, compensation structures that reward durability over velocity, governance structures designed for continuity beyond any individual founder or generation.

3. Architectural Boundaries

Adunai is organized around a three-layer decentralization architecture (A/B/C) that assigns each function to the decentralization model that fits it best.

The architecture sits inside the layer cake of §1.5: Layer 1 (Adunai Protocol) contains the A/B/C decentralization model below. Layers 2–4 are the reference implementations, commercial builders, and institutional implementations that sit above the protocol.

3.1 Layer A, On-chain financial settlement

Purpose: double-spend-resistant settlement for all protocol value movements, with protocol-level fee capture.

What lives here: PaymentsRouterTreasuryAgentRegistry settlement state, SavingsRegistryGroupSavingsTravelRule enforcement hooks.

Why blockchain fits: double-spend prevention is the fundamental financial guarantee; protocol-level fee collection requires atomicity with transfers; value-transferring code needs the strongest correctness guarantees; the Treasury must be transparently auditable.

3.2 Layer B, On-chain identity, trust, and compliance

Purpose: immutable, publicly verifiable anchoring of identity, trust, and compliance primitives.

What lives here: IdentityRegistryHandleRegistryAttestationsRegistryGuardianRegistryAttesterRegistryVouchingRegistryRevocationRegistryIdentityAttestationsIdentityLifecycleComplianceCompletenessLinkedIdentitiesRegistrySelectiveDisclosureReputationExportRateOracleSignerRegistryProtocolConfig.

Why blockchain fits: identity must be globally consistent (a DID means the same thing everywhere); handle uniqueness requires global consensus; institutional verification must be tamper-resistant; attestation existence must be publicly verifiable; compliance evaluation must be reproducible; recovery and linkage primitives must compose with on-chain identity state.

This is the substrate's center of gravity. The identity-first ordering of the contract surface (see §1.6) reflects that fourteen of the 22 core-bundle contracts live in Layer B.

3.3 Layer C, Off-chain peer-to-peer trust (Phase 2+)

Purpose: distribute attestation and reputation data across a peer-to-peer network optimized for mobile devices and African network conditions, with no single point of failure or control.

What lives here (Phase 2+): attestation payloads (typed, signed structured data with on-chain commitments), reputation data, relay operator network, subscription and gossip protocols.

Why peer-to-peer fits: attestations are consulted frequently, every onboarding, every high-value transaction, making on-chain queries expensive at scale; attestations do not require global consensus, only cryptographic verifiability; mobile users benefit from local caching and offline-first design; no central point exists for governments or regulators to pressure; community relays distribute load.

Design inspirations: Nostr's relay architecture, Secure Scuttlebutt's offline-first gossip, IPFS's content-addressing. African-specific optimizations include 3G/4G-bandwidth-efficient protocols, offline-first sync, SMS fallback for critical attestations, storage-conscious clients, and economic incentives for relay operators.

The Phase 0 protocol ships with on-chain AttestationsRegistry (read-write) as the canonical attestation layer. Layer C launches in Phase 2 as a prototype running in parallel with the on-chain registry; by Phase 3, Layer C becomes the canonical attestation surface for most queries, with on-chain retained for institutional-tier attestations and dispute evidence.

3.4 Settlement chain and multi-chain architecture

Layer A and Layer B deploy initially on Base (Coinbase's Ethereum L2). Expansion to Tron is planned for Phase 2 given its dominant role in informal African stablecoin use. Multi-chain architecture is planned in protocol design from v1, even though only Base is live at launch. Adunai does not build its own L1; chain-level decentralization is inherited from the underlying L2/L1 stack.

3.5 Applications layer and institutional integration

The applications layer sits above the protocol. It is not the protocol. It comprises Layer 2 reference implementations, Layer 3 commercial builders, and Layer 4 institutional implementations as defined in §1.5.

The critical architectural insight for institutional adopters: banks, governments, central banks, NGOs, and other institutions do not replace their existing software to use Adunai. They build integration middleware that plugs Adunai into their existing core systems via standard APIs. Their core banking systems, customer databases, and regulatory reporting tools remain intact. Adunai is additive infrastructure.

The protocol does not pick winners at the application layer. Wallet-level privacy primitives, stealth addresses per EIP-5564, per-counterparty DID rotation, selective-disclosure flows for credit and reputation, are Phase 1 deliverables built above the protocol by wallet implementers, not features of the protocol itself. The Phase 0 protocol provides the substrate (DID-default pseudonymity, off-chain attestation payloads, unbounded DIDs per controlling key) that wallet primitives compose with. Section 5 details the four-layer privacy architecture and the boundary between protocol and wallet responsibilities.

3.6 Fiat layer

Off-chain. Comprises the agent network (small businesses converting cash to stablecoin and back), bank partners (for institutional settlement and treasury operations), and mobile-money bridges (where regulatory arrangements permit). Adunai facilitates discovery, reputation, and dispute resolution for these off-chain actors via the Agent Registry, but does not operate the fiat layer directly. Operating fiat triggers money-transmission licensing globally; facilitating discovery of independent operators does not.

4. Identity Portability and the Merge Architecture

This section documents the substrate's response to a problem that earlier identity protocols treated as edge-case but is structural in African contexts: a single human controlling multiple identities that need to be consolidated, possibly across hostile builders, while preserving the cryptographic guarantees of the underlying substrate.

Identity-portability deep-reads through 2026 surfaced that the typical African user does not arrive at Adunai with a single, clean, pre-existing digital identity. Several patterns are common:

Multiple SIMs. A user in Lagos may carry MTN, Airtel, and 9mobile SIMs for cost, coverage, and use-case reasons. Each SIM-bound onboarding flow at a builder could provision a distinct DID.
Shared devices. Household devices in many African contexts are not single-user. A user who onboarded at a relative's phone may later need to consolidate that identity with one they set up on their own device.
Diaspora multi-channel. A user in the diaspora may onboard through a remittance app, separately through a savings app, and later again through a direct aID install, all the same human, three DIDs.
Builder-provisioned vs self-claimed. A user whose first Adunai interaction was inside a commercial wallet (a Layer 3 builder) may later claim the aID experience directly. The transition should not require abandoning the builder-side identity history.
Hostile builder. A user whose first DID was custodied by a builder that becomes hostile (refuses to release the key, attempts to lock the user in) needs an unconditional escape and a way to migrate history forward.

A protocol that treats any of these as edge cases will fail in the African market. Adunai treats all of them as protocol-level concerns, with primitives ratified in Phase 0.

4.2 Three primitives, composed

The portability architecture composes three primitives, all shipping in Phase 0:

The abandonment primitive (GuardianRegistry.initiateAbandonment) handles the hostile-builder case. It is permissionless to invoke with user-side proof of DID ownership, has a 60–90 day timelock during which the current key or any registered guardian can veto, and on expiry writes currentKeyOverride[did]. It does not require pre-registered guardians. It is the primitive that makes "you can always leave" a property of the protocol rather than a promise from a builder.

The handle-routing patch (HandleRegistry update) closes a latent break in handle portability post-recovery. Every signature-gated surface in HandleRegistry·transferHandleinstitutional flows, primary-handle operations, routes key resolution through guardianRegistry.resolveCurrentKey(did) rather than reading IdentityRegistry.controllingKey directly. After a successful recovery (which writes currentKeyOverridenot controllingKey), the user can still transfer handles, claim institutional tier, and use every other handle operation. Without this patch, recovery would orphan a user's handle.

The selfRevokeDID cooling-off patch (RevocationRegistry update) closes a scorched-earth attack vector. Without cooling-off, a hostile current-key holder could call selfRevokeDID instantly during an abandonment timelock and permanently brick the DID before the legitimate user could complete recovery. With the patch, selfRevokeDID gains a cooling-off period whenever the DID has institutional-tier activity, institutional handle, payment history above a ratified threshold, or active attestations. The cooling-off duration is at least as long as the abandonment timelock, making preemption infeasible. Fresh unused DIDs (no activity) can still be self-revoked instantly, preserving the cleanup case.

The linkage primitive (LinkedIdentitiesRegistry) handles the multi-DID consolidation case. The contract surface:

linkDID(primaryDID, secondaryDID, proofs) records linkage between two DIDs the same user controls. Default proof: mutual signatures (both DIDs sign a linkage commitment). Alternative proof: abandonment claim, for cases where one DID was hostile-recovered.
unlinkDID(primaryDID, secondaryDID) removes a linkage with a 30-day timelock and a notification mechanism.
isLinked(didA, didB) and linkedDIDs(did) for queries.

Linked DIDs remain technically distinct on-chain. Attestations stay scoped to the issuing DID. Aggregation across the linkage graph is client and SDK responsibility, not a protocol-level cascade. This preserves the audit clarity of per-DID attestation provenance while letting users see a single identity at the application layer.

Privacy: linkages are stored as commitments, not plaintext DID pairs. The commitment scheme is binding (cannot be forged), hiding (cannot be reverse-engineered to plaintext DIDs), and composable with SelectiveDisclosure's grant model. Reveals are gated by SelectiveDisclosure-issued grants.

Cap: the linkage graph is bounded at five DIDs per user. This covers virtually all real-user scenarios (multi-SIM, multi-device, diaspora multi-channel) while bounding the abuse surface and the gas/return-size of linkedDIDs queries.

KYC interaction: highest-tier-wins applies at the client and SDK aggregation layer, with anti-fraud mitigations preventing a low-tier hostile-recovered DID from being linked to a high-tier DID purely to inherit compliance status. The specific anti-fraud mechanism is ratified separately.

4.3 Composition invariants

The auditors of the Phase 0 bundle verify the following composition invariants across the portability primitives:

Abandonment timelock is at least as long as selfRevokeDID cooling-off duration. An adversarial current-key holder cannot preempt a legitimate abandonment by revoking during the abandonment window.
HandleRegistry routing respects currentKeyOverride. Every signature-gated surface calls guardianRegistry.resolveCurrentKey(did).
Linkage does not compromise SelectiveDisclosure grant scoping. Grants are scoped to the granting DID; aggregation across linked DIDs is client responsibility, not a protocol-level cascade.
Linkage does not create KYC privilege escalation. Highest-tier-wins applies at client aggregation; anti-fraud mitigations prevent escalation via hostile-recovered linkage.
Linkage privacy: commitments not plaintext, with binding and hiding properties verified.
Abandonment veto threshold honours user sovereignty. The mechanism does not allow a single hostile party to indefinitely block legitimate abandonment.
No new Foundation surfaces over user-controlled state. The Foundation gains no callable function over DID lifecycle, abandonment, or linkage state via these primitives, preserving Charter §VIII.
DoS surfaces bounded. The linkage graph is capped at five DIDs. The abandonment primitive is rate-limited via per-DID nonce and abandonment-context-hash uniqueness.

These are bundle-level invariants spanning multiple contracts. Per-contract Pattern A scope notes within the audit cover contract-local checks. The full composition specification is documented separately.

4.4 Why these primitives are protocol-level, not application-level

A reasonable objection: could the merge architecture live at the wallet or SDK layer instead, leaving the protocol minimal?

The answer is no, for three reasons.

First, the abandonment primitive must touch the on-chain key-resolution path. Without currentKeyOverride and the corresponding resolveCurrentKey indirection through GuardianRegistryno application-layer code can produce a verifiable escape from a hostile builder. The cryptographic ground truth lives in the contracts.

Second, the selfRevokeDID cooling-off must compose with the abandonment timelock at the protocol layer. A wallet-layer cooling-off would not prevent a hostile key-holder from directly calling RevocationRegistry.selfRevokeDID on-chain. Only an on-chain cooling-off binds.

Third, the linkage primitive must produce verifiable commitments that auditors, regulators, lenders, and institutional partners can rely on without trusting any particular wallet or SDK. A wallet-layer linkage scheme would be unverifiable by counterparties.

The substrate gains expressiveness by absorbing these primitives. Builders gain neutrality. Users gain genuine portability. The Foundation gains no new authority over user-controlled state; the primitives are role-free and the Foundation cannot un-link, un-abandon, or un-revoke. The architectural commitment is enforced by code.

5. Privacy Architecture

Adunai's identity primitives intentionally publish less than most identity systems. A DID is a key reference; nothing about the human behind it is on-chain unless they choose to publish it. But pseudonymity is not privacy, and Phase 0 protects against a narrower class of adversary than later phases will. This section is honest about both.

5.1 Five layers, in order of strength

Layer 1, DID-default pseudonymity (Phase 0, shipped). Every participant has a DID derived from a key plus salt (IdentityRegistry.deriveDID). On-chain, a DID reveals only that the holder controls a private key. There is no name, no country, no balance, no transaction history attached by the protocol. Wallets that surface only the DID, without registering a handle, without publishing attestations, operate at this layer.

Layer 2, Optional canonical handles (Phase 0, shipped). HandleRegistry lets a DID register a human-readable name. This is opt-in. Registering a handle trades pseudonymity for discoverability: anyone can resolve alice.adunai to its DID and observe everything attached. The tradeoff is appropriate for institutions and businesses that want public verifiability, and explicitly inappropriate for individuals where transaction visibility creates risk. Wallets are responsible for making this tradeoff legible at registration time.

Layer 3, Off-chain dataHash for attestations (Phase 0, shipped). AttestationsRegistry stores only a dataHasha 32-byte commitment to an off-chain claim payload. The actual claim ("Alice's national ID is X", "Bob's salary is Y") never touches the chain. Verifiers receive the payload off-chain through a channel the subject controls, and check it against the on-chain commitment. Attestation existence is public; the content is not. This is the same commitment pattern used by EAS and similar attestation systems.

Layer 4, Wallet-level unlinkability (Phase 1, planned). The Phase 0 PaymentsRouter publishes sender DID, recipient DID, token, and amount of every transfer. For institutional flows this is a feature, auditable settlement is the point. For individuals, it is inadequate. Phase 1 introduces two wallet-side primitives:

Stealth addresses following EIP-5564: the sender generates a per-transaction ephemeral key and derives a one-time recipient address from the recipient's published meta-address, so the recipient is not linkable to a long-lived DID by on-chain observers.
Per-counterparty DID rotation: wallets generate a fresh DID for each counterparty relationship. IdentityRegistry already supports unbounded DIDs per controlling key; Phase 1 surfaces this as default wallet behavior.

Layer 4 produces unlinkability against on-chain observers, not full transaction privacy. Per-transaction amounts and timing remain visible against the one-time addresses; observers with off-chain correlation data can defeat unlinkability heuristically. These are wallet-layer features built on Phase 0 protocol primitives.

Layer 5, Confidential transactions (Phase 3+, conditional). For threat models that demand transaction-level confidentiality against forensic adversaries, not just unlinkability against casual observers, the protocol would need shielded pools (zk-SNARK based, similar in shape to Aztec or Tornado-style designs) integrated with PaymentsRouter. This is not a committed roadmap item. Layer 5 shipping is conditional on hiring a specialist cryptographic engineer, dedicated audit budgets, and demonstrated user demand from threat models that warrant the cost. None of those conditions are currently met. Users requiring this protection class today should use protocols designed for that adversary class.

5.2 Selective disclosure for credit and reputation

Stealth-address transactions are unlinkable by default but must remain provable to specific counterparties on demand. A borrower with two years of stealth-routed payment history should be able to prove that history to a lender without making it public.

EIP-5564 stealth addresses encode each recipient as a meta-address derived from a spending key pair and a viewing key pair. The viewing key controls scanning and detection; the spending key remains separate and grants the ability to move funds.

For per-counterparty unlinkability, wallets generate a distinct stealth meta-address per counterparty relationship, each with its own viewing and spending keys derivable from the user's master seed via HD derivation. On-chain observers see only one-time addresses with no obvious linkage.

To disclose a counterparty relationship's history to a lender, the user hands the lender the viewing private key for that relationship's meta-address, encrypted to the lender's public key so the disclosure is point-to-point. The lender scans on-chain announcements with the viewing key, identifies the one-time addresses, and reconstructs the relevant payment history. The lender cannot spend, cannot link disclosed addresses to other counterparty relationships, and the disclosure does not become public.

This is wallet SDK responsibility, not protocol-level. The protocol provides the substrate (IdentityRegistry's unbounded DIDs, off-chain attestation payloads, PaymentsRouter's ability to send to any address); the wallet derives stealth meta-addresses, encodes EIP-5564 announcements, and implements viewing-key delegation. PaymentsRouter does not change.

The Phase 0 SelectiveDisclosure contract complements this wallet-layer flow: it provides on-chain user-signed grant management for attestation read access, with reader-DID-indexed permissions, lifecycle (grant/revoke/expire), and EIP-712 signature integrity. ReputationExport composes SelectiveDisclosure with AttestationsRegistry to produce portable reputation profiles for lenders, landlords, and visa consultants.

5.3 Honest threat model

Phase 0 plus Phase 1 wallet privacy protects against:

Casual chain-explorer surveillance by neighbors, family members, competitors, ad-hoc tax inspectors, or extortionists without forensic budgets.
Counterparty enumeration by competitors scraping on-chain data to reconstruct a business's customer or supplier list.
Wealth-based extortion targeting observable on-chain accumulation.

It does not protect against:

State-level chain analysis combining on-chain data with off-chain subpoenas (exchange KYC records, ISP logs, mobile-money history, device seizures).
Targeted investigation by Chainalysis-class firms operating at budgets that defeat stealth-address heuristics through cumulative correlated data.
Off-chain compromise of the user's device, recovery guardians, or attested off-chain claim payloads.
Voluntary disclosure by the user. Once a payload is shared with a counterparty, the protocol cannot un-share it.

Stronger threat models, investigative journalists protecting sources, dissidents in adversarial jurisdictions, high-net-worth individuals defending against state-actor surveillance, are explicitly not in Phase 0 scope. Users in those threat models should wait for Phase 3+ shielded pools or use protocols designed for that adversary class.

6. Economic Design

6.1 Revenue model

Adunai protocol revenue derives from four sources, all flowing to the Treasury:

Transfer fees on PaymentsRouter volume (primary).
Handle registration and renewal fees on HandleRegistry.
Foundation share of slashed agent collateral in dispute resolution (irregular).
Attestation fees on high-volume issuance (potential future).

Conservative projection at mature scale (3–5 years post-launch, capturing 1% of African cross-border flows): roughly $20M annual protocol revenue. Aggressive projection (5–7 years, multi-chain, consumer adoption): $100–150M annual revenue. Comparable protocol valuations at $150M/year revenue range from $3B to $10B depending on growth rate and competitive position.

6.2 Fee mechanics

Base transfer fee 0.3% of amount, capped at $5 per transfer. Lower fees for intra-country transfers, attestation-verified counterparties, and high-volume accounts. Constitutional bounds: minimum 0.01% (prevents zero-fee spam attacks), maximum 1% (supermajority + long timelock required to change). Fees are visible on-chain and queryable before submission.

6.3 Treasury allocation

Treasury funds are allocated roughly: 40% operations, 30% ecosystem grants, 20% reserve, 10% agent-network incentives. Allocation is itself governed and can change. This reflects the priority of bootstrapping the ecosystem during early years.

6.4 Reference clients as protocol artifacts

The aID reference identity client, and the Adunai reference wallet, if its held-open Phase 1+ ratification surface resolves to build, are treated as core protocol artifacts rather than peripheral implementations. They are the canonical demonstration of what the protocol enables when its primitives are exposed thoughtfully. Reference clients are maintained as Foundation-funded open-source codebases (MIT/Apache 2.0) that any builder may fork. The Foundation does not ship them as consumer products; it stewards them as developer scaffolding. Multiple community instances are expected to coexist and interoperate.

6.5 Token design (deferred)

Adunai launches without a token. A governance token may be introduced in Year 2 or later, contingent on demonstrated sustained usage, regulatory clarity, and Foundation readiness for decentralized governance. If a token launches, its design will be documented separately. Adunai functions fully without a token; token design risk is decoupled from protocol viability.

7. Governance

7.1 Phase 0, Foundation governance

The Adunai Foundation, a Mauritius purpose foundation under the Foundations Act 2012, stewards the protocol. Foundation responsibilities and constraints are set out in §1.9. The Foundation multi-sig holds nine signers with a 5-of-9 routine threshold (7-of-9 for emergency actions and signer changes) and geographic distribution across all major African regions, the African diaspora, and international advisors.

PAPSS complementarity: the Pan-African Payment and Settlement System is an AU-backed cross-border payment infrastructure developed by Afreximbank, connecting African central banks. Adunai positions explicitly as PAPSS's open-source, permissionless complement rather than a competitor. PAPSS is institutional, central-bank-to-central-bank settlement (regulated, top-down). Adunai is SMB, retail, and builder ecosystem (open, permissionless, bottom-up). The two are complementary at the institutional/retail boundary.

7.2 Phase 2–4, Progressive decentralization

Governance progressively transfers to community stakeholders: community proposals enabled in Year 2 (Foundation still gates execution); delegated voting on non-critical parameters in Year 3; on-chain governance for protocol upgrades in Year 4, with Foundation emergency pause only.

7.3 Mature phase (Year 5+), Full DAO governance

Foundation role reduces to legal steward (maintaining trademarks, charter, regulatory standing). Protocol governance moves entirely on-chain, with token-weighted or reputation-weighted voting. This progression follows patterns proven by Optimism, Uniswap, and Aave, adapted to DPI-stewardship context.

8. Threat Model

8.1 Smart contract vulnerabilities

Mitigations: minimal contract surface; heavy use of audited primitives (OpenZeppelin); single consolidated pre-mainnet audit covering the complete deployed v1 surface (35 contracts + 3 patches), with per-contract scope notes within the bundle; public audit contest (Code4rena or Sherlock); continuous bug bounty (Immunefi) post-launch; upgrade mechanisms with timelock; graduated value caps at initial mainnet deployment. Residual risk: non-zero. No protocol is perfectly secure.

8.2 Oracle and dependency risk

Mitigations: minimize oracle dependencies; RateOracle uses multiple sources with consensus requirements; bridge risk managed by using major audited bridges only, with exposure caps.

8.3 Economic attacks

Mitigations: fees and parameters reviewed by economic researcher pre-launch; agent collateral sized to make fraud economically irrational; reputation systems weighted to prevent Sybil attacks; post-launch monitoring for anomalous patterns.

8.4 Identity and attestation abuse

Mitigations: issuer accreditation registry; revocation mechanisms for compromised attestations; multi-tier social recovery; abandonment primitive for hostile-builder escape; time-bounded attestations with on-chain freshness enforcement.

8.5 Regulatory risk

Mitigations: jurisdictional diversification (Foundation under Mauritius purpose foundation; operating entities in friendly jurisdictions); proactive engagement with African central banks and regulators; protocol design minimizes functions that trigger strict regulations (no custody, no fiat handling, no currency issuance); legal structure separating protocol from services built on top.

8.6 Agent network fraud

Mitigations: staked collateral proportional to settlement capacity; reputation and rating system; dispute resolution with evidence review; fraud detection heuristics at scale; user education on verifying agent accreditation.

8.7 Sybil and spam attacks

Mitigations: proof-of-personhood attestation for sensitive operations (via World ID or equivalent); economic costs on identity creation; rate limiting on high-cost operations.

8.8 Governance capture

Mitigations: constitutional limits on parameter changes; timelocks on all significant decisions; Foundation emergency pause during transition phase; multi-sig requirements with diverse signers; eventual token distribution designed for broad ownership.

8.9 Identity portability and hostile-builder lock-in

Mitigations (all shipping in Phase 0 ahead of mainnet, audited in the bundled engagement): abandonment primitive (GuardianRegistry.initiateAbandonment) will ensure unconditional escape from any custodian; HandleRegistry routing through resolveCurrentKey will ensure handle portability post-recovery; selfRevokeDID cooling-off will prevent scorched-earth preemption of abandonment; LinkedIdentitiesRegistry will enable consolidation of multi-DID histories; composition invariants audited as a bundle (see §4.3). These primitives are role-free; the Foundation cannot act over them.

8.10 Privacy threat model

See §5.3 above. Phase 0 plus Phase 1 wallet privacy protects against casual chain-explorer surveillance, counterparty enumeration, and wealth-based extortion. It does not protect against state-level forensic chain analysis, Chainalysis-class targeted investigation, off-chain compromise, or voluntary disclosure. Phase 3+ shielded pools (Layer 5) are conditional, not committed.

9. Long-Term Vision: Infrastructure for African Monetary Sovereignty

Adunai's longer arc, beyond the five-phase roadmap of §1.10, is to support African monetary sovereignty by providing the technical substrate African monetary authorities currently lack. This vision is deliberately framed as infrastructure that enables possibilities, because the possibilities depend on decisions belonging to African authorities, not to the Foundation.

9.1 Strategic context

African economies face a structural disadvantage in the global monetary system. African central banks hold substantial reserves in foreign currencies, predominantly USD. African cross-border trade routes through foreign currency settlement, forcing two foreign-exchange conversions on what should be a direct African-to-African transaction. African businesses transact internationally in USD. African monetary policy is constrained by Federal Reserve decisions that consider African interests only incidentally.

Previous attempts at addressing this, the ECOWAS "eco" initiative, broader African Union continental currency ambitions under Agenda 2063, the CFA franc arrangement, have struggled for decades with a fundamental coordination problem: deeper monetary integration requires central banks to trust each other's monetary discipline, and trust of this kind has been difficult to establish across 54 sovereign states with divergent economic conditions and varying institutional quality. PAPSS, operational since 2022, represents important institutional progress but addresses settlement rather than currency-level coordination.

Adunai's architectural premise is that the right path forward avoids the trust problem rather than attempting to solve it. Each African central bank retains full monetary sovereignty over its own currency. What's shared is only technical infrastructure, payment rails, identity systems, settlement conventions, that makes African currencies collectively more functional while each remains independently sovereign.

9.2 Four-layer monetary architecture

Country-level digital currency rails. Each participating central bank authorizes a licensed partner to issue a stablecoin representing its local currency: cXAF for CEMAC, cNGN for Nigeria, cKES for Kenya, and similar stablecoins for other partnering countries. Each is backed 1:1 by reserves of its own currency, held in accounts overseen by its own central bank. Each central bank retains complete monetary sovereignty; no coordination with other central banks is required. Failure isolation: problems in one country affect only that country's stablecoin. Progressive activation: central banks can join one at a time.

External stablecoins integrated as first-class. Users who want USD-denominated value use USDC or USDT, integrated natively. The Foundation does not issue a USD-pegged stablecoin. USDC and USDT have established network effects, regulatory acceptance, and global liquidity that the Foundation would not replicate. African users needing USD stability are better served by existing solutions. EUR-pegged, GBP-pegged, and other major-currency stablecoins are similarly supported through integration.

ASU (African Settlement Unit) as measurement and settlement convention. ASU is a weighted basket calculation, similar in concept to the IMF's Special Drawing Rights, representing the aggregate value of participating African currencies. ASU is explicitly not a currency anyone holds. No wallets contain ASU. No reserves back it. It exists only as a calculation convention. Uses: cross-currency settlement routing (cXAF → ASU → cNGN without passing through USD); African economic measurement (a Cameroonian business can see XAF measured against the collective African economy); visibility of collective African economic activity (aggregate ASU-denominated transaction volume as a real-time metric). ASU's basket composition is maintained by the Foundation under a published methodology, subject to community governance as the protocol matures. Because ASU is a calculation rather than a currency, changes to basket composition do not affect anyone's wallet balances.

Aggregate data infrastructure. Adunai generates, as a byproduct of its operations, real-time data about African economic activity that does not currently exist in any consolidated form: country-level transaction volume, intra-African trade patterns, currency utilization, business and individual participation, counterparty network structure. This data is valuable to African central banks, the AfCFTA Secretariat, African development banks, governments, and researchers. The Foundation's role is to make this data available in structured, transparent form.

9.3 What this architecture achieves, and does not attempt

Together the four layers accomplish what a shared African currency alone could not: intra-African trade settles without foreign-currency routing; each African currency becomes more functional on its own terms; collective African economic strength becomes visible without a shared currency instrument; African monetary sovereignty is preserved; regulatory relationships with African monetary authorities become collaborative rather than adversarial; and the political moment for deeper coordination, if it arrives, is not required for the architecture to be valuable.

To be explicit about scope: Adunai does not issue currency (African or foreign); does not create a shared African currency; does not dictate monetary policy; is not a central bank; does not replace African central banks; does not replace the US dollar. The Foundation explicitly does not aspire to monetary authority. Its role is to provide neutral technical infrastructure.

9.4 Generational orientation

The long-term vision is generational. Progress is measured in years and decades, not quarters. Individual founders and executives will come and go; what matters is that the infrastructure, once built patiently with African authorities as partners, outlives any individual contributor and becomes part of Africa's permanent financial substrate. Whether deeper African monetary coordination ever occurs is not Adunai's decision to make. Adunai's contribution is to build infrastructure that makes whatever African monetary authorities choose to pursue more technically feasible.

9.5 AI agents as economic actors, a Phase 3+ direction

By the Phase 3+ timeframe, AI agents transacting on their own behalf, settling small payments, holding budgets, accumulating service histories, contracting with each other and with humans, are likely to be a significant category of economic actor. Adunai's primitives, designed for human and institutional participants, are unusually well-suited to AI participation as a side effect of their generality: each agent can hold a DID, accumulate a portable reputation through typed attestations, operate under spending limits enforced at the payments layer, and recover under the same multi-tier paths available to any other identity. None of this requires AI-specific contracts; it requires only that the primitives remain neutral with respect to who or what is behind a DID. This is forward-looking direction, not a committed roadmap item.

10. Comparison to Existing Systems

10.1 India Stack

Closest peer in spirit. India Stack (Aadhaar, UPI, DigiLocker, account aggregator framework) demonstrates what continental-scale DPI looks like when a single national authority commissions it. Adunai differs by being foundation-stewarded across 54 jurisdictions where no equivalent national authority exists. The architectural pattern, identity-first, payments downstream, attestations as the trust substrate, application ecosystem composed on top, is similar; the political geometry is fundamentally different.

10.2 EU eIDAS, Singapore SingPass, Brazil PIX/DREX

Each is a national or regional DPI substrate operated by a state or supranational authority. None is portable across the African continent. None is permissionless. Adunai positions as the foundation-stewarded equivalent for African economic life, with permissionless composition and African-first design.

10.3 PAPSS

Pan-African Payment and Settlement System. AU-backed, Afreximbank-operated, central-bank-to-central-bank settlement. Complementary to Adunai at the institutional/retail boundary. Adunai is not seeking to replace PAPSS; the two operate at different layers.

10.4 Mobile money

MTN MoMo, Orange Money, M-Pesa, Wave, Airtel Money. Massive adoption, good UX, trusted, ubiquitous agent networks. Siloed per operator, not interoperable, expensive cross-border, no developer access to shared primitives, not portable across countries. Adunai complements mobile money rather than competing directly in domestic P2P.

10.5 African fintech infrastructure

Flutterwave, MFS Africa, Paystack, Wave, NALA. Licensed, regulated, proven at scale, strong developer experience in their niche. Closed APIs rather than protocols, centralized control, per-company integration, limited to payments, no identity layer, no on-chain composability. These companies may become integrators with or competitors to Adunai; protocol neutrality creates room for cooperation.

10.6 Stablecoin infrastructure

Circle, Tether, Bridge, Noah, NALA Rafiki. Stablecoin settlement is proven; these companies have licenses and volumes. Companies or closed networks, not open protocols; they rent infrastructure rather than provide a permissionless substrate; not African-first in design. Complementary to Adunai.

10.7 Decentralized identity

Polygon ID, Ethereum Attestation Service, Worldcoin. Mature tech, open standards. Not integrated with payments; no African issuer ecosystem; no agent network; no African attestation types. Adunai uses similar patterns (AttestationsRegistry's commitment scheme aligns with EAS) and adds the African-specific ecosystem.

10.8 DeFi payment protocols

Uniswap, Aave, Superfluid. Unstoppable, composable, proven protocol design. Not designed for retail payments, no fiat gateway, no identity, not optimized for African regulatory or UX reality. Lessons from these protocols inform architecture; Adunai adopts proven patterns (factories, access control, timelocks, governance) while adapting to a DPI use case.

11. Open Questions and Invitations

This document is a draft. The authors specifically invite critique and contribution on the following open questions, several of which await ratification:

Abandonment primitive, user-side proof requirement design (phone/email OTP with hashed commitment, off-chain proof package with dispute window, attestation re-verification, tiered combination).
Abandonment timelock duration, 60 versus 90 days, with composability against selfRevokeDID cooling-off.
Abandonment veto threshold, single-key sufficient, single guardian, or M-of-N.
Linkage proof packaging, mutual signature default plus abandonment-claim alternative ratified; specific encoding open.
Linkage commitment scheme, commitments-not-plaintext and SelectiveDisclosure-gated reveal ratified; specific scheme open.
Linkage KYC anti-fraud mitigations, highest-tier-wins ratified; preventing low-tier hostile-recovered linkage to high-tier DIDs open.
selfRevokeDID cooling-off activity threshold, institutional handle, minimum payment history, active attestations, or combination.
Adunai-compatible certification standard, Foundation oversight model and community stewardship structure.
Token design, when, if, and how to introduce a governance token.
Local-currency stablecoin issuance, direct via banking partner, or partnership with existing issuer.

The authors will update this document as answers emerge. Readers with strong views on any of these are invited to contribute.

12. Acknowledgments

Adunai draws on the work of many prior projects and researchers. Particular debts are owed to: India's National Payments Corporation and the Aadhaar program, whose DPI work is the closest peer in spirit; the Ethereum Foundation and its researchers, whose work on account abstraction, rollups, and attestations underpins this design; the Optimism, Uniswap, and Aave foundations, whose governance models inform progressive decentralization; the Pan-African Payment and Settlement System and Afreximbank, whose institutional work complements Adunai's open-protocol surface; African fintech pioneers (M-Pesa, Flutterwave, Wave, NALA) whose work demonstrated the scale of the problem and the appetite for solutions; the African developer and entrepreneur community, whose contributions shape this design; and the Wolof-speaking peoples of Senegal, Gambia, and Mauritania, from whose language "Aduna", the root of our name, comes.

Appendix A, Glossary

Adunai: the protocol. Pronounced ah-DOO-nai. Derived from the Wolof word "Aduna" meaning "world" or "earth."
aID: the user-facing portal client for an Adunai identity. A reference implementation, not a new identifier. The DID is the canonical identifier.
Sign in with Adunai: the OAuth-pattern integration brand by which builder applications authenticate users against their Adunai identity.
DID: Decentralized Identifier. A user's canonical on-chain identity, stored as bytes32 in IdentityRegistry.
Handle: Human-readable name resolving to a DID, registered in HandleRegistry.
Attestation: A typed, signed claim about a DID issued by an accredited issuer.
Vouch: A signed claim by one DID in support of another, used as anti-Sybil and reputation signal.
Guardian: A DID designated by another user to co-sign social-recovery operations.
Abandonment: The protocol primitive (GuardianRegistry.initiateAbandonment) by which a user can unconditionally escape from a custodian without pre-registered guardians.
Linkage: The protocol primitive (LinkedIdentitiesRegistry) by which a user consolidates multiple DIDs into one identity graph.
Agent: Fiat-gateway operator registered in AgentRegistry.
Foundation: The Adunai Foundation, the Mauritius purpose foundation stewarding the protocol.
Treasury: On-chain contract holding protocol fees, governed by timelocked multi-sig.
ASU: African Settlement Unit. A basket calculation, not a currency.
Base: Coinbase's Ethereum L2, the primary settlement chain.
DPI: Digital Public Infrastructure. The category position Adunai occupies for African economic life.

Appendix B, References

To be completed in later revision.

Appendix C, Detailed Contract Specifications

Detailed contract specifications are documented separately.

Appendix D, Audit Scope

The bundled pre-mainnet audit scope covers the deployed v1 surface (35 contracts + 3 patches), including composition invariants across the portability primitives.

Document status: v0.3, draft for discussion. Not final. Not audited. Not a solicitation for investment.

Contact: [TBD, update with Adunai Foundation contact upon establishment]