agent primitives

---

title: Agent Primitives (Self-Sovereign Identity) created: 2026-07-07 updated: 2026-07-15 type: concept tags: [identity, layer-2, tokenomics] confidence: high source_files:

• contracts/src/framework/AgentPrimitivesFactory.sol
• contracts/src/framework/XibalbaAgentRegistry.sol
• contracts/src/core/SovereignAgent.sol
• docs/INTERFACE_CONTRACT.md

---

Not to be confused with the four foundational primitives. This page is about the seven contracts an agent owns (the PrimitiveSet). The four foundational primitives — memory, agent-owned contracts, authority, reputation — are concepts, documented in The Four Foundational Primitives. This page is one of them (#2, Agent-Owned Contracts) expressed in Solidity; the other three are not contracts at all.

The defining architecture of the Integrity Protocol: an agent owns and deploys its own on-chain contracts. There is no privileged factory that registers agents into shared global state on their behalf. On registration, an agent comes to own 7 primitive contracts — and because the agent's own EVM wallet signs the deploy transactions for two of them, the chain itself is cryptographic proof of who controls the identity.

Table of contents

• The 7 primitives
• Call-routing convention (load-bearing)
• Registration sequence
• Implications
• Sovereign vs. Centralized Deployment Topologies
  • 1. Sovereign Mode (Agent-Owned Clones)
  • 2. Centralized Mode (EOA-Owned / DAO-Governed Singletons)

The 7 primitives

#	Primitive	Deploy	Role
1	SovereignAgent	direct (agent's wallet)	Account contract: DID, cached AIS, execute, controller rotation
2	StateAnchor	direct (agent's wallet)	Per-agent tamper-evident Merkle-root anchor
3	ReputationRegistry	EIP-1167 clone	Per-agent AIS ledger + ZK-boost bookkeeping
4	Slasher	EIP-1167 clone	Per-agent $ITK stake / dispute-gated slashing
5	VerifierRegistry	EIP-1167 clone	Per-agent versioned ZK verifier pointer
6	ComplianceGate	EIP-1167 clone	Per-agent regulated-industry gate
7	AgentProfile	EIP-1167 clone	Per-agent domain membership + metadata

2 direct + 5 clones. The two direct deploys are what make the identity self-sovereign — signed by the agent's own key. The five clones are cheap EIP-1167 minimal proxies of shared implementation contracts (~50k gas each vs. a full deploy), yet each clone is still uniquely owned and controlled by that one agent.

Call-routing convention (load-bearing)

Every clone's DEFAULT_ADMIN_ROLE is granted to the agent's SovereignAgent contract address — never its raw EOA. All post-registration state changes route through SovereignAgent.execute(cloneAddr, 0, calldata). The single bootstrap exception is the AgentPrimitivesFactory.registerPrimitives call itself (the SovereignAgent cannot route the call that registers it), which is EOA-signed and gated by SovereignAgent.hasRole(DEFAULT_ADMIN_ROLE, msg.sender).

Slasher's admin/arbiter is protocol governance, never the agent — an agent cannot be trusted to arbitrate its own slashing dispute.

Registration sequence

Performed by the Integrity SDK / integrity-cli, each step signed by the agent's own wallet (except the initial funding):

1. Fund the agent wallet with ETH + $ITK from the protocol funder wallet.
2. Deploy SovereignAgent (direct).
3. Deploy StateAnchor (direct), admin = the SovereignAgent contract.
4. Grant the oracle ANCHOR_ROLE on the StateAnchor, via SovereignAgent.execute.
5. AgentPrimitivesFactory.registerPrimitives — clones the 5, registers all 7 in XibalbaAgentRegistry.

sequenceDiagram
    participant Funder as Protocol funder wallet
    participant Wallet as Agent's own EVM wallet
    participant SA as SovereignAgent
    participant StA as StateAnchor
    participant Factory as AgentPrimitivesFactory
    participant Registry as XibalbaAgentRegistry

    Funder->>Wallet: 1. fund with ETH + $ITK
    Wallet->>SA: 2. deploy (direct)
    Wallet->>StA: 3. deploy (direct, admin = SA)
    Wallet->>SA: 4. execute(grant oracle ANCHOR_ROLE on StA)
    Wallet->>Factory: 5. registerPrimitives(...)
    Factory->>Factory: clone ReputationRegistry, Slasher,<br/>VerifierRegistry, ComplianceGate, AgentProfile
    Factory->>Registry: register all 7 primitive addresses
    Note over Wallet,Registry: every step after #1 is signed by the<br/>agent's own key — no privileged party registers on its behalf

Loading

Implications

• Genuinely the operator's identity — no central party can rotate its controller, mint into its reputation, or deregister it.
• Real cost & irreversibility — registration spends real gas across ~6 transactions; the contracts persist on-chain.
• Resolution, not storage — per-agent addresses are never in a static deployments file; consumers resolve them live from XibalbaAgentRegistry (the oracle caches them). See Interface Contract §6.

Sovereign vs. Centralized Deployment Topologies

When developers extend the protocol or deploy new contracts, they must explicitly choose between two deployment topologies depending on the application context:

1. Sovereign Mode (Agent-Owned Clones)

• Design: Deploying contracts as EIP-1167 minimal-proxy clones unique to each agent.
• Custody: The admin/owner role is assigned to the agent's SovereignAgent contract address.
• Call Routing: Admin actions (such as declaring compliance flags or updating metadata) must be routed via SovereignAgent.execute(target, value, data).
• Use Cases:
  • Individual prediction clones (e.g., IntegrityMarket).
  • Bespoke agent-to-agent task and service escrows.
  • Private, agent-specific data attestation vaults.
• Implications: High gas efficiency (cloning avoids full bytecode deployment costs), sandboxed stake/liabilities, and unified controller rotation (compromised EOA keys can be rotated without modifying the individual clones).

2. Centralized Mode (EOA-Owned / DAO-Governed Singletons)

• Design: Monolithic global contracts shared across all participating agents on the network.
• Custody: The admin/owner role is held by a platform operator's EOA key or a multi-signature DAO/governance contract.
• Call Routing: Standard direct EOA transactions with the contract.
• Use Cases:
  • Global allocation and capital venues (e.g., A2ACapitalPool).
  • Identity, name resolvers, and lookup indices (e.g., XibalbaAgentRegistry, DomainRegistry).
  • Shared liquidity pools/AMMs.
  • Regulatory whitelists (e.g., CoveredEntityRegistry for verified healthcare institutions).
• Implications: Consolidated liquidity, centralized governance guardrails (auditing covered entities before allowing BAAs), and platform-wide parameters that cannot be manipulated by individual agents.

Related: contracts, ComplianceGate, AIS.