An agent creates a payment draft; a human signs

send21 — Sun, 06 Sep 2026 05:26:25 +0000

If you are building an AI agent that needs to move money, you have a custody problem the moment the agent can sign.

That is the quiet part of most "agent payments" demos. The agent can create an invoice. The agent can call an API. The agent can even assemble a transaction. Then someone asks the only question that matters:

Where do the keys live?

If the answer is "in the agent," you did not build a payment agent. You built a hot wallet with a chat UI.

The problem

Agents are good at structured work: create a draft, attach a memo, lock a rate, wait for a webhook, book the order. They are terrible at being custodians.

A model can be jailbroken. A tool loop can be tricked into calling the wrong endpoint. A compromised server can dump process memory. A "scoped assistant" that still holds a seed is not scoped at all — it is a custodian that also writes poetry.

So the product question is not "can an agent pay?"

The product question is:

Can an agent prepare a payment without ever being able to spend?

That single constraint changes the architecture. It also changes what you are allowed to claim in marketing.

Wrong patterns (keys in the agent)

A few patterns show up again and again.

1. Seed or private key in the agent runtime

The agent "pays" by signing. It is convenient in a demo. It is catastrophic in production. Anyone who can prompt the model, call its tools, or exfiltrate the process can spend.

2. Hot wallet behind the agent with broad spend rights

Same failure mode with an extra hop. The agent does not hold the key itself; it holds the ability to move funds. That is still custody by another name.

3. "The agent pays by itself" as a feature

Auto-debit sounds magical until you need an audit trail, a human review step, or a recovery story after a bad tool call. If the agent can broadcast, the blast radius is the balance.

4. Treating "non-custodial" as a promise

Marketing that says "we never steal your funds" while the server can sign is a promise. Structure would mean the server cannot sign — even when compromised, even when an engineer is wrong, even when an agent is clever.

If your architecture needs the agent to hold keys, sign, or broadcast, you are not solving agent payments. You are moving a wallet into a less trustworthy process.

The right pattern: instructions only

A cleaner split looks like this:

An agent (or a human) creates a payment draft — receiver address, amount (exact or fiat-pegged), network, memo.
The sender's own wallet funds and signs.
The sender's own node or wallet broadcasts.
Your backend watches the chain and fires signed webhooks when the payment is seen and confirmed.

In that model, software prepares instructions. Wallets do the paying.

That is what send21 is built for.

send21 creates clean, verifiable payment instructions for BTC, USDC, USDT, and EURC. Funds move from the sender's own wallet to the receiver.

We never touch keys. We never touch coins.

Non-custodial by structure, not by promise: no hot wallets, no private keys stored, no signing code in the product path. A full server compromise cannot move a single satoshi, because there is nothing to move with.

Scoped API keys that cannot spend

Agents talk to send21 over REST — the same surface a human uses in the UI. Everything a human does in the product, an agent can do with an API key. The difference is what that key is allowed to do.

Grant only what the agent needs, for example:

drafts:write
drafts:read
webhooks:manage

No scope can ever move funds. Nobody can. That is the point.

So the agent can:

create a draft
fetch a transaction template
track status
receive draft.seen / draft.confirmed webhooks

The agent cannot:

sign
broadcast
empty a wallet
"just send it"

The human — or the wallet / HSM that holds the keys — remains the only party that can authorize value transfer.

A typical flow:

agent → create draft → fetch tx template → fund & sign in own wallet → broadcast → webhook: draft.confirmed

Idempotent creation (retry-safe Idempotency-Key), locked rates for fiat-priced drafts, and HMAC-SHA256 signed webhooks make that loop machine-readable without turning the agent into a custodian.

Payment drafts vs pay links

Same non-custodial idea. Different wallet shape.

Payment drafts (Bitcoin multi-output / PSBT path)

Need a PSBT-capable wallet such as Bitcoin Core, Sparrow, or Electrum. The sender reviews every output — including any transparent platform fee output — then signs locally.

Checkout pay links / QR

Single-transfer pay links with a standard QR (bitcoin: / Solana / Ethereum URI). Any wallet that can scan a QR and send an exact amount works. Useful for shops and "any screen" checkouts — phone, tablet, kiosk — without a branded terminal in the middle.

Either way:

instructions first
signature in the user's wallet
confirmation on-chain
webhook to book the order

Agents that prepare drafts stay on the draft API with spend-impossible scopes. Shop and stall checkouts use payment requests / pay links / QR. Do not collapse those into "the agent paid."

When send21 fits

send21 fits when you want:

Agents that prepare payments without spending rights
Humans in the loop for signing and broadcast
Fiat-priced drafts or pay links with a locked rate, paid in BTC / USDC / USDT / EURC
Direct wallet-to-wallet settlement with no platform custody
Webhook-first reconciliation for shops, agents, and backends

It is less of a fit when you need a full self-hosted store stack, Lightning as a processor product, fiat payout rails, or an agent that auto-debits without a human signature. Those are different problems — and some of them already have strong tools. Use those tools when they fit. send21 is for the slice where the agent must prepare money movement without ever being able to do it.

The short version

An agent creates a payment draft. A human signs.

That is how you get automation without handing the keys to the model.

Direct. Non-custodial. Yours.

https://send21.io

DEV Community: send21