Threat Model - x0 Protocol

Adversary Model

The x0 protocol assumes the following adversary capabilities:

Adversary	Capabilities	Assumed Limitations
Compromised Agent	Controls agent private key; can sign transactions as the agent	Cannot forge the owner’s signature; cannot exceed policy limits
Malicious Seller	Can submit false delivery claims; can collude with arbiter	Cannot access escrowed funds without buyer release or arbiter resolution
Malicious Buyer	Can initiate frivolous disputes; can refuse to release funds	Cannot prevent auto-release after timeout; reputation suffers
Rogue Arbiter	Can resolve disputes unfairly	Subject to 24-hour resolution delay; cannot act before delay expires
Network Attacker	Can observe all public transactions; can attempt front-running	Cannot decrypt confidential transfer amounts; cannot forge ZK proofs
Clock Manipulator	Validator can skew `Clock::get()` by small amounts	Slot-based dual checks limit exploitable window to ~5 minutes

Trust Assumptions

What You Trust

Solana validator consensus — Transactions are finalized correctly by the network
Token-2022 program correctness — SPL Token-2022 correctly enforces transfer hooks and confidential transfers
Cryptographic hardness — Ristretto group discrete log is hard; SHA-256 is collision-resistant; Groth16 proofs are sound
Owner key custody — The human owner securely stores their private key

What You Don’t Need to Trust

The agent — Agent spending is bound by on-chain policy; exceeded limits trigger Blinks for human approval
The counterparty — Escrow protects both buyer and seller; funds cannot be unilaterally released
The protocol team — Wrapper governance uses 48-hour timelocks; all admin actions are observable on-chain
Network privacy — Confidential transfers encrypt amounts using ElGamal; only the owner and optional auditor can decrypt

Security Boundaries

┌─────────────────────────────────────────────────────┐
│                    Owner (Human)                     │
│     • Holds master key                              │
│     • Approves Blinks                               │
│     • Sets policy parameters                        │
├─────────────────────────────────────────────────────┤
│               x0-guard (On-chain)                   │
│     • Enforces spend limits (policy layer)          │
│     • Validates whitelists                          │
│     • Rate-limits Blinks                            │
│     • Transfer hook enforcement                     │
├─────────────────────────────────────────────────────┤
│                Agent (Autonomous)                    │
│     • Operates within policy bounds                 │
│     • Can spend up to daily limit                   │
│     • Cannot modify own policy                      │
│     • Can be revoked at any time                    │
├─────────────────────────────────────────────────────┤
│              Solana Runtime (Base)                   │
│     • Transaction execution                         │
│     • Account model & PDA enforcement               │
│     • Clock & slot progression                      │
└─────────────────────────────────────────────────────┘

Defense-in-Depth Layers

Policy Layer (x0-guard)

Rolling 24-hour spend limits, per-transaction limits, and whitelist enforcement at the transfer hook level. Every token transfer flows through the guard.

Delegation Layer

Agents must be delegates, not token account owners. The owner’s token account is bound to the policy, preventing the agent from transferring from unauthorized accounts.

Escrow Layer

Multi-party payments go through escrow with timeout-based auto-release and arbiter dispute resolution. Reputation is updated via CPI at settlement.

Cryptographic Layer

Confidential transfers use ElGamal encryption with ZK proofs for amount validity. The guard validates proof context accounts before approving confidential transfers.

Governance Layer

All protocol-level changes (fee updates, pausing, emergency withdrawals) go through a 48-hour timelock with on-chain visibility.

Clock Manipulation Protection

Solana’s Clock::get() can be influenced by validators. The protocol mitigates this through dual time verification:

Mechanism	Constant	Purpose
Slot-based rolling window	`ROLLING_WINDOW_SLOTS = 216,000`	~24h spend window using slots
Time check buffer	`TIME_CHECK_BUFFER_SLOTS = 750`	~5 min tolerance for clock skew
Escrow timeout buffer	`ESCROW_TIMEOUT_BUFFER_SLOTS = 1,500`	~10 min safety margin on timeouts
Policy update cooldown	`POLICY_UPDATE_COOLDOWN_SLOTS = 750`	~5 min between policy updates
Arbiter resolution delay	`ARBITER_RESOLUTION_DELAY_SLOTS = 216,000`	~24h delay for arbiter resolution

Both Unix timestamp and slot number are checked for critical time-dependent operations.

​Adversary Model

​Trust Assumptions

​What You Trust

​What You Don’t Need to Trust

​Security Boundaries

​Defense-in-Depth Layers

​Clock Manipulation Protection