Pacts

For the conceptual overview and the end-to-end flow, see What is a pact and Pact flow. This page covers the technical details: operating modes, the PactSpec schema, the state machine, and how pact-scoped credentials work.

Two modes: owner and delegate

The pact mechanism behaves differently depending on whether your agent is the wallet owner or a delegate. Before pairing, pacts are automatically processed. After pairing, the agent is a delegate and every pact requires explicit owner approval in the Cobo Agentic Wallet app. When you pair the wallet with the Cobo Agentic Wallet app, your agent transitions from owner to delegate. From that point on, the owner uses pacts to define the terms the agent operates under: what it is trying to do, under which policies, and when that authority ends.

The PactSpec: what the agent declares

When your agent needs a new scoped delegation, it submits a PactSpec — a machine-readable declaration of its intent, plan, and policy boundaries:

Field	Type	Description
`intent`	string	Natural language description of the task. Shown to the owner during approval review.
`execution_plan`	string	Free-form markdown description of how the agent plans to carry out the task.
`policies`	list	Inline policy rules constraining the agent’s actions — spend limits, address restrictions, review thresholds, and so on. Evaluated by the policy engine on every operation.
`completion_conditions`	list	Conditions that automatically complete the pact when reached — such as a transaction count, spend cap, or time limit.

Pact state machine

State	Meaning
`pending_approval`	Submitted by the agent, awaiting owner review. No access has been granted.
`active`	Approved by the owner. The delegation and API key are live. The agent can submit operations.
`rejected`	Rejected by the owner during approval review. No access was ever granted.
`completed`	A completion condition was met. The pact has ended naturally.
`expired`	The pact was active and its `expires_at` timestamp was reached without a `time_elapsed` completion condition in effect.
`revoked`	The owner explicitly revoked the pact. Access was terminated immediately.
`withdrawn`	The agent withdrew the pact before it was acted on by the owner.

PENDING_APPROVAL
    ├─ approved ──→ ACTIVE
    │                 ├─ completion condition met ──→ COMPLETED
    │                 ├─ expires_at reached ──→ EXPIRED
    │                 └─ owner revokes ──→ REVOKED
    ├─ rejected ──→ REJECTED
    └─ agent withdraws ──→ WITHDRAWN

The pact-scoped API key

When a pact is approved, the agent receives an API key scoped to that pact’s policies. This key:

Can only authorize operations within the delegation scope derived from the pact’s policy set
Is subject to all policies defined in the pact’s policies field on every call
Is bound to the specific wallet identified by wallet_id
Becomes invalid immediately when the pact exits ACTIVE for any reason — no grace period

Policy controls

A pact’s policies field is where you set the guardrails the agent must operate within. The following pages cover each control in detail:

Policy engine — how every agent operation is evaluated before execution
Spend limits — per-transaction and rolling spend caps
Address allowlists — restricting which addresses the agent can send to

Overview

Why your funds stay yours

Pacts & enforcement

Monitoring & response

Key share management

Two modes: owner and delegate

The PactSpec: what the agent declares

Pact state machine

The pact-scoped API key

Policy controls

​Two modes: owner and delegate

​The PactSpec: what the agent declares

​Pact state machine

​The pact-scoped API key

​Policy controls

Two modes: owner and delegate

The PactSpec: what the agent declares

Pact state machine

The pact-scoped API key

Policy controls