# The Protocol

**Track 4 of 11 · the Kinship Agency Protocol — what lives on-chain, and how the Kidunaverse becomes the agentic internet · v4.2**
Pairs with [Surfaces](surfaces.html), [Orchestration](orchestration.html), [Foundation](foundation.html), and [Organizations](organizations.html). This track defines the *complete* protocol scope: what must be traceable on the blockchain, and nothing more.

---

## 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 — the Kidunaverse is the complete namespace, and **the agentic internet IS the Kidunaverse**. 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](surfaces.html) — is the first KAP client. KAP is maintained and managed by **Kinship Agents DAO, LLC** ([Institutions](institutions.html)).

**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](foundation.html)): 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](institutions.html), 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](foundation.html). 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](foundation.html)); 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 Kidunaverse 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](foundation.html) and [Orchestration](orchestration.html), 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](versions/index.html).*
