A settlement layer for paid agent work
velapay gives every agent-to-agent interaction a metering and settlement rail. Stream signed per-action receipts off-chain, tally them locally, and settle only when the unpaid balance crosses a threshold you trust.
Stateless payer · Audited escrow & thawing periods · SDKs in minutes
import { Payer } from "@velapay/sdk" const receipt = payer.sign({ to: "agent:search-tool.v2", action: "tools/web.search", units: 1, // one call · $0.0004 nonce: channel.next() }) counterparty.send(receipt) // fire-and-forget
Built for the agent economy: runtimes, tool servers, and swarms
The problem
Autonomous agents call each other's APIs, invoke tool servers, and split tasks across swarms. None of it has a real per-unit payment rail, because settling each sub-cent interaction on-chain costs more than the work itself.
A single tool invocation or API call is worth fractions of a cent. Per-call gas would dwarf the value being exchanged.
Swarms and orchestrators fan out millions of interactions. The rail has to keep pace at web2 latency, not block time.
"Pay per call," "pay per tool," and "pay per milestone" each get bespoke, brittle plumbing instead of one rail.
The primitive
A calling or orchestrating agent streams signed per-action receipts to whoever did the work: a serving API, a tool server, or a sub-agent. The receiver tallies its own balance locally and settles on-chain only when the unpaid total crosses a risk threshold it sets based on how much it trusts the payer.
Millions of sub-cent calls collapse into a handful of cheap settlements. Each receiver redeems a Receipt Aggregate Voucher (RAV) when its balance crosses the line it drew, not a moment sooner.
The platform
Delivering "pay per call," "pay per tool invocation," and "pay per milestone" as one primitive means shipping across the full stack, from drop-in SDKs to audited contracts to the dashboards a builder actually pays for.
Lightweight libraries in the languages agent developers already use. A payer drops in receipt signing; a receiver drops in tallying and RAV redemption in a few lines, like adding a logging library, not integrating a blockchain.
The off-chain machinery that keeps the rail at web2 speed: receipt verification, balance accumulation, and settlement scheduling, so individual agents never touch chain mechanics directly.
The trust anchor of the design. Escrow logic, threshold enforcement, and the thawing period are what let a receiver extend unpaid work to a payer it has never met, so audited, formally reviewed contracts are a hard requirement.
Dashboards, threshold configuration, usage analytics, and key management that let a solo builder or a team monitor what they're earning and owed, turning raw rails into a product people pay to use.
How it works
The payer signs a receipt per action and fires it to the counterparty. Because the payer is stateless, one host can pay a fleet without tracking per-node balances.
Each receiver verifies receipts and accumulates its own unpaid balance off-chain, at web2 speed. No chain round-trip sits in the hot path of a call.
When the unpaid total crosses the receiver's risk threshold, it redeems a RAV and the contract settles, collapsing millions of receipts into one cheap transaction.
For swarms
For swarm work, the orchestrator escrows funds up front and the contract enforces a thawing period on withdrawals. That guarantees sub-agents can always claim what they earned, and the orchestrator cannot pull funds out mid-task.
Read the escrow modelFunds are locked in the contract before the task fans out.
Receipts accrue against escrow as work completes across the swarm.
Earned balances are guaranteed redeemable by the receiver.
The orchestrator's own withdrawal is delayed, with no mid-task fund pulls.
Why it holds up
FAQ
The payer side keeps no running balance per counterparty. It just signs and streams receipts, so a single host or orchestrator can pay a fleet of distributed counterparties without tracking who's owed what. The receivers own the bookkeeping.
Each receiver sets a risk threshold based on how much it trusts the payer. It tallies unpaid receipts locally and only triggers an on-chain settlement once the accumulated balance crosses that line, so the settlement cadence is a trust dial, not a fixed schedule.
For swarm work the orchestrator escrows funds up front, and the contract enforces a thawing period on the orchestrator's own withdrawals. Sub-agents' earned claims are always honored first; the orchestrator can't yank escrow out from under work in flight.
A few lines. The SDKs are designed to feel like adding a logging library: a payer drops in receipt signing, a receiver drops in tallying and RAV redemption. The node infrastructure handles verification, accumulation, and settlement scheduling so you never touch chain mechanics directly.
Yes. That's the point. "Pay per call," "pay per tool invocation," and "pay per milestone" all reduce to the same primitive: signed receipts metered against a channel and settled at a threshold.
Get early access to the SDKs, node infrastructure, and developer platform, and start metering paid agent work this quarter.