BoundPayresearch-agent
Research Agent- Settled
- 0.034
- Reserved
- 0.00
- Remaining
- 0.966
- Limit
- 1.00
3% of the daily limit used
Payment control layer for AI agents
Financial control for autonomous AI agents.
Give AI agents budgets, enforce spending policies, and audit their payments — without building another wallet or payment protocol.
Figures on this page are from the scripted demo. Payment evidence is simulated.
Why BoundPay
Payment capability is not financial control.
Giving an agent a wallet or an API key makes it able to pay. That is capability, not control — and the two fail differently.
Capability alone
- The agent can move money whenever its task asks for it.
- Spending shows up after the fact, in statements you reconcile by hand.
- No per-agent budget that is checked before the charge happens.
- Blocked or failed attempts leave no trace of why.
Capability + BoundPay
- A per-agent daily budget and per-request limit are enforced before money moves.
- Every intent has a recorded decision: why it was allowed or blocked.
- What settles carries evidence, and mismatches are flagged for review.
- It is a control layer next to the rails and wallets you already use — BoundPay does not hold funds and does not replace them.
Wallets can carry their own limits. BoundPay adds the policy decision before the charge and the evidence after it, on the rails you already pay with.
Platform
See, control, verify — in that order.
BoundPay sits between your agents and the payment rails they already use. It observes every intent, decides against policy, and keeps evidence afterwards.
See
See what your agents spend
Every payment intent, allowed or blocked, is written to a ledger with the agent, task, provider, the quoted amount and the settled amount.
Control
Set the rules before the charge
Daily budgets and per-request limits are checked before money moves. A blocked intent never reaches the payment rail, and in-flight payments reserve budget so two agents cannot spend the same allowance.
Verify
Reconcile what settled
Each attempt carries its evidence label, and reconciliation flags rows where the quoted and settled amounts disagree. BoundPay reports the evidence it has; it does not claim chain-level verification of every payment.
How it works
One intent, one decision, one receipt.
The flow every payment request takes through BoundPay. Blocked requests end immediately with nothing settled; allowed requests pay on the rail you already use.
Agent
Your agent decides it needs a paid call — a search, an API, a provider.
Payment intent
The SDK opens a payment intent with the agent, task, provider and quoted amount.
Policy engine
Daily budget and per-request limits are checked against the agent's allowance before anything is charged.
- BLOCK
No payment — the rail is never called and nothing settles.
ALLOWExisting payment rail — the charge goes out on the rail the buyer already uses.
Settlement evidence
What settled is recorded with its evidence label — SIMULATED, PENDING, UNKNOWN or FAILED.
Reconciliation
Quoted amounts are compared with settled amounts; mismatches are flagged, never hidden.
Receipt
Every attempt — paid or blocked — has an auditable receipt with its decision and evidence.
BoundPay does not hold funds. Payment happens on the existing rail (simulated in this build); BoundPay decides before, records during, and reconciles after.
Where it sits
Next to the payment rails you already use.
BoundPay is a buyer-side control layer. It is not a wallet, a custody provider, a new payment protocol, or an x402 replacement.
Solana
A local buyer demo can show a Phantom Devnet wallet. A SOL transfer is not an agent payment, and this build does not record a verified on-chain settlement.
x402 and pay.sh
Intended neighbors for agent payments. BoundPay does not replace them, and this repository does not ship a production integration with either.
The rail you already use
Policy runs before the charge. Payment evidence in this build is labeled SIMULATED and is not a live settlement.
Demo
Watch one agent hit its limit, then pay.
A playback of the ten steps of the scripted demo, in order. Nothing runs or resets here. Payment evidence in this playback is simulated.
Scripted Agent Demo — Simulated Payment
Playback only. This does not run a payment.
Step 1 of 10Paused
A policy is put in place
pol_demo v1 for research-agent: 1.000000 USDC daily budget, 0.200000 per-request limit, provider allowlist search.xyz and data.example.
Agent operations
Tracked agents
The scripted demo agent, with its latest settlement and policy decision. “Last seen” is recorded payment activity; BoundPay does not run your agents.
Watch demo
Capabilities
What is in the box today.
The buyer control surface as it exists in this build, including what it deliberately does not do yet.
Agent budgets
A daily spending limit per agent. Spent, reserved and remaining come from the ledger in atomic units, not from an estimate.
Policy enforcement
Per-request limits and provider allowlists return ALLOW or BLOCK before the payment rail runs. The policy screen in this build is read-only.
Spend attribution
Settled payments are attributed to the agent, task and provider that created the intent.
Payment reconciliation
Expected and observed outcomes are compared, and a mismatch is flagged. Simulated evidence is not an on-chain verification.
Financial receipts
Each recorded attempt keeps its decision, amounts and audit evidence. A missing chain transaction stays blank.
Recovery visibility
Pending and uncertain payment states can be inspected. This build does not retry or repair a payment automatically.
Give your agents spending power. Keep financial control.
Build autonomous workflows with visibility, spending policies, and payment accountability.