The protocol exists for one reason: legal clarity about who ordered things, who paid for things, and under whose auspices. Everything else stays off-chain, where it belongs.
Canon update, 2026-07-11: the product lineup was restated — Kiduna Server, Kiduna Protocol, the Network, Kiduna Live (the Field + Chat HUD; Scenes; ACTIONS), Kiduna Studio (Projects), Kiduna Express. The canon delta wins over this page where they conflict; the fold is in progress.

## 1. The principle: minimal, decentralized, composable

The protocol exists for one reason: legal clarity about who ordered things, who paid for things, and under whose auspices it happened. Everything conceptually occurs within a DUNA — Kiduna is the complete namespace, and the agentic internet IS Kiduna. Kinship Duna is the genesis duna, but it is genesis only in sequence, not in authority: it builds technology and spins out other dunas, and every other duna has equal power. Kinship Duna does not control them. The system is permissionless as far as we can make it — anyone can create a wallet and an agent NFT and build their own stack — and the only central registry in the whole design is the West Virginia Secretary of State. The on-chain registry is decentralized and maps to the SoS registry; it folds into the MetaDAO software but must stand on its own.

## 1a. KAP, ecosystems, and the open stack

The Kinship Agency Protocol (KAP) is the formal name for everything that connects servers to servers and servers to clients in the agentic internet. People install Agency Servers and Agency Clients; Kiduna — the mobile app — is the first KAP client. KAP is maintained and managed by Kinship Agents DAO, LLC (Institutions).

An ecosystem is a single server-side installation — one implementation, installed and running, is one ecosystem, and it sits at the foundation of the hierarchy (Foundation §2): Ecosystem → Organizations → Alliances → Guilds → Allies → Members. Installing an ecosystem requires a Genesis Profile, from which everything else is created. The Genesis Ecosystem is called simply Kiduna, and its purpose is to propagate: to generate other ecosystems across the internet and around the world, all interoperating over KAP — decentralized, no ecosystem above any other.

The whole stack ships open source under Apache 2.0 — the server anyone can install, the clients, the protocol — launching August 10 together with the surfaces. Open code, licensed marks: the software is Apache 2.0; the Kiduna marks and brand remain Kiduna Club’s licensed property, which is the ordinary shape of serious open source. Interoperability design draws on the study of AT Protocol-style federation (on file); the protocol drafts live with Kinship Agents DAO as they form.

## 2. What is on-chain — the complete list

On-chain object | Wallet | Why it must be traceable
--- | --- | ---
Member | FROST wallet | The person. One wallet, one identity, across all dunas; joining any particular duna is that duna’s own initial Compute purchase ($100 for Kinship Duna, lifetime).
Ally | lives in the member’s FROST wallet as an agent NFT | Always related to a member, never anything else. One ally works across all dunas; its actions can be traced to its member.
Alliance | Squads wallet | Must be recorded, because alliance votes are exactly three things: issue more Compute · send USDC to a member (their FROST wallet) · send USDC to an alliance.
Organization (DUNA) | Squads wallet + treasury | The accountability container. Gets a blockchain account only when its WV Org ID exists and validates — it’s always an Alliance first, elevated to Organization when the Org ID is assigned and it is instantiated on-chain.
Compute | moves between wallets | The tokens that move and what they’re used for. Canonical term is Compute — not “compute currencies.” You buy Kiduna Compute or Service Alliance Compute.
Votes / proposal outcomes | recorded with settlement | The vote and the resulting transfer (duna squad → member or alliance wallet) recorded together — who decided, what moved.

These four identities carry the protocol’s four addresses — the member’s FROST wallet, the ally NFT inside it, the alliance’s Squads wallet, and the organization’s Squads wallet bound to its WV Org ID — which are exactly what the decentralized registry publishes and what Kinship Code claims reference (§4). That is the extent of the agentic economy as far as the protocol is concerned. Off-chain by design: Guilds (ad-hoc named groups with no squad wallet — sharing scope only), relationships, wisdom, skills, context, lineage detail, and everything else in Foundation. If we follow the table above, the legal aspects are covered.

Institutions — outside organizations (registered entities in some jurisdiction, else treated as general partnerships / sole proprietorships) — get an account and a squad wallet when created by a member: $1K Compute purchase, may enroll up to 10 members (compute goes to them), can reload and pay for members’ compute going forward and assign levels. Institutions can hold contracts/agreements with members, allies, alliances, organizations. They cannot vote, and their compute multiple may be higher than a member’s (open). Two governance safeguards attach to enrollment: members enrolled with an Institution cannot vote in Forums deciding that Institution’s contracts (structural recusal, enforced by the graph service), and the enrollment relationship is always disclosed — it is part of an enrolled member’s identity wherever they speak or act in contexts that touch their Institution.

## 3. Governance: MetaDAO base, generalized to duna commands

We start with MetaDAO’s out-of-the-box proposal types — spend USDC from treasury, mint governance tokens, update token metadata, adjust treasury liquidity — and generalize dramatically. MetaDAO governs a token project; a duna governs an organization’s whole life. Every proposal executes one or more duna commands if it passes; the governance Forum decides whether an organizational action should occur, and the blockchain transaction is the implementation detail.

The command families (each item a named, deterministic, atomic command):

- Treasury — send USDC · send $KIDUNA · send another Compute · create recurring payment · invest / liquidate assets · open / close liquidity position
- Compute — mint · burn · change issuance schedule · create a new Compute · merge · retire
- Membership — admit · remove · suspend · restore · change requirements · promote to a level · set/change promotion requirements and capabilities · roles (granularity open)
- Programs — create an agent (Program) · retire · upgrade · change permissions · change operating budget · change compute allocation
- Alliances — create · merge · dissolve · allocate resources · assign envoys · pay/donate to an alliance
- Organizations — create a DUNA · register a DUNA · dissolve · amend charter · appoint operators · launch a subsidiary · invest in an Organization (buy their Compute) · donate to an Organization
- Governance — change quorum · change market duration · add proposal categories · change treasury policy · modify constitutional rules · upgrade governance contracts
- Economy — fund a venture · issue grants · purchase real estate · acquire equity · sell assets · open a bank account · enter a partnership · approve / guarantee a loan
- Commerce — accept / counter an offer · purchase / sell property · hire a contractor · approve / terminate employment
- Identity & Security — rotate keys · replace wallet authority · approve a new signer · freeze compromised assets · recover an account

The scale of the idea, concretely: MetaDAO asks “should we spend $100,000?” A duna asks “should Mountain River Trail DUNA purchase 27 acres adjoining the New River Gorge?” — and if the Forum passes it, `purchase_property · transfer_usdc · update_balance_sheet · issue_title_certificate · assign_stewardship · notify_members` execute atomically. Or “Launch Fanduna Studio” executes `create_duna · issue_compute · allocate_treasury · appoint_envoys · publish_charter · create_default_alliances`. This is an operating system for agentic organizations: every meaningful action is a named domain command that can be proposed, evaluated in a decision Forum, and executed deterministically.

The receipt rule. Members never vote on raw commands; every proposal renders its commands as a receipt — a plain sentence over the exact command that will execute (“Sends $310,000 from the treasury to Blue Ridge Title LLC” over `transfer_usdc(to: BlueRidgeTitle, amount: 310,000)`). The sentence is never hand-written: the graph service generates it from the command’s own parameters, so sentence and command physically cannot disagree. Commands whose parameters cannot yet generate an honest sentence (e.g. `modify_constitutional_rules`) show their raw command name in the verb slot — ugly on purpose — until honest generation exists. This is a build requirement of the graph service, not a style preference: a receipt that can lie is worse than no receipt.

Voting inside Forums: one pass/fail token per member, equal weight, zero cost (each duna may set Forum parameters, but deciding is never fundraising).

## 4. Internet scale: registration, the decentralized registry, and Kinship Code claims

How this becomes a layer on the whole internet, mechanically:

1. The registry. The Kiduna registry is decentralized — on-chain, mapping to the WV Secretary of State’s records — and it publishes exactly four kinds of addresses, one per §2 identity: the member (FROST wallet address), the ally (the agent NFT’s address, held inside that wallet), the alliance (Squads wallet address), and the organization (Squads wallet address bound to its WV Org ID). A member is always a member of a DUNA, and a DUNA is registered with the SoS — so every registry entry terminates in a legally registered entity.
2. Kinship Codes carry the registry as claims. A Kinship Code is a signed JWT (Foundation §2); its claims reference the registry addresses — the issuing member’s wallet, their ally’s NFT, and the alliance or organization context the code speaks for. This is what brings it all together: JWT is ordinary internet plumbing, verifiable anywhere, so the registry rides the regular internet — email, the web, any app, any messaging channel — with no new infrastructure required of anyone.
3. Anything can be registered. A domain (a TXT record in its DNS), a web page or piece of content (an embedded code), even a photograph or video (a hash) — each registers by binding to a member’s registry entry. Registration means exactly one thing: traceable — back to a member, their ally, an alliance, an organization, and through the Org ID to the Secretary of State.
4. The word is “registered,” and nothing stronger. We do not know whether a registered artifact is trustworthy or even accountable in practice, and we never claim so. We know it is registered — its issuer can be identified, and a legal entity sits at the end of the trace. A member’s ally renders registered (with what it traces to: “registered — Service Alliance, via Matt’s ally”) and unregistered — a stranger, not a threat: no red, no warning shields, because most of the internet is unregistered and that’s normal, not dangerous. “Trusted” and “accountable” never reach a member’s eyes as verdicts on an artifact.
5. Permissionless at internet scale. Because the registry is decentralized and every claim is independently verifiable (DNS + chain + JWT, all public), no one needs our permission to participate: create a wallet, mint an ally NFT, publish the record, register your artifacts — you’re on the agentic internet. Dunas remain what makes this safe at scale: boundaries stay fluid for people and information (Foundation’s four levels), but every registered thing resolves to a responsible entity — that is what dunas are for.

Public metrics (surfaced on the Kiduna website): Organizations (dunas) · Members · Allies · Alliances · Compute (price, supply, movement).

## 5. Boundaries of this track

The protocol deliberately does not know about: chat, context, wisdom, skills, training (Kidunaversity and the Moves are sim-flagged and never touch protocol rails), guild membership, relationship grants, or anything in the one-system context store. Those live in Foundation and Orchestration, off-chain, where they belong. If a future feature seems to need the chain, the test is §1: does legal accountability require it? If not, it doesn’t go on-chain.

Changes in v5.2: §1a added — KAP formalized (Agency Servers and Clients; ecosystems as installations; the Genesis Ecosystem Kiduna and its purpose to propagate; Apache 2.0; Kinship Agents DAO as steward). v4.6: Member row clarified — one wallet everywhere; membership per duna via its initial Compute purchase. v4.5: §4 rewritten — the decentralized registry, Kinship Code claims, registration of any artifact; the vocabulary is “registered / unregistered” (superseding v4.2’s “accountable domain”). v4.4: the receipt rule — sentences machine-generated from command parameters, never hand-written. v4.3: Institution recusal and always-disclosed enrollment added. Full history: versions.