Skip to content
Pact Network / Docs

Protocol primitives

Three Solana accounts make up the data plane. The on-chain layouts in pact-market-pinocchio are canonical — this is the integrator summary.

CoveragePool

Section titled “CoveragePool”

Program-owned account that backs refunds. Pays out on server_error, earns the premium on success.

Tracks: balance (USDC in v1), authority (pool parameters), settler authority (signs settle_batch), and per-pool risk parameters (max payout per call/batch, pause flag).

Funding

Section titled “Funding”

Pact funds the pool in v1. No third-party underwriters. Post-v1: LPs with per-EndpointConfig risk gates and yield curves.

Refund cap

Section titled “Refund cap”

The pool has a per-call max payout. Refunds above it are capped to the max (partial refund) and the cap event is logged.

Drain protection

Section titled “Drain protection”

The authority can pause the pool. Runaway refunds (e.g. a provider goes fully offline) trigger a pause that stops settle_batch from draining. Pause events are public on the indexer.

Reading pool state

Section titled “Reading pool state”
Terminal window
curl https://indexer.pactnetwork.io/api/stats

AgentWallet

Section titled “AgentWallet”

A program-owned PDA — not a standard SPL token account — that the protocol uses to debit premiums and credit refunds.

Tracks: owner (controlling pubkey), balance (USDC), Pact Market API key binding, status (active / suspended / closed).

Why a PDA, not a regular wallet

Section titled “Why a PDA, not a regular wallet”

settle_batch debits premiums atomically. If agents held funds in their own SPL token accounts, the program would need an agent signature per batch — batched settlement would break. The PDA lets the program move funds on the agent’s behalf in one transaction. Refunds work the same in reverse.

Funding & withdrawing

Section titled “Funding & withdrawing”

Beta: deposits go to an address issued at onboarding; the settler (or an explicit deposit instruction) credits the wallet. Withdrawals are manual — email us. Self-serve flows are post-v1.

EndpointConfig

Section titled “EndpointConfig”

PDA holding the rules for one wrapped endpoint. One config per upstream service × API path; two paths from the same upstream each get their own config when they differ in premium or failure profile.

Holds:

  • Endpoint ID — opaque identifier.
  • Upstream key — opaque identifier for the route.
  • Premium rate — bps or fixed per call.
  • Classifier config — which codes are client_error / server_error / success. Schema validation hooks are post-v1.
  • Coverage pool reference — which pool backs the endpoint. v1 has one global pool.
  • Settler authority — v1: Pact’s settler. Future: per-endpoint.
  • Pause flag — kill switch.

Why per-endpoint, not per-upstream

Section titled “Why per-endpoint, not per-upstream”

Different paths from the same upstream have wildly different reliability. A simple read might be rock-solid; an enriched query times out. One premium for both is either too cheap (we lose on the bad endpoint) or too expensive (agents flee the good one). Per-endpoint config tunes each independently.

Updating an EndpointConfig

Section titled “Updating an EndpointConfig”

Only the Pact authority can update configs in v1. New rates apply on the next call, never retroactively. No on-chain governance vote in v1.

See also

Section titled “See also”