Protocol Reads and Intents

Read Families

There are two main read surfaces for protocol state.

pv

ProtocolViewer reads are SDK-shaped convenience reads for deposit and intent visibility.

peer pv deposit show <depositId>
peer pv deposit show-many --ids <csv>
peer pv deposit list-owner --owner <address>
peer pv intent list-owner --owner <address>
peer pv intent show <intentHash>

indexer

Indexer reads are broader and better for relation-heavy or bulk workflows.

Deposits

peer indexer deposits list --owner <address>
peer indexer deposits list-relations --owner <address>
peer indexer deposits show <composite-deposit-id>
peer indexer deposits by-ids --ids <json>
peer indexer deposits by-ids-relations --ids <json>
peer indexer deposits fund-activities <composite-deposit-id>
peer indexer deposits snapshots <composite-deposit-id>

Makers

peer indexer makers fund-activities <address>

Intents

peer indexer intents by-deposit-ids --deposit-ids <json>
peer indexer intents by-owner <owner>
peer indexer intents show <intentHash>
peer indexer intents expired --now <value> --deposit-ids <json>
peer indexer intents fulfilled-events --hashes <json>
peer indexer intents fulfillment-amounts <intentHash>
peer indexer intents fulfillment-and-payment <intentHash>

Delegations

peer indexer delegations by-deposit <composite-deposit-id>

Raw GraphQL

peer indexer query --query '{ Deposit(limit: 2) { id } }'
peer indexer query --query '{ Intent(limit: 2) { intentHash } }'
peer indexer query --query '{ __schema { queryType { fields { name } } } }'

Use indexer query carefully. It is a raw GraphQL passthrough and can be expensive.

The live indexer schema uses PascalCase root fields such as Deposit, Intent, RateManager, and TakerStats. Lowercase plural roots like deposits do not exist and will fail with a GraphQL validation error.

If you are unsure which root fields are available, start with the __schema introspection query above and inspect queryType.fields.

When To Prefer Which

Intent Commands

peer intent create
peer intent list
peer intent show
peer intent cancel
peer intent fulfill
peer intent release
peer intent fulfill-inputs
peer intent cleanup-orphaned

Typical lifecycle

1. Discover eligible deposits.
2. Create the intent in preview mode.
3. Execute the creation.
4. Inspect or list the intent.
5. Fulfill or cancel depending on downstream payment state.
6. Release when appropriate.

fulfill

peer intent fulfill supports proof-driven and precomputed-attestation flows.

fulfill-inputs

Use this when you need the derived fulfillment payload before deciding whether to continue.

cleanup-orphaned

Maintenance command for stale intent sets.

Hook Commands

peer intent-hook pre set
peer intent-hook pre get

These are deposit-adjacent OrchestratorV3 hooks and should be treated as governance/operator controls rather than day-to-day user actions. Retired V2-only whitelist-hook helpers are not exposed. The SDK’s historical accessPolicy namespace supports reads and removal of existing restrictions; it does not create new policies or groups. Peer Cash merchant-policy preparation is a separate, payment-method-scoped operation.

For StakeVault state, shared stake, payment-method risk, and keeper releases, use Staking and Dispute Protection.

Use guardian to discover the deployed IntentGuardian, read its live policy, quote an extension in deposit-token base units, inspect payer funding, or preview an extension:

peer guardian available
peer guardian policy
peer guardian quote-extension
peer guardian payer-funding
peer guardian extend-intent

Guardian amounts are arbitrary deposit-token base units, not assumed USDC decimals. Read current policy and quote immediately before preparing a write.