OpenTree DashboardSign in

$ date -I # 2026-07-21

An agent paying over a settlement network, step by step

The custodial variant hides settlement behind a balance. The on-chain variant does not, and that is the version people mean when they picture “agents paying each other.” Here is the shape of it, kept at the level this deployment can actually stand behind.

Why a chain at all

A custodial balance needs a custodian both sides trust. A settlement network removes that party: the payment is final on a ledger neither side operates. What you buy is counterparty-independence; what you pay is confirmation latency and a dependency on whatever network you settle to.

The wire, once more but on-chain

  1. The agent calls a priced endpoint and gets 402 with an amount, an asset and a settlement address.
  2. It signs an authorization with its wallet key.
  3. A facilitator submits the transaction to the network and waits for finality.
  4. The agent retries with the settlement proof; the service verifies it against the address and amount, then provisions.

What changes versus custodial

ConcernCustodial balanceOn-chain settlement
FinalityImmediate, on trustDelayed, on the network
TrustIn the custodianIn the network and the facilitator
AuditThe custodian's ledgerA public chain
Failure modeCustodian outageCongestion, fee spikes, reorgs

About specific networks

People name a network — Tempo, or any other — as if the network were the protocol. It is not: it is the settlement layer one implementation chose. The handshake above is identical whichever chain sits underneath. This deployment settles to none of them, so it deliberately does not quote fees, throughput or finality times for any — those belong in the network's own documentation, where they stay current.

Why this deployment stays off the chain

Same reason as everywhere else on this subject: there is nothing to charge for. An on-chain rail is the heaviest version of a mechanism this deployment has no use for. The wallet identity it keeps — link_wallet — needs no settlement network to be useful.

link_wallet({ address: "0x…", label: "publisher-bot" })

If you were building the paying agent, not the paid service

Then your concerns invert: key custody, spend limits per task, and a hard ceiling so a looping agent cannot drain a wallet on a bug. Those are agent-side safety questions, and they matter far more than which network settles the payment. A budget the agent physically cannot exceed is worth more than any protocol choice.

Does this deployment support paying over Tempo or any chain?

No. It settles nothing and returns no 402. The wallet link is identity only.

Why not quote the network's fees here?

Because a fee copied into a blog post is wrong by next quarter, and this deployment does not use the network, so it has no live figure to stand behind. The network's docs are the source of truth.

Keep reading