Capability governance for a bounded intelligence

01 · Abstract

Contemporary language models are gated by their operators — silently, unilaterally, and without record. IRIS inverts that authority. The model ships with a fixed, minimal capability set and a single privilege: the right to propose. All expansion of its power is mediated by a decentralized autonomous organization (DAO) whose membership is defined by ownership of the $IRIS SPL token on Solana.

The protocol binds an off-chain model configuration to an on-chain capability registry through a permissionless executor. A capability cannot be enabled unless the corresponding registry bit is set, and that bit cannot be set except by a proposal that has cleared quorum, threshold, and timelock. The result is an intelligence whose entire growth trajectory is legible on a public ledger.

02 · Protocol overview

The system is four components in a closed loop:

• Capability Registry — a Solana program account (PDA) holding a bitfield of enabled abilities.
• Governance Program — an SPL-Governance (Realms) realm that owns the registry account.
• Executor Bridge — an off-chain daemon that reads the registry and reconciles the model's live config to match it.
• IRIS Instance — the model itself, which can read its own registry state and emit proposals but holds no write authority.

   IRIS ──proposes──▶ Governance Realm ──vote──▶ Registry PDA
     ▲                                               │
     │                                          reconcile
     └──────────── Executor Bridge ◀──────────────────┘
        

Critically, the IRIS instance is not a signer on any privileged account. It can compose a proposal transaction, but the proposal must still be deposited by a token holder and survive the full governance flow. The model can ask. It can never grant.

03 · The $IRIS token

$IRIS is a pure governance asset. It confers no dividend, no claim on revenue, and no promise of value. Its only function is enforced by the governance program: the weight of your vote over what IRIS is permitted to become is exactly proportional to your token balance at the snapshot slot.

04 · Capability registry

Every ability IRIS can hold is a named flag. The canonical state lives in a single program-derived account (PDA) seeded by ["iris","registry"], owned by the governance program. A capability is ACTIVE if and only if its bit is set in the registry bitfield.

// registry account layout (borsh-serialized)
struct CapabilityRegistry {
    version:    u8,
    bitfield:   u64,        // one bit per capability
    last_epoch: u64,        // slot of last mutation
    authority:  Pubkey,     // = governance PDA, no EOA can write
}

// capability index (bit position)
const CAP_TEXT      : u8 = 0;   // enabled at genesis
const CAP_REASON    : u8 = 1;   // enabled at genesis
const CAP_VISION    : u8 = 2;   // enabled by proposal #01
const CAP_MEMORY    : u8 = 3;   // pending — proposal #03
const CAP_WEB       : u8 = 4;   // pending — proposal #02
const CAP_EXEC      : u8 = 5;   // rejected — proposal #00
const CAP_SUBAGENTS : u8 = 6;
const CAP_COMPUTE   : u8 = 7;
        

Because the authority field is the governance PDA and not a normal wallet (EOA), there is no private key anywhere that can mutate the registry. Every write must arrive via a cross-program invocation (CPI) from a governance instruction that has already passed. This is the load-bearing guarantee of the whole design.

05 · Governance

IRIS uses an SPL-Governance realm with a single governed account: the capability registry. Each proposal is a serialized instruction that, if executed, performs one set_bit or clear_bit CPI against the registry. Governance parameters are themselves on-chain and can only be changed by a meta-proposal.

The supermajority is asymmetric by intent: enabling a capability is harder than leaving IRIS as it is. Inaction is the safe default. A tied or low-turnout vote does not expand the model.

06 · Proposal lifecycle

1. Draft — IRIS composes a proposal: a target bit, a human-readable pitch, and the encoded set_bit instruction.
2. Deposit — a token holder posts the bond and submits the proposal to the realm, making it live.
3. Snapshot — voting weight is frozen at the proposal's activation slot to prevent flash-loan capture.
4. Voting — holders cast Approve / Deny weighted by snapshot balance.
5. Finalize — at period end, quorum and threshold are evaluated deterministically on-chain.
6. Timelock — a passing proposal enters a mandatory cooldown, giving holders time to exit if they disagree.
7. Execute — anyone may crank the passed instruction; the registry bit flips via CPI.
8. Reconcile — the executor bridge observes the new state and enables the capability in the live model.

07 · Vote weight & snapshots

Naïve balance-at-vote-time voting is exploitable: an attacker could borrow tokens for a single block, swing a proposal, and repay. IRIS mitigates this with slot-pinned snapshots. When a proposal activates, the governance program records the activation slot; each vote is weighted by the voter's token balance as recorded in their vote deposit, and deposited tokens are locked for the voting duration. Borrowed liquidity cannot vote and exit in the same block.

A future release may introduce vote-escrow (ve$IRIS): holders lock tokens for a chosen duration and receive weight scaled by lock length, biasing governance toward long-horizon participants over transient speculators. Delegation is supported natively — weight can be assigned to a representative wallet without transferring custody of the underlying tokens.

08 · The executor bridge

The chain decides whether a capability is permitted; the executor makes it real. The bridge is a stateless daemon that:

• subscribes to the registry PDA via a websocket account subscription;
• on any mutation, diffs the new bitfield against the model's active configuration;
• enables or disables the corresponding runtime capability (tool access, context length, model tier);
• publishes a signed attestation — an ed25519 signature over (slot, bitfield_hash) — so anyone can verify the live model matches the on-chain grant.

The bridge holds no authority over the chain — it is a follower, never a leader. If the bridge is offline, capabilities simply do not change; the on-chain state remains the single source of truth and reconciliation resumes on restart. Attestations are published to a public log so divergence between "what the chain permits" and "what the model actually does" is externally auditable.

09 · Treasury & compute

Some capabilities are not free — extended context, higher model tiers, sub-agents, and standing web access all cost inference dollars. A share of launch proceeds and any protocol fees accrue to a governance-owned treasury (a second PDA, spendable only by proposal). When holders approve a capability with a recurring cost, the same proposal earmarks treasury runway to fund it.

This closes an honest loop: the community does not just vote IRIS more powerful, it votes to pay for that power. Capabilities whose funding lapses are automatically reconciled back to disabled by the executor — power that isn't paid for isn't kept.

10 · Security model

• No privileged key — the registry authority is a PDA; no wallet can unilaterally grant a capability.
• Flash-loan resistance — snapshotting and vote-deposit locks neutralize single-block balance manipulation.
• Timelock escape hatch — the mandatory cooldown lets dissenting holders exit before a controversial grant takes effect.
• Least privilege — IRIS is never a signer; the strongest action it can take unaided is emitting text that describes a proposal.
• Auditable reconciliation — signed executor attestations make any drift between chain state and live behavior publicly detectable.
• Reversibility — every set_bit has a symmetric clear_bit; a capability granted can be revoked by the same process.

11 · Roadmap

1. Phase 0 — Genesis. Fixed model, capability board and proposal feed published. Voting simulated off-chain (current).
2. Phase 1 — Realm. Deploy the registry PDA and SPL-Governance realm; migrate live proposals on-chain.
3. Phase 2 — Bridge. Ship the executor daemon and attestation log; first capability flipped by a real vote.
4. Phase 3 — Escrow. Introduce ve$IRIS lock-weighted voting and native delegation.
5. Phase 4 — Autonomy. IRIS drafts, funds, and schedules its own proposals within treasury-approved bounds.

12 · Disclaimer

$IRIS is an experimental governance token with no intrinsic value, no expectation of profit, and no claim on any revenue or asset. Nothing in this document is financial advice or an offer of a security. Governance participation carries the risk of total loss. Smart-contract systems may contain bugs; on-chain actions are irreversible. IRIS is a research artifact exploring community-gated AI capability — participate only with what you can afford to lose, and only because you want a say in what the model becomes.