I’ve updated the canonical version to **1.3.1** and added **Treasuries** as a first-class section. Insert this as **Section 19**, move **Compute** to Section 20, and move the **Structural Summary** to Section 21.

# Kiduna Core Taxonomy  
## Canonical Version 1.3.1

**Status:** Canonical working taxonomy  
**Version:** 1.3.1  
**Date:** July 19, 2026

---

# 19. Treasuries

A **Treasury** is the financial resource system of a Realm.

Any Realm may have a Treasury.

A Treasury may include:

- one or more wallets;
- one or more bank accounts;
- custodial accounts;
- payment accounts;
- token holdings;
- Compute reserves;
- receivables;
- financial commitments; and
- other governed stores of value.

A Treasury is not limited to crypto assets.

It may consist of:

- a wallet;
- a bank account;
- multiple wallets;
- multiple bank accounts; or
- any authorized combination of these.

A Treasury belongs to a Realm and is controlled according to that Realm’s:

- Roles;
- Permissions;
- Policies;
- governance;
- signing rules;
- spending limits;
- accounting rules; and
- applicable law.

## 19.1 Treasury Accounts

A Realm may connect multiple financial accounts to one Treasury.

Each account should declare:

- the Realm that owns or controls it;
- the account type;
- the institution or network;
- the assets it may hold;
- who may view it;
- who may propose transactions;
- who may approve transactions;
- who may execute transactions;
- applicable spending limits;
- required signatures;
- governance requirements; and
- reconciliation status.

A Treasury may aggregate information across its accounts while preserving the separate authority and operational rules of each account.

## 19.2 Bank Accounts

A Treasury may include one or more bank accounts.

Bank accounts may be used to:

- receive fiat payments;
- hold operating funds;
- pay expenses;
- compensate contributors;
- receive off-ramp proceeds;
- fund on-ramp purchases;
- maintain reserves; and
- interact with the traditional financial system.

Access to a bank account must remain subject to the Realm’s Permissions and governance.

A Connection to a bank account does not by itself grant authority to move funds.

## 19.3 Wallets

A Treasury may include one or more cryptographic wallets.

Wallets may hold:

- Compute;
- stablecoins;
- governance assets;
- market positions;
- credentials;
- tokenized assets;
- treasury reserves; and
- other supported digital property.

Kiduna recognizes three primary wallet types.

### Multisignature Wallet

A **Multisignature Wallet** requires approval from a defined number of authorized signers before a transaction may be executed.

Kiduna uses **Squads** as the standard multisignature wallet infrastructure for shared Realm Treasuries.

A Squads wallet may define:

- authorized signers;
- signing thresholds;
- spending limits;
- proposal requirements;
- transaction queues;
- execution delays;
- emergency procedures; and
- governance Connections.

### FROST Wallet

A **FROST Wallet** uses threshold cryptography to distribute control of a wallet across key shares.

The standard Kiduna member wallet uses three key shares.

No single key share is sufficient to control the wallet.

The three shares may be distributed across approved devices, services, recovery systems, or custodial arrangements according to the member’s configuration and Kiduna security policy.

FROST wallets are the standard wallets for Members.

A Member’s FROST wallet may be used for:

- holding Compute;
- payments;
- receiving distributions;
- governance participation;
- signing Kinship Codes;
- authorizing Agents;
- connecting to Alliance governance; and
- other member-authorized Actions.

### External Wallet

An **External Wallet** is a wallet created or controlled outside Kiduna and attached to a Realm through a Connection.

Any Realm may attach an External Wallet.

An External Wallet may include:

- a browser wallet;
- a hardware wallet;
- an institutional wallet;
- a custodial wallet;
- a smart-contract wallet; or
- another compatible wallet.

Attaching an External Wallet does not make it native to Kiduna and does not alter its underlying signing or custody model.

Kiduna should clearly distinguish between:

- observing the wallet;
- verifying ownership or control;
- requesting a signature;
- proposing a transaction;
- and possessing authority to execute a transaction.

## 19.4 Realm Treasury Defaults

Different Realm types have different standard Treasury configurations.

### Organization Treasuries

Every Organization has a Squads multisignature wallet as part of its Treasury.

An Organization Treasury is governed through its Forums.

Forum governance may determine:

- Treasury Policies;
- budgets;
- allocations;
- signers;
- signing thresholds;
- spending limits;
- investments;
- distributions;
- transfers;
- liquidity;
- compensation;
- protocol payments; and
- other material financial Actions.

A Forum Decision may:

- authorize a specific Treasury Action;
- create a standing Treasury Policy;
- delegate limited spending authority to a Role;
- change signer or threshold rules;
- allocate a budget;
- or trigger an executable transaction.

The Organization’s Squads wallet provides the execution and signing layer.

The Forum provides the collective authority layer.

### Alliance Treasuries

An Alliance may have a Treasury and uses a Squads multisignature wallet as its standard shared wallet.

Alliance Treasuries may use simpler governance than Organizations.

Alliance governance may include:

- direct member approval;
- signer approval;
- role-based approval;
- threshold voting;
- budget limits;
- time-limited delegations; or
- other lightweight decision processes.

An Alliance does not require the full Forum governance system used by an Organization unless the Alliance adopts it.

Alliance Squads wallets may connect to the FROST wallets of participating Members.

These Connections allow member wallets to participate in Alliance governance through mechanisms such as:

- signing;
- approvals;
- voting;
- delegation;
- membership verification;
- contribution tracking; and
- distribution.

The Alliance wallet remains distinct from the participating Member wallets.

A Connection does not merge custody, ownership, or balances.

### Member Treasuries

A Member’s personal Treasury uses a FROST wallet as its standard native wallet.

The Member is the Source of authority for the wallet.

Ki may assist the Member with:

- understanding balances;
- preparing transactions;
- managing permissions;
- reviewing risks;
- participating in governance;
- connecting external accounts; and
- maintaining records.

Ki may not execute a transaction beyond the authority explicitly granted by the Member.

### Other Realm Treasuries

Any other Realm may establish a Treasury when it needs to:

- receive funds;
- hold assets;
- pay contributors;
- make purchases;
- operate a budget;
- issue distributions;
- collect revenue; or
- participate in markets.

The Realm must define:

- who owns or controls the Treasury;
- which governance process applies;
- which wallet or account types are permitted;
- who may propose transactions;
- who may approve them;
- who may execute them; and
- how the Treasury is reconciled and audited.

## 19.5 Treasury Governance

Treasury governance determines how financial authority is exercised.

Treasury Actions may be:

### Autonomous

An authorized Agent or Role may execute the Action within a defined policy and limit.

Example: paying a recurring infrastructure bill below an approved threshold.

### Confirmed

A designated Presence must approve the Action.

Example: approving a routine contributor payment.

### Deliberate

The Action requires elevated confirmation because of its amount, risk, permanence, or sensitivity.

Example: transferring a substantial portion of a Realm’s reserves.

### Multisignature

The Action requires approval from the required number of wallet signers.

### Governed

The Action requires a valid Forum Decision, vote, policy, or other Realm governance process.

These requirements may be combined.

For example, an Organization Treasury Action may require:

1. a passed Forum Decision;
2. creation of a transaction in Squads;
3. signatures from the required signers; and
4. deterministic execution by an authorized Actor.

## 19.6 Treasury Roles and Permissions

Treasury authority may be assigned through Roles.

Possible Treasury capabilities include:

- view balances;
- view transactions;
- create budgets;
- propose payments;
- approve payments;
- sign transactions;
- execute transactions;
- connect accounts;
- reconcile records;
- manage liquidity;
- distribute Compute;
- allocate compensation;
- manage signers; and
- modify Treasury Policies.

No Role should receive unrestricted Treasury authority by default.

Treasury Permissions should specify:

- the Realm;
- the account or wallet;
- the asset;
- the Action;
- the maximum amount;
- the time period;
- the recipient or recipient class;
- the required approvals;
- the applicable Policy;
- and whether the authority may be delegated.

## 19.7 Treasury Connections

Treasuries may connect to:

- Member FROST wallets;
- Realm Squads wallets;
- External Wallets;
- bank accounts;
- payment processors;
- exchanges;
- on-ramps;
- off-ramps;
- accounting systems;
- tax systems;
- governance systems; and
- liquidity venues.

Connections allow systems to exchange information or initiate authorized Actions.

A Connection does not override:

- custody;
- ownership;
- privacy;
- signing requirements;
- governance;
- or Permissions.

## 19.8 Treasury Records

Every Treasury Action should produce an auditable record.

Treasury records should include:

- the Realm;
- the account or wallet;
- the proposing Presence or Agent;
- the Source of authority;
- the applicable Role;
- the governing Policy or Decision;
- required approvals;
- signatures;
- asset;
- amount;
- recipient;
- purpose;
- timestamp;
- execution status;
- transaction identifier;
- and reconciliation state.

Records may be private, but their existence and use remain subject to the Realm’s governance and applicable reporting requirements.

## 19.9 Treasury Invariants

The following principles apply across Kiduna:

1. **Any Realm may have a Treasury.**

2. **A Treasury may contain wallets, bank accounts, or both.**

3. **Organizations use Squads wallets and govern their Treasuries through Forums.**

4. **Alliances use Squads wallets with simpler Realm-defined governance.**

5. **Members use FROST wallets with three key shares.**

6. **Any Realm may attach an External Wallet.**

7. **Alliance Squads wallets may connect to Member FROST wallets for governance.**

8. **Connections do not merge ownership or custody.**

9. **Administrative Roles do not override Treasury Permissions.**

10. **No Wizard, Mage, Agent, or system operator has universal access to Treasury assets.**

11. **Every Treasury Action must have a valid Source of authority.**

12. **Every executed Treasury Action must be deterministic and auditable.**

---

# 20. Compute

**Compute** is the digital capacity used to purchase intelligence, Agent operations, and related services within a Realm.

An Organization or other authorized Realm may issue or designate its own Compute.

Compute may be held, received, distributed, or managed through a Realm’s Treasury.

## 20.1 Realm-Defined Compute Rules

A Realm may establish:

- membership purchase requirements;
- holding requirements;
- activation thresholds;
- minimum and maximum issuance conditions;
- pricing;
- Agency Premium;
- Role-specific rates;
- lineage distributions;
- Treasury distributions;
- contributor allocations;
- transferability;
- redemption;
- conversion; and
- market access.

## 20.2 Raw Compute Cost

**Raw Compute Cost** is the underlying cost of:

- models;
- infrastructure;
- tools;
- storage;
- networking; and
- execution

required to perform work.

## 20.3 Agency Premium

The **Agency Premium** is the amount charged above Raw Compute Cost for access to a Realm’s:

- agency;
- coordination;
- intellectual property;
- infrastructure;
- community;
- context;
- relationships; and
- services.

The Agency Premium may be expressed as:

- a multiple;
- a fixed addition;
- a percentage; or
- a Role- or service-specific schedule.

## 20.4 Protocol Licensing

A Realm may pay Kiduna Club:

- a defined portion of the Agency Premium for use of the Kiduna stack; and
- a defined portion of Compute purchases for protocol and infrastructure licensing.

These are separate economic rules.

## 20.5 Compute Purchase Distribution

When Compute is purchased, the received payment may be distributed through the applicable Treasury among:

- lineage recipients;
- Kiduna Club licensing;
- the Realm Treasury;
- liquidity;
- contributors;
- sponsors; and
- other Policy-defined recipients.

A protocol default may be provided, but a Realm may change it where permitted by its governing rules.

## 20.6 Lineage

**Lineage** records the invitation or relationship path through which a Presence joined a particular Realm.

Lineage distributions may reward multiple generations of that path.

A default distribution may be:

- Generation 1: 20%;
- Generation 2: 5%;
- Generation 3: 3%; and
- Generation 4: 2%.

Lineage applies to the relevant Realm and does not automatically create a universal relationship across the Kidunaverse.

## 20.7 Treasury Allocations

A Realm may establish recurring or discretionary Treasury allocations for contributors such as:

- Catalysts;
- Luminaries;
- Builders;
- Creators;
- Operators; and
- other recognized Roles.

Roles may carry:

- fixed compensation;
- recurring compensation;
- bounties;
- revenue shares;
- Compute distributions;
- market-based payments; or
- other Realm-defined rewards.

---

# 21. Structural Summary

The canonical taxonomy answers these foundational questions.

## Where does participation happen?

In the **Field**, accessed through **Surfaces**.

## What can be entered and explored?

**Realms**.

## Who appears and participates?

**Presences**.

## Who provides personal agency?

**Ki**, the Ally.

## What other software entities act?

**Actors**.

## What do Agents know and possess?

**Wisdom, Stance, Abilities, Automations, and Connections**.

## What appears visually?

**Elements**, organized within the Field, Realms, and Panels.

## What creates a bounded, independently designed experience?

**Scenes**, entered through **Portals**.

## What persists?

**Artifacts**.

## What happens?

**Actions**.

## How does a Presence participate in a Realm?

Through **Roles**.

## Why may an Action occur?

Because of valid **Authority, Permissions, Role, goal, context, visibility, and Policy**.

## How is information protected?

Through **Privacy and Visibility**.

## How is reliability assessed?

Through contextual **Trust**.

## How are collective decisions made?

Through **Governance**.

## Where is financial value held and governed?

In **Treasuries**, which may contain wallets, bank accounts, or both.

## How are goods, services, access, and participation made available?

Through **Offerings**.

## How are intelligence, agency, contribution, and value paid for?

Through **Compute, Treasuries, Roles, and Realm-defined economic policies**.

This is now **Kiduna Core Taxonomy v1.3.1**. The most important conceptual distinction is that a **Treasury is the Realm-level financial system**, while wallets and bank accounts are accounts contained within or connected to that Treasury.