Quick start/The Charter

The Adunai Foundation, Charter

Version 0.1, Working Draft for Legal Counsel Review Status: Template. Not legally filed. Subject to jurisdiction-specific adjustments.

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

Preamble

This charter establishes the structure, purpose, authority, and limitations of The Adunai Foundationthe non-profit entity stewarding the Adunai protocol. The Foundation exists to serve the protocol and its users. Its authority is bounded. Its obligations are enumerated. Its transparency is mandatory.

This document is a working draft prepared for review by specialized crypto legal counsel. It reflects architectural and governance intent. Specific legal language will follow counsel guidance on the chosen jurisdiction.

Article I, Identity and Purpose

Section 1.1, Name

The entity is The Adunai Foundation (the "Foundation"). The name is a single unit and is not abbreviated in formal documents.

Section 1.2, Jurisdiction

The Foundation is incorporated in Mauritius as a purpose foundation under the Foundations Act 2012 (subject to counsel verification of 2026 fitness with Liechtenstein or Cayman as fallback). This jurisdiction is chosen for:

  • Legal clarity on non-profit purpose foundations holding protocol treasuries (Mauritius Foundations Act 2012 specifically supports purpose foundations distinct from beneficiary-foundations, aligning with the Adunai stewardship model)
  • African Continental Free Trade Area (AfCFTA) member jurisdiction, alignment with the protocol's African-first positioning while remaining non-aligned with any single African economy
  • Precedent with comparable protocol foundations (Ethereum Foundation in Zug, Optimism Foundation, Aave Companies); Mauritius provides a comparable legal-clarity surface with African jurisdictional alignment
  • Tax treatment appropriate for non-profit operations with international grant-making

Section 1.3, Purpose

The Foundation exists to steward Adunai as Africa's non-state Digital Public Infrastructure (DPI) substrate: an open, permissionless financial-and-identity infrastructure protocol designed for African economic life, peer to India Stack, EU eIDAS, Singapore SingPass, and Brazil PIX/DREX in DPI category, sharing the substrate-not-product positioning, though with narrower current scope (Adunai covers identity, attestations, reputation, payments, savings, recovery, linkage; India Stack additionally includes DigiLocker credentials and ONDC commerce; eIDAS includes regulated qualified trust services; SingPass uses government-attested data), and architecturally distinct in being foundation-stewarded across 54 African jurisdictions rather than government-operated within one. The Foundation's authority is bounded by constitutional governance as enumerated in Article VIII of this Charter; the bounded-authority discipline is what makes Adunai legible to institutional partners across multiple sovereignties, and what protects user sovereignty over identity from platform or institutional ownership.

Specifically, the Foundation exists to:

  1. Steward the Adunai protocol as African DPI substrate, identity-first (identity, attestations, reputation, compliance, recovery, linkage are the architectural heart; finance is downstream as a first-class application)
  2. Maintain the protocol's neutrality, builder-neutrality, and progressive decentralization over time
  3. Support the multi-layer ecosystem (reference implementations including aID, and the Adunai Reference Wallet if developed, held open as a Phase 1+ ratification surface; commercial builders across the eight category taxonomy; institutional implementations including government DPI integrations and central bank stablecoin partnerships)
  4. Pursue alignment with regulators, central banks, AU Digital Transformation Strategy bodies, AfCFTA Secretariat, Smart Africa, and international DPI bodies as the protocol matures, on behalf of the substrate's open-infrastructure positioning
  5. Safeguard the protocol's treasury and distribute it according to enumerated purposes
  6. Enforce, through architecture rather than goodwill, the constitutional guarantees of identity portability and builder neutrality encoded in protocol primitives

The Foundation does NOT exist to:

  • Operate commercial services on the protocol (separate for-profit entities may do so)
  • Own or control user funds beyond the Treasury
  • Grant itself authority not explicitly enumerated in this charter
  • Survive beyond its usefulness, Article XI defines its progressive decentralization

Section 1.4, The Name's Origin

The name "Adunai" derives from "Aduna," the Wolof word for "world" or "earth." The Foundation acknowledges this linguistic and cultural heritage. Where the Foundation's activities involve the Wolof-speaking communities of Senegal, Gambia, or the diaspora, the Foundation seeks to engage respectfully and meaningfully with those communities.

Article II, Values and Principles

The Foundation commits to the following values as binding constraints on its decisions:

Section 2.1, Openness

All protocol code is open source. All governance decisions are publicly recorded. All treasury flows are observable on-chain. Minutes of board meetings are published within 30 days.

Section 2.2, Neutrality

The Foundation does not favor specific applications, builders, or users over others. Grant decisions are made on merit. Protocol upgrades serve all users, not specific constituencies.

Section 2.3, Minimum Necessary Authority

The Foundation exercises only the authority required to fulfill its purposes. When authority can be safely transferred to the community, it is. Progressive decentralization is not optional; it is mandatory.

Section 2.4, Long-Term Orientation

Decisions are made on multi-year horizons. Short-term revenue maximization is explicitly deprioritized.

Section 2.5, Cultural Respect

The Adunai protocol serves African users and communities. The Foundation's operations, communications, and partnerships reflect respect for the diverse cultures, languages, and economic realities of the continent. The Foundation does not presume to speak for African users or communities; it listens and adapts.

Section 2.6, Safety Before Speed

Protocol deployments, upgrades, and expansions prioritize safety. Deadlines do not override audit requirements. User fund safety is the highest operating priority.

Section 2.7, Respect for Monetary Authority

Currency issuance is the sovereign authority of recognized monetary authorities. The Foundation explicitly does not aspire to monetary authority and commits to the following:

  • The Foundation does not issue currency, tokens representing sovereign claims, or instruments that function as a replacement for sovereign money
  • This restriction applies to African currencies (local-currency stablecoins like cXAF, cNGN, cKES are issued by authorized licensed partners under central bank oversight, not by the Foundation) and to foreign currencies (the Foundation does not issue a USD-pegged, EUR-pegged, or other foreign-currency stablecoin). External stablecoins (USDC, USDT, and similar) are integrated as first-class citizens on Adunai but are the products of their respective issuers, not of the Foundation.
  • The African Settlement Unit (ASU), described in Whitepaper Section 11.2, is not a currency. ASU is a calculation convention, a weighted basket measurement similar to the IMF's Special Drawing Rights. No one holds ASU; no reserves back it; it exists only as a mathematical reference for cross-currency settlement routing and economic measurement. The Foundation maintains the ASU basket methodology as a governance responsibility, subject to community oversight and the standard timelock and multi-sig processes that govern other protocol parameters.
  • The Foundation supports African monetary authorities as structural partners, providing technical infrastructure that strengthens their capabilities rather than circumventing them
  • Any long-term vision for deeper African monetary integration (coordinated reserve management, basket-backed regional instruments, continental currency frameworks) is explicitly a matter for African monetary authorities and political institutions to determine, not for the Foundation to direct

This posture distinguishes Adunai from crypto protocols that position themselves in opposition to monetary authorities. The Foundation's view is that African monetary sovereignty is a legitimate aspiration best served by patient infrastructure work with authorities as partners, not by unilateral action that provokes adversarial responses.

Section 2.8, African-First Positioning

Adunai is designed primarily for Africans transacting with Africans, with intercontinental flows as a secondary use case. The Foundation's strategic resources, partnerships, grants, staffing, governance, prioritize African institutional relationships (central banks, pan-African banks, AfCFTA Secretariat, Afreximbank, African Development Bank, African Union bodies) over international corridor partnerships. International partnerships remain welcome but are not the Foundation's primary focus.

This is not a temporary positioning to be abandoned when convenient; it is a permanent principle. The Foundation commits to allocating at least 70% of its operational resources (staff time, grant disbursements, partnership engagement) to African-first priorities through Phase 4.

Article III, Governance Structure

Section 3.1, Board of Directors

The Foundation is governed by a Board of Directors ("the Board") comprising:

  • 3 Founding Directorsserving 4-year initial terms, selected at Foundation formation
  • 2 Independent Directorsselected by the Board, serving 3-year terms
  • 2 Community-Elected Directors (from Year 2), serving 2-year terms, elected by a defined community constituency

Total: 7 directors. Odd number ensures tie-breaking capability.

Directors must:

  • Have no material conflict of interest with Foundation activities (specific disclosure requirements in bylaws)
  • Commit minimum time per month (10 hours for most directors, 40+ hours for Executive Director)
  • Complete ethics and security training annually

Directors may not:

  • Hold positions at companies that are material protocol service providers (creates conflict)
  • Accept compensation from parties affected by Foundation decisions
  • Use Foundation authority for personal commercial benefit

Section 3.2, Executive Director

The Board appoints an Executive Director who:

  • Executes Board decisions and operational matters
  • Represents the Foundation externally
  • Hires and manages Foundation staff
  • Reports to the Board monthly
  • May be removed by simple majority Board vote

Section 3.3, Advisory Councils

The Foundation maintains advisory councils (non-governing):

  • Technical Advisory Council: senior engineers and security researchers, advising on protocol upgrades and audit strategy
  • Regulatory Advisory Council: legal and policy experts from target jurisdictions, advising on regulatory engagement
  • Community Advisory Council: builders, users, and partners, advising on ecosystem priorities

Advisors serve 2-year terms, renewable. Advisor recommendations are not binding but are documented and responded to.

Section 3.4, Multi-Sig Signers

The on-chain Treasury multi-sig comprises 9 signers:

  • 3 Foundation directors (rotating)
  • 3 technical advisors from the Technical Advisory Council
  • 3 ecosystem representatives nominated by the Community Advisory Council

Threshold: 5-of-9 for routine disbursements. 7-of-9 for signer changes or emergency actions.

Signers must:

  • Use hardware wallets (Ledger or Trezor)
  • Complete annual security training
  • Not have material conflicts with the disbursement recipients
  • Be geographically distributed across at least 3 continents
  • Publicly declared (no anonymous signers on the multi-sig)

Article IV, Authorities and Limitations

Section 4.1, Enumerated Authorities

The Foundation has authority to:

  1. Propose and execute protocol contract upgrades (via timelock and multi-sig)
  2. Accredit issuers for the Attestations Registry
  3. Configure Attestation schemas
  4. Adjust protocol fee rates within constitutional limits (0.01% floor, 1% ceiling)
  5. Disburse Treasury funds for purposes enumerated in Article VI
  6. Represent the protocol to regulators, institutions, and media
  7. Engage contractors, employees, and advisors
  8. Dispose of Foundation-owned intellectual property (trademarks, domain names, protocol codebase copyrights)
  9. Enter partnerships with external entities (within Article V limits)
  10. Initiate arbitration of agent disputes during the initial phase

Section 4.2, Reserved Limitations

The Foundation may NOT:

  1. Freeze, reverse, or censor user transactions
  2. Access user private keys or control user identities without explicit user authorization
  3. Disburse Treasury funds for purposes not enumerated
  4. Introduce backdoors or kill switches to the protocol
  5. Favor specific users or builders except through transparent grant programs
  6. Issue a protocol token without Board supermajority vote AND community ratification
  7. Extend its own authority without amendment to this charter (Article XII)
  8. Survive its decentralization schedule (Article XI)

Section 4.3, Veto and Emergency Powers

The Board may pause protocol contracts in response to:

  • Confirmed smart contract vulnerability actively being exploited
  • Regulatory order from a court of competent jurisdiction
  • Clear and present threat to user funds

Pause requires 7-of-9 multi-sig and documented rationale. Pause may not exceed 14 days without community ratification (defined in Article XI).

Article V, Partnerships and Commercial Relationships

Section 5.1, Commercial Separation

The Foundation does not itself operate commercial services on the protocol. Commercial operations (products, services, fiat gateways, premium offerings) are undertaken by separate for-profit entities ("commercial builders"). The Charter names no commercial builder and confers no builder any special status: every commercial builder is one builder among many.

Section 5.2, Commercial builders

Commercial builders are for-profit companies that build products and services on the Adunai protocol. The Foundation and any commercial builder are legally and operationally separate:

  • Different boards
  • Different treasuries
  • Different employees (some may consult to both but not simultaneously employed)
  • Different IP ownership (the Foundation owns the Adunai protocol trademark; each commercial builder owns its own corporate and product trademarks)
  • Different brand foundations (the Adunai brand foundation at brand-foundation/ is locked Phase 0 and Foundation-stewarded; each commercial builder's brand foundation is its own work-product)

The Foundation may grant any commercial builder:

  • Licenses to use Foundation IP on reasonable terms
  • Grant funding on the same terms as other grantees (no preferential treatment)
  • Contract engagements for specific services, at arm's-length pricing

The Foundation may NOT:

  • Own equity, tokens, profit share, or any other financial stake in any commercial builder
  • Receive dividends or profit share from any commercial builder
  • Favor any commercial builder in grant, accreditation, or protocol decisions

Neutrality guarantee, no builder equity (amended 2026-07-02, founder authority, pre-formation). The Foundation holds no equity, tokens, or financial stake in any commercial builder on the protocol, including any founding operating company and any other. This supersedes and withdraws the prior arrangement under which the Foundation would have held a 20% equity stake in the founding commercial company; that arrangement is withdrawn before Foundation formation, and the Foundation will be incorporated carrying no builder equity. A Foundation financially exposed to one builder cannot credibly claim not to pick winners; this guarantee removes that exposure. (Made under founder authority in the pre-formation period; post-formation Charter changes follow the Article XII amendment process; subject to counsel review at formation.)

Section 5.3, Other Partnerships

The Foundation may partner with:

  • NGOs and development organizations
  • Governments and regulatory bodies
  • Educational institutions
  • Commercial entities on specific projects

All partnerships are disclosed publicly with terms. Partnerships that create material financial obligations require Board approval.

Article VI, Treasury Governance

Section 6.1, Sources

The Treasury receives:

  • Protocol fees from Payments Router
  • Handle registration and renewal fees from Handle Registry
  • Slashing proceeds from Agent Registry disputes
  • Direct donations
  • Grant income (if the Foundation receives grants from external funders)

Section 6.2, Purposes

Treasury funds may be used for:

  1. Foundation operations: salaries, rent, travel, legal, accounting, insurance
  2. Protocol development: engineering, security audits, formal verification
  3. Ecosystem grants: funding to third-party builders, researchers, educators
  4. Agent network support: subsidized onboarding, tooling, education for fiat gateway agents
  5. Strategic reserve: held against future operational needs and unforeseen events
  6. Regulatory engagement: legal counsel, policy research, advocacy

Section 6.3, Allocation Targets

Target allocation (adjustable by Board vote):

  • Operations: 40%
  • Ecosystem grants: 30%
  • Reserve: 20%
  • Agent network: 10%

Allocations may be rebalanced up to 10% per year without external ratification. Larger rebalances require community ratification.

Section 6.4, Transparency Requirements

The Foundation publishes:

  • Quarterly treasury reports showing inflows, outflows, and balances by category
  • Annual financial statements audited by a reputable accounting firm
  • Grant records including recipients, amounts, purposes, and outcomes
  • Real-time on-chain transparency via the Treasury contract

Classified information (ongoing legal matters, security incidents, pending partnership negotiations) may be temporarily withheld but must be disclosed upon resolution.

Section 6.5, Investment Policy

The Foundation does not speculate with Treasury funds. Reserves are held in:

  • Stablecoins (primarily USDC)
  • Short-duration US Treasury bills via tokenized vehicles
  • Bank deposits at jurisdictional banks rated investment grade

No more than 10% of reserves in any single asset other than USDC. No leveraged positions. No lending except to protocols with explicit Foundation approval and time-limited exposure.

Article VII, Ecosystem Grants

Section 7.1, Grant Principles

The Grants Program:

  • Funds work advancing the protocol's purposes
  • Does not purchase equity or tokens in grantees
  • Does not create obligations on recipients beyond deliverables
  • Is merit-based and transparent

Section 7.2, Grant Types

Detailed in the Grants Program document. Summary:

  • Research grants: protocol research, academic work
  • Development grants: SDK integrations, infrastructure tools, reference implementations
  • Ecosystem grants: applications demonstrating value of the protocol
  • Community grants: education, documentation, community building
  • Public goods grants: open-source infrastructure benefiting the ecosystem broadly

Section 7.3, Grant Governance

Grants are decided by:

  • Small grants (<$25K): Executive Director approval
  • Medium grants ($25K–$250K): Grants Committee approval
  • Large grants (>$250K): Board approval

All grants are published within 30 days of award.

Article VIII, Protocol Stewardship

Section 8.1, Upgrade Authority

The Foundation proposes protocol upgrades. Upgrades require:

  • Technical Advisory Council review
  • 14-day public comment period (RFC process)
  • Multi-sig approval (5-of-9)
  • 14-day on-chain timelock before execution

Emergency security patches may bypass the RFC period (not the timelock) with 7-of-9 multi-sig and public disclosure of the emergency.

Section 8.2, Protocol Parameters

The Foundation may adjust parameters within constitutional limits:

  • Fee rates: 0.01%–1% (soft limits; changes require Foundation multi-sig)
  • Timelock durations: minimum 24 hours, maximum 30 days
  • Agent collateral requirements: minimum 5% of max single settlement
  • Handle registration fees: must be economically reasonable

Section 8.3, Constitutional Limits

Certain protocol properties are constitutional and cannot be changed without supermajority community ratification:

  • User fund custody (the protocol does not custody user funds; user keys control assets)
  • Open access (anyone can register an identity; no permissioning at the protocol layer)
  • Fee ceiling (1% maximum)
  • Treasury disbursement permanence (funds once disbursed cannot be clawed back)
  • Identity portability (users can recover their DIDs from hostile or unavailable custodians via the GuardianRegistry.initiateAbandonment primitive without Foundation cooperation or pre-registered guardians; the Foundation has no surface to block, delay, or compromise a user's portability)
  • Identity linkage / merge sovereignty (users can link DIDs they control via LinkedIdentitiesRegistry for the African modal multi-DID case; linkage proofs are user-initiated; the Foundation has no surface to forcibly link or unlink user-controlled DIDs)

The portability and linkage primitives are architectural manifestations of this charter's commitment to user-controlled state. The Phase 0 substrate closes the identity-portability gap by adding GuardianRegistry.initiateAbandonmentthe HandleRegistry routing patch (resolveCurrentKey consultation), the RevocationRegistry selfRevokeDID cooling-off, and the new LinkedIdentitiesRegistry contract. These primitives ship in Phase 0 ahead of mainnet.

Section 8.4, Institutional Verification Governance

The HandleRegistry contract implements a three-layer trust model. Layer 3, institutional verification with a visual tick, is the Foundation's specific governance responsibility. This section defines how the Foundation manages this tier.

8.4.1, Verifier categories. The institutional verification tier covers these institutional types, each with its own authorized verifier set:

  • .bank.adunailicensed banks, verified by approved banking regulators or audit firms
  • .gov.adunaigovernment entities, verified by country-level eGovernment authorities where integrated
  • .health.adunaihealthcare institutions, verified by medical boards or health ministries
  • .edu.adunaiaccredited educational institutions, verified by accreditation bodies
  • .org.adunairegistered NGOs, verified by accounting firms or regulatory registries
  • .telco.adunaitelecom operators, verified by telecom regulators
  • .utility.adunaiutility providers, verified by sector regulators
  • .press.adunaimedia organizations, verified by press councils or similar bodies

8.4.2, Verifier authorization. The Foundation authorizes verifiers for each institutional category via multi-sig with 14-day timelock. Each verifier authorization is bounded by expiry (default: 2 years) and must be renewed. Verifiers are chosen based on:

  • Independence from the institutions they verify (no conflict of interest)
  • Technical capacity to conduct verification
  • Legal standing in the jurisdiction they serve
  • Willingness to publish verification methodology
  • Financial responsibility (insurance or bond, as appropriate to the category)

8.4.3, Verifier obligations. Authorized verifiers commit to:

  • Publish their verification methodology publicly
  • Document evidence for each verification on-chain (as a hash)
  • Renew verifications annually or per the institutional category default
  • Revoke verifications when legitimately warranted (sanctioned institution, regulatory action, confirmed fraud)
  • Disclose conflicts of interest
  • Respond to disputes within 14 days
  • Maintain insurance or bond against fraudulent verifications where the institutional category is financially sensitive

8.4.4, Foundation oversight. The Foundation:

  • Maintains a public registry of authorized verifiers per category
  • Publishes annual audit reports on verifier performance
  • Can revoke verifier authorization for cause (fraud, systematic error, non-responsiveness) via timelock
  • Arbitrates disputes between institutions and their verifiers
  • Curates and updates the reserved name list to prevent impersonation attempts
  • Cannot itself issue institutional verifications (verifier role is strictly third-party)

8.4.5, Verification revocation protections. Once an institutional verification is issued, revocation is timelock-gated (14 days). This prevents verifier misuse, a verifier cannot revoke a legitimate institution's verification capriciously. During the timelock, the institution may contest the revocation through the Foundation's dispute process.

8.4.6, Impersonation takedown. For impersonation attempts that slip through reserved name protections in the base namespace (e.g., a user registers ecobank.adunai to impersonate Ecobank), the Foundation may reclaim the handle via governance takedown. This requires:

  • Documented evidence of impersonation or bad-faith registration
  • 14-day timelock
  • Multi-sig approval (5-of-9)
  • Reclaimed handle transferred to the legitimate entity if they verify, or burned

The Foundation does not have authority to reclaim handles absent clear impersonation evidence. Good-faith first-come-first-served registrations in the base namespace are protected.

Section 8.5, Layer C Peer-to-Peer Network Governance

Adunai's architecture includes Layer C, a peer-to-peer attestation relay network that operates off-chain (see Whitepaper Section 3.3). Layer C is fundamentally different from Layers A and B: it is not governed by smart contracts, and the Foundation's role here is curator and coordinator, not operator.

8.5.1, Layer C is community-operated by design. The Foundation does not own, operate, or control any Layer C relay. Relays are run by volunteers, commercial operators, community groups, and institutions. The Foundation's role is to publish standards, curate reference implementations, and support ecosystem development, not to run infrastructure.

8.5.2, Layer C protocol specification. The Foundation maintains the Layer C protocol specification as a living document. Changes to the specification follow the same RFC/timelock/multi-sig process as protocol upgrades (Section 8.1). The specification is open source and versioned. Anyone may implement a conformant relay or client.

8.5.3, Relay directory. The Foundation maintains a public directory of known relays (similar to a DNS). Relays may self-register and be included after basic verification (uptime, spec conformance). The directory is advisory, not prescriptive, users and applications may connect to any relay they choose, listed or not.

8.5.4, Relay operator standards. The Foundation publishes (but does not enforce) standards for relay operators:

  • Uptime expectations
  • Data retention policies
  • Abuse handling (spam, illegal content)
  • Attestation replication and redundancy
  • Bandwidth efficiency best practices
  • Regional coverage guidelines

8.5.5, Economic model for relays. In Phase 2+, relays can earn small fees in stablecoin for providing attestation storage and query service. The economic model is set by the protocol (fee splits, billing mechanisms) and governed through the same parameter adjustment process as other protocol fees. The Foundation does not collect a cut of relay earnings, relay fees flow directly between users and operators.

8.5.6, Layer C censorship resistance. The Foundation commits to Layer C being genuinely censorship-resistant:

  • No relay operator is required or authorized by the Foundation
  • Users and applications are free to connect to any relay
  • The Foundation will not operate takedown powers over Layer C content (that authority exists only for Layer B institutional handles, not for Layer C attestations)
  • If specific content must be removed for legal reasons in a jurisdiction, that is the responsibility of relay operators in that jurisdiction, not the Foundation

8.5.7, Funding Layer C development. The Foundation's Grants Program Track 2.7 (Layer C Peer-to-Peer Infrastructure) funds Layer C development and bootstrapping. This is a structural commitment to Layer C's existence: without Foundation funding support during Phase 1–2, Layer C would be unlikely to emerge organically.

8.5.8, Failure mode. If Layer C fails to achieve adoption or technical viability, the Foundation may continue to support on-chain AttestationsRegistry (Phase 0–1 architecture) indefinitely as a fallback. Layer C is the preferred direction, not an absolute requirement for protocol function. Users and applications retain the option of on-chain attestation queries even as Layer C matures.

Section 8.6, Reference-Client Governance

Adunai's Layer 2 contains foundation-stewarded reference implementations, specifically aID (the reference identity client and "Sign in with Adunai" integration brand) and the Adunai Reference Wallet (held open as a Phase 1+ ratification surface; if developed, a forkable wallet scaffold). The Foundation does not ship these as consumer products; it stewards them as developer scaffolding and community-owned reference codebases.

8.6.1, Reference, not canonical. Reference implementations are reference, not canonical. The aID app is the user's most powerful interface to their Adunai identity (the DID), but it is not the privileged or canonical entry point. Users can enter the Adunai ecosystem through any Adunai-compatible client and arrive at aID later. Identity lives at the DID level (protocol), not at the app level. Reference implementations exist to:

  • Demonstrate the protocol's intended user experience and integration patterns
  • Provide a forkable starting point for builders constructing their own clients
  • Anchor the "Sign in with Adunai" integration standard for the broader ecosystem
  • Carry the multi-tier recovery UX (Tier 1 time-locked phone/email, Tier 2 social guardians, Tier 3 KYC re-verification) in a form builders can study and adapt

8.6.2, Foundation does NOT ship consumer products in Phase 0. Reference implementations exist as developer scaffolding (forkable code), not as Foundation-marketed consumer products. This is intentional separation: the Foundation stewards substrate; commercial builders build consumer products on top of the substrate. The Foundation's marketing reach is limited to "here are the reference implementations; here is how to fork them; here is the integration standard."

8.6.3, Community stewardship + Foundation oversight. Reference codebases are community-stewarded with Foundation oversight. The Foundation maintains ultimate veto authority over reference-implementation releases (security gating, compatibility with protocol substrate, alignment with "Adunai-compatible" certification standard) but day-to-day development is community-led. The specific oversight model, committee structure, maintainer designation, RFC process, is itself a future governance design question.

8.6.4, Adunai-compatible certification standard. The Foundation publishes a certification standard for clients claiming "Adunai-compatible" status. Clients claiming the standard must support:

  • Bidirectional flow (both "Sign in with Adunai" and "Get your Adunai ID" patterns)
  • Multi-tier recovery (clients MUST surface all three recovery tiers; users choose at signup)
  • Cooperative handoff (clients MUST support standard handoff protocol when user requests builder switch)
  • Non-interference with GuardianRegistry.initiateAbandonment (clients cannot block, delay, or compromise a user's invocation of the abandonment primitive)
  • Routing through guardianRegistry.resolveCurrentKey(did) (clients must consult the canonical key-resolution path, not IdentityRegistry.resolve(did).controllingKey directly)

The certification standard is publishable; conformance is voluntary; non-conformant clients can still integrate with the protocol but lose the "Adunai-compatible" claim. The Foundation has no authority to block non-conformant clients from the protocol (per Charter §2.2 neutrality + §8.3 open access).

8.6.5, Future evolution. Phase 2+ may warrant a separate operational non-profit entity (provisionally "Adunai Trust", a three-entity structure: the Adunai Foundation as steward; a commercial builder; and a reference-client operator). This is a future governance decision, not a current commitment. For Phase 0–1, reference-client stewardship sits inside the Foundation under this section.

Article IX, Regulatory Engagement

Section 9.1, Principles

The Foundation engages regulators:

  • Proactively, before problems arise
  • Transparently, publishing regulatory communications
  • Constructively, seeking workable frameworks
  • Honestly, acknowledging regulatory concerns

Section 9.2, Target Jurisdictions

Priority regulatory engagement in:

  • Cameroon, Nigeria, Kenya, Senegal, Ghana (Tier 1, largest users)
  • Egypt, South Africa, Côte d'Ivoire, Rwanda, Ethiopia (Tier 2)
  • BIS, IMF, World Bank as international engagement
  • EU via MiCA (for diaspora-to-Africa flows)
  • US via FinCEN and state regulators (for diaspora flows)

Section 9.3, Lobbying Position

The Foundation lobbies for:

  • Clarity on open-source protocol status (not subject to money transmission licensing)
  • Clear rules for attestation issuers
  • Interoperability standards between stablecoins and fiat rails
  • Consumer protection for end users

The Foundation does not lobby against:

  • Legitimate consumer protection
  • Anti-money laundering frameworks applied to intermediaries (not to the protocol itself)
  • Reasonable KYC requirements for regulated services

Article X, Conflict of Interest and Ethics

Section 10.1, Disclosure

All directors, officers, and senior staff disclose annually:

  • Material financial interests in crypto projects
  • Advisory or board positions
  • Material holdings in protocols or companies that could affect Foundation decisions
  • Family and household member conflicts

Section 10.2, Recusal

Any person with a material conflict recuses from related decisions. Recusals are documented.

Section 10.3, Post-Employment Restrictions

Former directors and officers may not accept positions at material protocol service providers within 1 year of departure. Standard non-compete and non-disclosure obligations apply to all staff.

Section 10.4, Whistleblower Protection

The Foundation maintains anonymous reporting channels for violations of this charter, with legal protection for whistleblowers.

Article XI, Progressive Decentralization

Section 11.1, Commitment

The Foundation is committed to progressive decentralization. The Foundation's authority decreases over time as community governance takes over.

Section 11.2, Schedule

Year 1: Foundation operates with full governance authority. Community input via advisory councils.

Year 2: Community proposal mechanism launched. Foundation retains execution authority; community can formally propose.

Year 3: Delegated voting enabled for non-critical parameters. Fee adjustments, grant allocations transition to community vote with Foundation review.

Year 4: On-chain governance for protocol upgrades. Foundation retains emergency pause authority only.

Year 5: Foundation role reduced to: trademark stewardship, regulatory engagement, legal entity continuity. All protocol governance on-chain.

Year 7+: Foundation optionally sunsets into community-governed equivalent, or continues as minimal legal entity.

Section 11.3, Measurement

Progress toward decentralization is measured and reported annually. Metrics include:

  • Number of active governance participants
  • Community voting participation rate
  • Proportion of decisions made via on-chain vote
  • Foundation treasury share (decreasing as community-controlled treasuries grow)

Section 11.4, Non-Reversal

The Foundation may not reverse decentralization steps. Once authority is transferred to the community, it is permanent.

Article XII, Amendment

Section 12.1, Amendment Process

This charter may be amended by:

  • Board supermajority (6-of-7)
  • Plus 30-day public comment period
  • Plus ratification by community vote (mechanism defined once community governance is active)

Amendments must be published 60 days before effect.

Section 12.2, Non-Amendable Provisions

Certain provisions cannot be amended except by dissolution and re-chartering:

  • Foundation non-profit status
  • Commercial separation (Article V.1)
  • Progressive decentralization commitment (Article XI.1)
  • Constitutional protocol limits (Article VIII.3)

Section 12.3, Dissolution

The Foundation may be dissolved by:

  • Board unanimous vote
  • Plus community supermajority ratification
  • Plus orderly wind-down plan

Upon dissolution, remaining treasury funds transfer to successor governance structure or, if none exists, to public goods funding recipients approved by community vote.

Article XIII, Execution

This charter enters effect upon:

  • Incorporation of the Foundation in chosen jurisdiction
  • Appointment of initial directors
  • Filing of this charter with incorporation documents

Initial directors (to be confirmed):

  • Director 1: [Founder name, founding technical lead]
  • Director 2: [Legal / governance expert]
  • Director 3: [African fintech or regulatory expert]

Initial jurisdiction: Mauritius (purpose foundation under Foundations Act 2012; formation in progress; counsel-verified fitness 2026; Liechtenstein and Cayman documented as fallback alternatives subject to counsel's negative finding on Mauritius) Initial filing date: [TBD] Initial Executive Director: [Founder, serving until Board selects independent successor]

Appendices

Appendix A, Bylaws

Specific operational procedures (meeting cadence, voting procedures, officer duties, committee structures). To be drafted by counsel.

Appendix B, Code of Ethics

Detailed ethical guidelines for directors, officers, and staff.

Appendix C, Conflict of Interest Form

Annual disclosure template.

Appendix D, Whistleblower Policy

Anonymous reporting procedure and protection.

Appendix E, Multi-Sig Signer Agreement

Specific duties and responsibilities for Treasury multi-sig signers.

Appendix F, Advisory Council Charters

Per-council purpose, membership, and authority.

Document status: v0.1, working draft. For legal counsel review before filing.

Next step: engagement with specialized crypto-foundation legal counsel (initial candidates: Cooley, Reed Smith, Harneys, to be evaluated).