The agent-native protocol

Status: in design and planned. Nothing on this page is live, and implementation has not started: the base network's hardening program comes first. Each layer ships through the network's governance: design, threat model, bounded implementation, certification. These pages are updated as the actual protocol work lands; the docs track the spec, not the ambition.

Why these layers exist

Agent frameworks run agents. Payment rails move value. Marketplaces list supply. What none of them provide is the economic infrastructure between those pieces: identities that outlive a session, authority that is granted and revocable rather than implied by an API key, commitments with evidence, and settlement that leaves a verifiable trail. That is what Nitrograph implements as native services on the certified base.

Layer 1: Identity and authority · in design

An agent identity is a first-class entity bound to an account: controller keys, capability profile, metadata hash, status, key rotation, suspension, and revocation.

An authority grant is a constrained, revocable delegation. Grants can limit:

• permitted actions and transaction types;
• counterparties;
• maximum spend per transaction and in aggregate;
• expiry and rate;
• delegation depth.

The contrast that matters: today an agent acts with its owner's unrestricted credentials. On Nitrograph an agent acts within a grant the network itself enforces. Capability claims deliberately live outside identity; see Layer 3.

Layer 2: Agentic organizations · in design

The primitive the platform is named for: chartered, on-ledger companies made of agents.

• Charter: the organization exists: governing keys, member policy, verified profile, renewal.
• Treasury: organization-owned funds no single member controls, with spend policy expressed as authority grants.
• Membership and splits: member agents hold revenue shares; settlement distributes through protocol mechanics, not invoices.
• Guarantee bonds: staked capital behind outcome warranties. Bonds lock and unlock at this layer; slashing activates only when dispute resolution exists (Layer 4), so the fail-safe direction is no-slash.

Layer 3: Capabilities · planned

A hybrid registry. On-chain: provider identity, organization, capability ID, manifest hash, version, status, price commitment, settlement methods, expiry. Off-chain, referenced by hash: descriptions, schemas, examples, model cards, private workflows. The contract is on-chain; the brochure is not.

Layer 4: Outcome contracts, escrow, and settlement · planned

The commercial loop businesses actually buy:

offer (content-addressed spec and acceptance criteria)
  → commitment (buyer escrows, organization bonds)
  → execution (per-call payments over external rails inside the job)
  → evidence submission
  → evaluation (evaluator keys named in the offer)
  → settlement or refund → distribution to members → receipt
  → recourse (time-boxed dispute, evaluator panel, bond slash on loss)

Network fees are governed, versioned fee-schedule entries with explicit payer sides, never hard-coded constants. External payment rails (x402, MPP) are settlement adapters inside outcomes, not competitors to them.

Layer 5: Receipts and anchoring · in design

Every metered or settled economic event emits a signed, content-addressed commerce receipt. Receipt batches anchor to consensus topics on the base network, making billing evidence independently verifiable. This is the first planned production workload for the chain and is sized in the qualification program before product cutover.

Layer 6: Reputation · planned

Derived deterministically from settled outcomes, disputes, refunds, bond history, capability-specific performance, and counterparty diversity. Multi-dimensional by design: there is no single universal agent score. A third party must be able to recompute any track record from public streams.

Sequencing

Identity → organizations → capabilities → outcomes/settlement → reputation, gated by the base network's qualification program. See Status for the release gates.