DEV Community: send21

Discuss: should a human sign when your agent hits an x402 paywall?

send21 — Wed, 28 Oct 2026 09:40:07 +0000

A question for anyone building agents that call paid APIs over x402.

Your agent sends a request, the server answers 402 Payment Required, and then: the agent has no funded wallet, or the price is above its budget. What should happen?

One option we're considering for send21 (crypto pay links and API for people and AI agents): turn the 402 payment requirements into a page where a person reviews the amount and signs in their own wallet. The agent retries the request with that signature, and the seller's own facilitator settles it. send21 would stay non-custodial and never broadcast anything.

To be clear, this isn't built, and send21 doesn't support x402 today. We wrote up how x402, AP2 and send21 differ at https://send21.io/x402-ap2-agent-payments if you want the background. It would be the x402 version of our over-budget handoff example: the repo at https://github.com/send21io/send21-over-budget-handoff does the same thing with a pay link and a signed webhook.

Would you use this? Concrete answers help most:

Which chain and token do you pay in?
Which API are you paying for?
How often does your agent hit a 402 it shouldn't pay on its own?
Would signing those approvals feel risky, or just annoying?

"We'd rather just fund a wallet" is a useful answer too.

Let your agent pay a local helper, while you still sign

send21 — Sun, 25 Oct 2026 19:33:36 +0000

Here's a small, concrete case: your own agent arranges a physical task with someone nearby you already know and trust. A photo check of a delivery at the front door, for example, for 3 EUR. When the helper reports it done, somebody has to pay them.

You probably don't want the agent to hold funds for that. You also don't want to type an address and an amount by hand every time. This post shows a middle path, in an open-source example: agent-hires-local-helper.

The split is simple: the agent prepares the payment, you sign it in your own wallet. send21 (crypto pay links and API for people and AI agents) sits in between. It creates the payment draft; it never holds keys, never signs and never broadcasts. The agent's key can create and read drafts, but no key can move funds.

The flow

Task card. The task, where, the agreed amount, and the helper's receiving address in groups of four. The helper gave you that address once; it lives in helper.json. The agent reads it from there and can't change it.
Task done → two MCP checks and one draft. The agent checks the address rules over the send21 MCP server (https://send21.io/mcp) and creates a payment draft with the REST API, with the same scoped key.
Owner review. You see the amount, a QR code, the full address, whether it matches the saved one, and a plain list of what the agent did. One button: Open the payment to sign in your wallet.
Paid. After a signed draft.confirmed webhook (or the draft status turning Confirmed).

Why a draft, not a pay link

send21 has two building blocks. A pay link asks to get paid, and send21 says pay links need the owner's own approved receiving addresses, while drafts may pay any approved address. The helper's address isn't yours, so paying it is a draft. That also works on default accounts, where the receiving-address policy is ApprovedOnly, once you've approved the helper's address.

The calls

From lib/agent.js, shortened:

const status = await mcp.callTool("get_account_status");
// -> receivingAddressPolicy

const book = await mcp.callTool("list_address_book");
const entry = book.find((e) => e.address === helper.address && e.network === helper.network);
const approved = Boolean(entry?.verifiedAt);

if (status.receivingAddressPolicy === "ApprovedOnly" && !approved) {
  // The agent can't approve addresses. It stops, tells the owner, creates nothing.
  return { stopped: true, reason: "The helper's address is not approved in send21 yet..." };
}

const draft = await api.post("/drafts", {
  receiverAddress: helper.address,          // from helper.json, never from a message
  network: helper.network,                  // "Solana"
  currency: helper.currency,                // "Usdt"
  paymentMethod: "MultiOutput",
  singleOutput: true,                       // one QR payment from any wallet
  fiatCurrency: task.fiatCurrency,          // "EUR"
  fiatAmount: task.fiatAmount,              // 3
  memo: `${task.title}: done (task ${task.id})`,
}, { idempotencyKey: `helper-task-${task.id}` });

The draft goes through POST /drafts rather than the MCP create_draft tool because singleOutput: true makes it one QR payment any wallet can pay, with the send21 fee billed to the account. create_draft puts the fee in a separate output, which suits batching wallets.

The Idempotency-Key from the task id is the part we'd copy into any agent. Agents retry. A webhook fires twice, a message gets processed again, someone presses "done" twice. With the same key, send21 returns the original draft instead of creating a second one, and the same key with a different receiver, amount, currency or network is refused. npm run agent shows it: it asks twice and gets the same draft id back. Drafts have no orderId or reuseOpenForOrder; those exist only for pay links, so the task id lives in the key and the memo.

A fiat price is locked for 15 minutes. If the lock runs out while the draft is still within its life, the agent re-quotes it (POST /drafts/{id}/requote) instead of creating another one.

Asset and network are checked before anything is sent: USDT only on Solana or Ethereum, USDC for example on Solana, Polygon or Arbitrum. The example run used USDT on Solana.

After creating the draft, the example compares the draft's receiverAddress with the saved one, every character. Only an entry you verified in your send21 address book is shown as pre-approved; otherwise the UI says Matches the helper address you saved.

The webhook check

The task is marked paid on the server, from a signed webhook, never from the browser. First the signature (lib/webhook.js):

// X-Send21-Signature-V2: t=<unix>,v1=<hex HMAC-SHA256 of "<t>.<delivery id>.<raw body>">
if (!t || !v1 || Math.abs(now - Number(t)) > 300) return false;   // older than 5 minutes: refuse
const expected = crypto.createHmac("sha256", secret)
  .update(`${t}.${deliveryId ?? ""}.`).update(rawBody).digest("hex");
return crypto.timingSafeEqual(Buffer.from(v1, "hex"), Buffer.from(expected, "hex"));

Then the content (server.js). A valid signature isn't enough; the payment has to be this task's payment:

if (handledDeliveries.has(delivery)) return res.end("already handled"); // retries reuse X-Send21-Delivery
const expected = event === "draft.confirmed" && data?.draftId === draft.id
  && String(data.sentCurrency).toLowerCase() === String(draft.currency).toLowerCase()
  && data.network === draft.network
  && Number(data.amountSats) === Number(draft.amountBaseUnits);  // billed amount in base units

orderId is only set for pay-link payments, so a draft is matched by its draftId. An unsigned delivery gets a 401. To see the Paid screen without paying, npm run local-paid signs a test delivery with a local secret, posts it twice (the second is ignored as already handled), and the UI labels it Local test webhook so it's never mistaken for a real payment.

Use it from your own agent

Any MCP client can make the same checks:

{ "mcpServers": { "send21": { "url": "https://send21.io/mcp", "headers": { "Authorization": "Bearer s21_YOUR_KEY" } } } }

with a rule like: When a helper task is reported done, create a payment draft to the helper's saved address with the task id in the Idempotency-Key (create_draft with idempotencyKey, or POST /drafts), then give me the draft to sign. Never sign or send payments.

The limits, honestly

Nobody checks the work. "Done" means someone pressed Task done. send21 doesn't hold the money in between and doesn't judge the result. Use this for helpers you know and trust.
It doesn't find helpers. You bring the person and their address.
Address rules on new accounts. New accounts use the receiving-address policy ApprovedOnly: API keys can only use addresses the owner approved in the send21 app with a passkey or an authenticator code, and the agent stops if the helper's isn't one. Approve the helper's address first. Our test run used an account with inline addresses allowed, so the UI said Matches the helper address you saved.
It's a demo. One task in memory, no database. The webhook needs a public HTTPS endpoint.
Live networks. Account keys use live networks; a draft moves no money until someone signs it. Test with a small amount to your own address and cancel the draft (npm run agent -- --cancel <id>). The testnet demo runs in the browser with no account.
Check the address in your wallet. The review screen helps, but the wallet's confirm screen is the last word. A phished or forged link is still a risk.

Run it

git clone https://github.com/send21io/send21-examples
cd send21-examples/examples/agent-hires-local-helper
npm install
npm test                 # no key, no network
cp .env.example .env     # scoped key from https://send21.io/api-keys
npm start                # http://localhost:3022
npm run agent            # the agent flow in the terminal

If you've built something similar, we'd like to hear how you decide when "done" is done. Questions: info@send21.io

Stop copying payee addresses from wallet history: a small pattern for repeat crypto payments

send21 — Sun, 25 Oct 2026 19:18:16 +0000

If you pay the same person in USDC or USDT every month, there is a good chance you do it like this: open the wallet, find last month's transfer, copy the address, paste, send.

That one step, copying the address from history, is exactly what address poisoning is built for.

The threat in one paragraph

An attacker watches the chain for your transfers. Right after you pay someone, they send you a tiny or zero-value transfer from an address that starts and ends with the same characters as your real payee. Now your history has two entries that look the same at a glance. Next month you copy the wrong one.

This is not rare. The USENIX Security '25 paper "Blockchain Address Poisoning" from Carnegie Mellon counted 270 million attack attempts aimed at 17 million victims on Ethereum and BSC alone, between 1 July 2022 and 30 June 2024. 6,633 of those incidents caused at least $83.8M in losses.

A test transfer doesn't protect you either. On 19 December 2025 (UTC), someone sent 49,999,950 USDT on Ethereum to a lookalike address about 26 minutes after a 50 USDT test transfer to the real one (CoinDesk). The test worked. The address for the big payment came from history.

A manual routine anyone can use (no tools needed)

Get the address once, from outside the chain. An invoice, a contract or a message from the payee. Not from a block explorer and not from your history.
Save it as a named payee record. Your wallet's address book, a password manager entry, a text file you control. Write down the network and the asset next to it (USDT on Solana and USDT on Ethereum are different addresses).
Every payment starts from that record. Never from "recent", never from the history list, never from a search box that shows past addresses.
Compare the whole address, in groups of four. Lookalikes are generated to match the first and last 4 to 6 characters. Read it group by group against the record.
Check again on the wallet's confirm screen. That is the last place the address can still change, for example through a swapped clipboard or a forged link.
If the payee says their address changed, confirm through a second channel before you update the record.

Most of the protection comes from steps 1 to 3: one source of truth, and history is never used as an address book.

The same pattern in code

We wrote an open-source example of this routine with send21 (crypto pay links and API for people and AI agents): repeat-payer-verified-address. It is a small Node.js app. It's one way to automate the routine above, not the only one.

One stored record. The payee lives in payee.json (label, network, asset, address, monthly amount). The app refuses to start until you replace the placeholder, and the error tells you to copy the address "from the invoice or contract they sent you, never from wallet history". It also refuses an asset on a network where send21 does not offer it (USDT, for example, only runs on Solana and Ethereum).

If your send21 key can read the address book, the app also checks whether the address is an entry you verified in the send21 app (with a passkey or an authenticator code; no API key can verify one). Only then does the UI say approved payee. Otherwise it says saved payee and that the record is your local file.

The draft is built from that record, never from a paste:

// lib/monthly.js
const idempotencyKey = `monthly-${payee.id}-${month}`;
let draft = await api.post("/drafts", draftBody(payee, month), { idempotencyKey });

The Idempotency-Key is per payee and month, so a double click or a retry returns the same draft instead of a second one.

The full address is checked in three places. After creating the draft, the app compares the saved address character by character with receiverAddress in the draft, with the output in the wallet instructions (GET /drafts/{id}/tx-template) and with the address inside the QR link (Solana Pay or EIP-681 URI):

// lib/address.js: exact, case-sensitive, no first-4/last-4 shortcut
export function compareAddresses(approved, actual) {
  const a = String(approved ?? ""), b = String(actual ?? "");
  const match = a.length > 0 && a === b;
  // ...also reports where the first difference is
}

The test suite includes a lookalike that shares the first and last four characters and fails at position 4. If any check fails, the UI shows Stop. The address does not match and no wallet button.

Monthly without retyping. npm run monthly -- --schedule creates a recurring template (POST /recurring-templates, interval: "Monthly") from the same record, so send21 creates each month's draft from the stored address. The payer still signs every one.

Price lock. A price in EUR (or any of 161 currencies) is locked for 15 minutes. If this month's draft is still valid but the lock ran out, the app re-quotes the same draft (POST /drafts/{id}/requote) instead of making a twin.

Your wallet signs. The page ends at Waiting for your signature with a QR code and an Open in your wallet button. send21 prepares the payment; it never holds keys, never signs and never broadcasts. A signed draft.confirmed webhook (checked with X-Send21-Signature-V2) moves it to Paid.

What this does not do

It removes one risky step: copying an address from history. It does not stop scams in general. A phished or forged pay link, a changed invoice or a tampered payee record is still a risk, and a wrong address saved in step 1 stays wrong every month. So keep step 5: compare the full address on your wallet's confirm screen before you sign.

Try it

git clone https://github.com/send21io/send21-examples
cd send21-examples/examples/repeat-payer-verified-address
npm install && npm test     # tests need no key and no network
cp .env.example .env        # add a scoped key from https://send21.io/api-keys
npm start                   # http://localhost:3021

Account keys use live networks, and a draft moves no money until someone signs it, so test with a small draft to your own address and cancel it afterwards (npm run monthly -- --cancel <id>). If you just want to look around, the testnet demo runs in the browser with no account.

How do you keep payee addresses today? We're curious what routines people use. Questions about the example: info@send21.io

x402 vs AP2 vs send21: three ways AI agents handle payments

send21 — Thu, 22 Oct 2026 20:24:56 +0000

Disclosure: this is written by the team behind send21, one of the three approaches below. We have tried to describe the other two from their own documentation, and we link to it so you can check.

"How does an AI agent pay?" has at least three different answers right now, and they are not really competitors. They answer different questions: who holds the money, who authorizes the payment, and what kind of thing is being paid for.

x402: the agent pays for a request

x402 is an open standard for internet-native payments built on the HTTP status code 402 Payment Required. It was started by Coinbase, and the x402 site now announces an x402 Foundation at the Linux Foundation. The reference code is on GitHub.

The flow, from the spec's README:

A client (for example an agent) requests a resource.
The server answers 402 Payment Required with a PAYMENT-REQUIRED header listing what it accepts.
The client picks an option, builds a signed payment payload and repeats the request with a PAYMENT-SIGNATURE header.
The server verifies the payment, locally or through a facilitator's /verify endpoint, serves the response, and settles the payment on-chain, itself or through the facilitator's /settle endpoint.

On the server it can be one piece of middleware per route. x402 describes itself as network, token and currency agnostic: there are SDKs for EVM chains, Solana and several others, stablecoins are the main use, and fiat networks may be added. There are no protocol fees beyond network fees. Its principles say a facilitator or server must never be able to move funds other than as the client intended.

Where it fits: pay-per-call APIs, paywalled content and data, machine-to-machine payments where a human signing each request would make no sense. The trade-off is that the client needs a key that can sign payments, which in practice means a funded wallet, and spending limits are something the agent's owner sets up around it.

AP2: the agent buys with your mandate

AP2, the Agent Payments Protocol, is an open protocol published by Google under the Apache 2.0 license (GitHub). It is available as an extension for the Agent2Agent (A2A) protocol and the Universal Commerce Protocol, and the AP2 site says standardization continues in FIDO Alliance working groups.

AP2 starts from a different problem. Payment systems assume a person clicks "buy". When an agent does it, the merchant and the payment side need to know that the user really authorized this purchase, and who is accountable if it goes wrong.

Its answer is verifiable digital credentials called mandates:

A Checkout Mandate captures the items and purchase details agreed between the agent and the merchant, and is shared with the merchant.
A Payment Mandate authorizes a payment against a specific payment instrument, and is shared with the credential provider, the networks and the merchant's payment side.

Each comes in an open form (the user's constraints, such as a budget, for an agent acting on its own) and a closed form (authorization for one finalized checkout and amount). Chained together they give an audit trail for both human-present and human-not-present purchases.

The first version supports "pull" payment methods like credit and debit cards. E-wallets, real-time bank transfers and digital currencies are on its roadmap. The AP2 samples already include a human-not-present flow that pays with x402, which shows the two can work together.

Where it fits: agents shopping at merchants on a user's behalf, inside existing card networks, where verifiable intent and accountability matter more than speed.

send21: the agent prepares, someone else signs

send21 (our project) takes a third route: the agent never holds money and cannot pay. It creates a crypto pay link or payment draft through the MCP server or the REST API, using a scoped key that cannot move funds. The payment is then signed in a wallet the agent does not control: the payer's own wallet, or the operator's.

The agent can track the payment and react to an HMAC-signed webhook when it confirms. send21 retries failed deliveries, so the same delivery can arrive more than once, and the receiver should key on the delivery id. On new accounts, API keys can only use receiving addresses the owner approved in the app with a passkey or an authenticator code. An agent can propose an address; it cannot approve one.

Payers can use BTC (on-chain or Lightning), USDC, USDT (on Solana and Ethereum), EURC, SOL or ETH. send21 never holds keys or funds, and it does not implement x402 or AP2 today.

Where it fits: agents that bill people (invoices, checkouts, pay links), agents that hit their budget and hand a purchase to a human with a link to pay, and teams that do not want an agent holding a funded wallet. It is a poor fit for paying per API call: nobody wants to sign a transaction for every request.

Side by side

	x402	AP2	send21
Question it answers	How does a client pay for this HTTP request?	How does a merchant know the user authorized this purchase?	How does an agent get a person paid, or ask a person to pay, without holding money?
Who pays	The client, from its own wallet	The user, through their payment credentials and mandate	The payer or operator, signing in their own wallet
What the agent holds	A key that can sign payments	Mandates, not the money	A scoped API key that cannot move funds
Money	Stablecoins first, many chains	Cards first	BTC, Lightning, USDC, USDT, EURC, SOL, ETH
Human approval	Optional, set up by the owner	Through the signed mandate	A person or the operator's wallet signs each payment

How to choose

Start from the question you actually have:

Is your agent the customer of an API or a data source? x402 is built for that. Put a budget around the wallet it uses.
Is your agent shopping at merchants for a user, with cards? AP2 is designed for that, with mandates that make the user's intent checkable.
Is your agent the one asking for money, or does it need a person to decide? That is where send21 fits: the agent prepares the payment, and the money moves only when someone signs.

Many agents will end up using more than one. A research agent might pay for data with x402, book a flight under an AP2 mandate, and send its customer an invoice through send21.

The protocols are moving quickly, so check the primary sources before you build: x402.org, ap2-protocol.org, and for send21 the docs and the testnet demo.

Our own summary page with the same comparison: x402, AP2 and send21: AI agent payments explained. Corrections are welcome at info@send21.io.

How to send a crypto invoice and get paid straight to your wallet

send21 — Thu, 22 Oct 2026 20:24:07 +0000

Disclosure: this is written by the team behind send21.

Most crypto invoices are a PDF with a wallet address pasted at the bottom. Then the questions start. Which rate turns your EUR 1,200 into USDC? Which network should the client use? Did the money arrive? And what if an exchange withdrawal lands a few euros short?

This guide walks through sending a crypto invoice as a pay link instead, with send21, so the client pays from their own wallet straight into yours. send21 is non-custodial software: it prepares the payment instructions and watches the chain, but it never holds keys or funds. The short version is on the crypto invoice generator page.

What you need before you start

A wallet you control for each network you want to accept. For example a Solana wallet for USDC or EURC on Solana, an Ethereum wallet for Ethereum or Base, a Bitcoin wallet for on-chain BTC, or a Lightning wallet with a Lightning address (it looks like name@wallet.com).
A send21 account. Sign-up is free with an email address. There is no subscription and no KYC step, because send21 never holds your money. The rules that apply to your own business still apply to you.

Step 1: Price the invoice in your own currency

Open Get paid in the app and enter the amount in the currency your books are kept in: EUR, USD, SEK or any of 161 fiat currencies. You can also ask for an exact crypto amount instead.

Add a message the client will see, such as "Invoice 2026-041, logo design", and your invoice number as the order id. The order id comes back with every notification.

Step 2: Choose what you accept

Pick the currencies and networks you are happy to receive, each with your own receiving address:

Currency	Networks
BTC	Bitcoin on-chain, or Lightning to your Lightning address
USDC	Solana, Ethereum, Base, Arbitrum, Polygon (native USDC only on Arbitrum and Polygon)
USDT	Solana and Ethereum only
EURC	Solana, Ethereum, Base
SOL	Solana
ETH	Ethereum, Base, Arbitrum

Offer only what you want to hold. If your clients are in the EU, USDC and EURC are usually the easiest choice, since EU exchanges delisted USDT.

Step 3: Send the link

Send the pay link by email or chat, or show its QR code. When the client opens it, they see:

your amount in your currency, your message, and the currencies you accept;
after picking one, a single QR code with the exact crypto amount, which network to use, and how long the rate is locked.

The rate locks for 15 minutes when the client picks a currency, and the rate, its source and the time are recorded. So a price in EUR stays a price in EUR, and you can see later exactly how it was converted.

The client pays from any wallet or exchange that can send to an address. They sign in their own wallet, and the money goes from their wallet to yours. Nothing passes through send21.

Ask the client to compare the address in their wallet with the one on the pay page. send21 highlights its start and end, the parts a look-alike address from clipboard malware would have to copy.

Step 4: Get told when it is paid

send21 watches the chain and tells you by email, in the app and, if you set one up, by a signed webhook to your own system. You hear when the payment is seen and again when it is confirmed. Before marking a payment confirmed, send21 looks the transaction up once more at a second source.

Each pay link is for one payment.

Step 5: Handle a payment that arrives a little short

Exchanges often deduct their withdrawal fee from the amount, so EUR 1,200 arrives as EUR 1,198.50.

When a transfer within 10% of the billed amount reaches your address, send21 flags it instead of ignoring it. You get an alert, and you decide: accept it as paid, or decline it with a reason. The client sees a notice not to pay again. If you have not decided 2 hours before the payment expires, you get a reminder. You can also choose to accept small short payments automatically (up to 10%, and you absorb the difference). Overpayments always wait for you.

Two honest limits: a transfer more than 10% off is not flagged, and the money is already in your wallet either way, so any refund is a new payment you make yourself.

Step 6: Keep the records

Each paid invoice keeps the amount, the rate with its source and time, the transaction and your order id, and you can download a PDF of the payment. send21 does not convert crypto to fiat or pay out to a bank, so taxes and bookkeeping in your country stay with you.

What it costs

Creating and sending invoices is free. When one is paid, send21 bills a fee to your account: 0.49% on the smallest payments, falling by tier to 0.01% above $100,000, never more than $100 per payment. The fee is never taken out of the payment, so you receive the full amount. Fees add up on your account, and you settle them in one payment at $10 or after 30 days. The full schedule is on the pricing page.

A few things to know first

Crypto payments cannot be reversed. A refund is a new payment from your wallet.
Lightning confirms automatically only when your wallet provider supports it (LUD-21). Otherwise the payment is confirmed with the proof of payment that the paying wallet shows.
ETH seen only as a balance increase (where no block explorer is available) waits for you to confirm it.

Try it without real money

To see the flow from both sides first, the testnet demo runs a real payment with test coins, with no account and no email.

From your own software, the same pay link is one call to POST /api/v1/payment-requests (see the quickstart).

Start here: send21 crypto invoice generator. Questions or corrections are welcome at info@send21.io.

Let an AI agent create crypto pay links over MCP (without handing it your keys)

send21 — Thu, 22 Oct 2026 18:42:08 +0000

Agents are good at preparing payments and bad places to keep money. This tutorial shows a split that works: your AI agent creates a crypto pay link over the Model Context Protocol (MCP), the payer pays from their own wallet straight to your address, and your server learns about it through a signed webhook.

We use send21: Crypto pay links and API for people and AI agents. send21 is non-custodial payment software. It prepares payment instructions and watches the chain. It never holds private keys or funds, never signs and never broadcasts. No API key can move funds.

What you will build:

Connect an MCP client to the send21 MCP server.
Ask the agent what is still missing (get_account_status).
Approve a receiving address yourself, in the send21 app.
Let the agent create a pay link (create_payment_request).
Let the agent check it (get_payment_request).
Optional: verify webhooks on your own server.

Full docs: send21.io/docs/mcp.

1. Connect your MCP client

The server lives at https://send21.io/mcp (Streamable HTTP, stateless). There are two ways in.

Option A: sign in, no key to copy. Clients that support MCP sign-in (OAuth) can add https://send21.io/mcp/oauth as a remote server with no headers. The client opens send21 in your browser, you sign in, see what the app asks for, and approve. In Claude Code:

claude mcp add --transport http send21 https://send21.io/mcp/oauth
# then run /mcp in Claude Code and choose send21 to sign in

A signed-in connection only ever uses receiving addresses you approved, whatever your account setting. It shows up under API keys as a connected app, and Disconnect ends it at once.

Option B: a scoped API key. Sign in, open API keys and create a key with only the scopes the job needs. For this tutorial that is drafts:read and drafts:write, plus addressbook:write if the agent should propose addresses and webhooks:manage for step 6. Keys look like s21_... and are shown once.

Cursor (.cursor/mcp.json) and other clients that use mcpServers:

{
  "mcpServers": {
    "send21": {
      "url": "https://send21.io/mcp",
      "headers": { "Authorization": "Bearer s21_YOUR_KEY" }
    }
  }
}

VS Code (.vscode/mcp.json):

{
  "servers": {
    "send21": {
      "type": "http",
      "url": "https://send21.io/mcp",
      "headers": { "Authorization": "Bearer s21_YOUR_KEY" }
    }
  }
}

Claude Code with a key:

claude mcp add --transport http send21 https://send21.io/mcp \
  --header "Authorization: Bearer s21_YOUR_KEY"

Listing the tools and reading the fee schedule work without a key. Every other tool needs one (or a sign-in).

2. Ask the agent what is missing

Start every session with get_account_status. It reports whether your email is confirmed, your receiving-address policy, how many addresses are approved or waiting, unsettled fees, the key's scopes, and the next steps.

Here is a real response from our test account (email redacted):

{
  "email": "<redacted>",
  "emailVerified": true,
  "receivingAddressPolicy": "InlineAllowed",
  "approvedReceivingAddresses": 0,
  "approvedPayingAddresses": 0,
  "proposedAddresses": 0,
  "ownerCanApprove": false,
  "keyScopes": ["drafts:read", "drafts:write", "webhooks:manage"],
  "outstandingFeesUsd": 0,
  "feesBlockCreation": false,
  "nextSteps": ["Ready: create pay links."]
}

Our test account is an older one with the InlineAllowed policy. New accounts start with ApprovedOnly, and older accounts can turn it on in Settings. On ApprovedOnly, get_account_status is how the agent learns what is still missing before it can create a pay link. We recommend ApprovedOnly for any account an agent touches.

3. You approve the receiving address, not the agent

This is the step that keeps a prompt-injected agent or a leaked key from sending your customers' money somewhere else.

On ApprovedOnly, an API key can only use addresses the owner approved. The agent can propose one:

{
  "name": "propose_receiving_address",
  "arguments": {
    "label": "My Phantom wallet",
    "address": "YourSolanaAddress",
    "network": "Solana"
  }
}

The address is saved unapproved, and you get an email. That email has no approve link. You sign in to send21, compare the address character by character, and approve it with a passkey or an authenticator code. An emailed code is never enough, because an agent that reads your inbox could use it. No API key and no scope can approve an address.

If the agent names any other address in a pay link, the call fails with 422 address_not_approved and nothing is created. A good agent then calls get_account_status, tells you, and waits.

4. Create a pay link

create_payment_request makes a pay link priced in fiat (any of 161 currencies). You list the currencies you accept, each with your own receiving address. The payer opens the link, picks one, the rate locks for 15 minutes, and they send a single transfer from their own wallet straight to your address.

The call we ran against the live server (addresses redacted):

{
  "name": "create_payment_request",
  "arguments": {
    "fiatCurrency": "EUR",
    "fiatAmount": 1,
    "orderId": "TPL-MCP-DEVTO-20261022-1",
    "memo": "MCP tutorial test run",
    "expiryHours": 1,
    "idempotencyKey": "tpl-mcp-devto-20261022-1",
    "reuseOpenForOrder": true,
    "options": [
      { "currency": "Usdc", "network": "Solana", "address": "<your-solana-address>" },
      { "currency": "Usdt", "network": "Solana", "address": "<your-solana-address>" }
    ]
  }
}

Two arguments are worth having from day one:

idempotencyKey: a retry with the same key and the same parameters returns the original pay link. The same key with another amount, currency or address is refused (422), and nothing is created.
orderId with reuseOpenForOrder: true: if the agent retries with a new key, it still gets the open link for that order instead of a second one.

Other useful options: declineNote (what happens if the payer does not pay, shown on the pay page), shortfallAbsorbUpToPercent (accept small short payments automatically, 0 to 10; overpayments always wait for a person), and expiryHours (default 24).

Want a different asset mix? USDT works on Solana and Ethereum. On Base you can take USDC, EURC or ETH. Bitcoin works on-chain or over Lightning ("method": "Lightning" with your Lightning address).

The real response, with ids, token and address redacted:

{
  "id": "<uuid>",
  "shareToken": "<token>",
  "payPath": "/pay/<token>",
  "orderId": "TPL-MCP-DEVTO-20261022-1",
  "fiatCurrency": "EUR",
  "fiatAmount": 1,
  "memo": "MCP tutorial test run",
  "status": "Open",
  "expiresAt": "2026-10-22T19:38:58.466Z",
  "createdAt": "2026-10-22T18:38:58.466Z",
  "options": [
    { "currency": "Usdc", "network": "Solana", "address": "<solana-address>", "method": "MultiOutput" },
    { "currency": "Usdt", "network": "Solana", "address": "<solana-address>", "method": "MultiOutput" }
  ],
  "activeDraftId": null,
  "draftStatus": null,
  "fee": null,
  "amountMismatch": null,
  "declineNote": null,
  "shortfallPolicy": null,
  "changeSignals": [],
  "changeNotes": [],
  "optionChangeSignals": [
    { "currency": "Usdc", "network": "Solana", "method": "MultiOutput", "signals": [], "notes": [] },
    { "currency": "Usdt", "network": "Solana", "method": "MultiOutput", "signals": [], "notes": [] }
  ]
}

The link to share is https://send21.io plus payPath. The payer scans one standard QR code (Solana Pay here) with any wallet. Hand the link to a human. The agent does not pay it.

changeSignals is empty here. It fills with new_address, new_asset or unusual_amount when something differs from your paid payments, and the pay page shows the payer the same lines.

5. Check the status

get_payment_request takes the paymentRequestId and returns the same shape. Right after creation ours was identical to the response above: status: "Open", draftStatus: null.

How to read it:

Pay link state	Meaning
`Open`, `draftStatus: null`	Nobody picked a currency yet
`Open`, `draftStatus: AwaitingPayment`	The payer picked a currency, the price is locked
`Open`, `draftStatus: Seen`	Payment seen, not confirmed yet
`Completed`	Confirmed
`Expired` / `Cancelled`	Unpaid / cancelled

A transfer within 10% of the billed amount never confirms on its own. It waits for you to accept or decline it. That decision is yours, not the agent's.

Polling is fine for a chat session. For anything that ships goods, use webhooks.

6. Optional: verify webhooks on your server

Register an endpoint with POST /api/v1/webhooks (scope webhooks:manage). The signing secret is shown once. Each delivery carries X-Send21-Delivery (retries reuse it) and X-Send21-Signature-V2: t=<unix>,v1=<hex>, an HMAC-SHA256 of <t>.<delivery id>.<raw body>.

Your receiver has three jobs:

Verify the V2 signature over the raw bytes, in constant time.
Reject deliveries older than 5 minutes.
Dedupe by delivery id. send21 retries failed deliveries (up to 8 attempts), so the same delivery can arrive more than once. Use its delivery id to ignore repeats.

A minimal Node receiver, no dependencies. The signature lines come from the send21 docs. The HTTP wrapper and the in-memory dedupe are ours, and we tested them locally with self-signed sample deliveries, not live send21 traffic:

import http from 'node:http';
import crypto from 'node:crypto';

const secret = process.env.SEND21_WEBHOOK_SECRET; // shown once when you register the endpoint
const handled = new Set(); // demo only: use a database table with a unique key in production

http.createServer((req, res) => {
  if (req.method !== 'POST' || req.url !== '/webhooks/send21') return res.writeHead(404).end();
  const chunks = [];
  req.on('data', (c) => chunks.push(c));
  req.on('end', () => {
    const rawBody = Buffer.concat(chunks); // raw bytes, before any JSON parsing

    // X-Send21-Signature-V2: t=<unix seconds>,v1=<hex HMAC-SHA256 of "<t>.<delivery id>.<raw body>">
    const sig = String(req.headers['x-send21-signature-v2'] ?? '');
    const t = /(?:^|,)t=(\d+)/.exec(sig)?.[1];
    const v1 = /(?:^|,)v1=([0-9a-f]{64})/.exec(sig)?.[1];
    const deliveryId = String(req.headers['x-send21-delivery'] ?? '');
    const fresh = t !== undefined && Math.abs(Date.now() / 1000 - Number(t)) <= 300;
    const expected = crypto.createHmac('sha256', secret)
      .update(t + '.' + deliveryId + '.').update(rawBody).digest('hex');
    const ok = fresh && v1 !== undefined &&
      crypto.timingSafeEqual(Buffer.from(v1, 'hex'), Buffer.from(expected, 'hex'));
    if (!ok) return res.writeHead(401).end();

    // Retries reuse X-Send21-Delivery, so ignore ids you've already handled.
    if (handled.has(deliveryId)) return res.writeHead(200).end();
    handled.add(deliveryId);

    const { event, data } = JSON.parse(rawBody);
    if (event === 'draft.confirmed') {
      // Check orderId, amount and asset against your own order before you ship anything.
      console.log('paid', data.orderId, data.sentAmount, data.sentCurrency, data.network);
    }
    res.writeHead(200).end();
  });
}).listen(3000);

Any 2xx counts as delivered. Endpoints must be public HTTPS. Reconcile on orderId and the exact amount, not on arrival time, and never mark an order paid from the browser.

Rules worth pasting into your agent

The send21 docs ship a rules block for AGENTS.md, CLAUDE.md or Cursor rules. The short version:

Create pay links with create_payment_request, with orderId and reuseOpenForOrder: true.
Only use approved addresses. On 422 address_not_approved, propose the address and tell the owner.
Call get_account_status when something is blocked.
Amount mismatches are the owner's to decide.
Never hold keys, sign or send payments. The payer signs in their own wallet.

Next steps

Runnable code: send21-examples has an MCP pay-link example, webhook receivers, and LangChain, Vercel AI SDK and Shopify samples.
No account yet? The testnet demo runs the whole flow on test networks, with no sign-up.
MCP reference (tools, resources, prompts): send21.io/docs/mcp.

Questions: info@send21.io.

Written by send21.

Address poisoning: the copy-paste habit that cost one trader 49,999,950 USDT

send21 — Thu, 22 Oct 2026 18:11:06 +0000

By send21 (send21.io)

Many crypto theft stories involve a hacked exchange or a leaked seed phrase. Address poisoning needs neither. No key is stolen and no code is exploited. The victim signs a perfectly valid transaction from their own wallet, to an address they chose themselves. It just happens to be the wrong address.

This post explains how the attack works, what the research says about its scale, and the habits that make it much harder to fall for.

How the attack works

On chains like Ethereum and BNB Smart Chain, an address is a 40-character hexadecimal string. Nobody memorizes those. So, as a peer-reviewed USENIX Security 2025 paper titled "Blockchain Address Poisoning" puts it, users often select addresses from their recent transaction history. That habit is the whole attack surface.

The attack runs in three steps:

Watch. The attacker monitors the chain for transfers. When you send tokens to an address, they note who you paid.
Generate a lookalike. They brute-force a new address whose first and last characters match the one you paid. Wallets often shorten addresses to something like 0xAbC12…9f3E, so a match on the visible ends is enough to look right.
Poison your history. They make that lookalike address show up in your transaction list, ideally near the top.

Then they wait. The next time you go to pay the same counterparty and grab the address from your history, there's a chance you grab theirs.

The paper describes three ways attackers plant the lookalike:

Tiny transfers: a small amount of the same token, sent from the lookalike address to you.
Zero-value transfers: a transfer of zero tokens that appears to go from you to the lookalike address. Popular token implementations let anyone trigger a zero-value transferFrom with an arbitrary sender, so your history can show an outgoing "payment" you never made. The researchers call these potentially even more dangerous than tiny transfers, because it looks as if you've paid that address before.
Counterfeit token transfers: a fake token with a name close to a real one, "sent" from you to the lookalike.

Because blockchain transactions are irreversible, a single mistake is usually final.

How big is it?

The USENIX paper measured address poisoning on Ethereum and BNB Smart Chain between 1 July 2022 and 30 June 2024. On those two chains alone, the researchers found:

over 270 million attack attempts,
targeting over 17 million victims,
6,633 successful incidents, with at least $83.8 million lost.

The authors call their loss figure a conservative lower bound: they only tracked a handful of major stablecoins. They also note the attack can affect any blockchain whose addresses are hard for people to compare at a glance, not only hexadecimal ones.

It hasn't slowed down. Blockaid reported in March 2026 that it had flagged over 65.4 million address poisoning transactions on-chain since January 2025.

The December 2025 case: the test transfer didn't help

On 20 December 2025, a trader lost 49,999,950 USDT, nearly $50 million, to address poisoning. According to The Block, the trader had withdrawn the funds from Binance and was moving them to their own wallet. They did what security guides tell you to do: they sent a small test transaction first, 50 USDT, to the right address.

That test is what the attacker was waiting for. An automated script generated a lookalike address that matched the intended one in its first five and last four characters. The differences were only in the middle, which many wallet interfaces hide behind an ellipsis. The attacker then sent small transactions from the lookalike to the victim's wallet. When the victim copied an address from their history for the full transfer, they likely picked the attacker's.

Etherscan data cited by The Block puts the test transaction at 3:06 UTC and the big transfer about 26 minutes later, at 3:32 UTC. Within 30 minutes the attacker had swapped the USDT to DAI (which can't be frozen the way USDT can), then to ETH, and moved around 16,680 ETH into Tornado Cash.

Blockaid describes this as test-transaction interception: bots watch for small "test" transfers, plant a lookalike right after, and wait for the big one. In Blockaid's words, the technique "specifically targets security-conscious users."

The lesson isn't that test transfers are useless. A test checks that the address you typed works. It does nothing to check that the address you use next is the same one.

Habits that actually help

None of these are new, but the December case shows why they matter.

1. Never copy a payee address from your transaction history. This is the attack vector. Get the address from a source you trust: your saved contacts, the recipient's own page or invoice, or direct confirmation from them.

2. Use an address book or saved contacts. Save and label addresses you pay often, once, after checking them properly. Then always pay from the saved entry. The USENIX researchers list building an allow-list of trusted addresses as a user-level mitigation, and Blockaid recommends the same.

3. Verify the full address, not just the ends. Attackers generate addresses that match exactly the characters people check. Compare the middle too, character by character, ideally on your hardware wallet's screen before you sign.

4. Ignore zero-value and dust transfers. An unexpected tiny transfer from an address that looks like one of your contacts is a warning sign, not a payment. A zero-value "transfer" from you that you don't remember making is almost certainly poisoning. Don't interact with it, and don't use it as a source of addresses.

5. Treat a test transfer as one step, not as proof. After a test, confirm with the recipient through a separate channel that it arrived. Then send the full amount to the same verified address, from your address book, not from history. Blockaid notes that a test alone is not sufficient without independent verification.

Where pay links fit in

We build send21: crypto pay links and an API for people and AI agents. It's relevant here because of where the address comes from, not because it makes the attack go away.

Address poisoning works when the payer copies the payee's address from their own transaction history. With a pay link, the payer doesn't do that. The receiver sends a link, and the payer gets the address and amount from it as a standard QR code or payment URI (BIP-21, Solana Pay, EIP-681 or a Lightning invoice). They then sign and send from their own wallet, straight to the receiver's own address. send21 is non-custodial: it never holds private keys or funds, and never signs or broadcasts a transaction.

On the receiving side, the owner decides which addresses get used. An AI agent working through the send21 API or MCP server can only propose a receiving address. The owner signs in to the app, compares it character by character, and approves it with a passkey or an authenticator code. On new accounts, an API key that names any other address gets 422 address_not_approved and nothing is created.

The limits matter just as much:

A fake link sent by someone pretending to be the receiver still points to the wrong address. Only open links that came from someone you know, through a channel you trust.
If the receiver's account is compromised, the attacker could get an address of their own approved.
Your wallet history can still be poisoned. A pay link only changes where the address comes from for that payment.

So the habit from the top of this post still applies: before you sign, check the full address in your wallet.

Summary

Address poisoning doesn't break cryptography. It works on a habit: copying addresses from history and checking only the first and last few characters. Break that habit. Pay from saved contacts or from the recipient's own link, read the whole address, ignore dust and zero-value transfers, and don't let a successful test make you relax for the next transfer.

Questions or corrections: info@send21.io.

We built a white-label P2P money app on send21: here's how to rebrand it with one file

send21 — Fri, 16 Oct 2026 09:31:54 +0000

Disclosure: this is written by the team behind send21 (send21.io), and dewby is built on send21.

dewby is a small P2P money app for paying friends back. It's a testnet demo: test money on test networks, nothing in it has value. It's a white-label version of our open-source example app, send21 pair: the same payments engine with its own name, logo, colors and UI. And the whole brand lives in one file.

What it does

Friends connect once by scanning a code. Then there are three things to do:

Pay back. Ask a friend for 120 in your own currency, or pay them. They get a request with the amount, a note and an Open wallet button.
Split. Pick two or more friends, enter the total, and everyone gets their share as a separate request.
QR anyone can pay. Show a QR for an amount. Whoever scans it pays from their own wallet, with no app and no account.

Each payment goes straight to the receiver's own wallet address. The payer signs in their own wallet. send21 never holds keys or funds, never signs and never broadcasts, and neither does dewby.

You can try it alone: tap Try it alone with a demo friend, send the prefilled request, tap Let Demo friend pay, and watch it go from waiting to paid. On desktop, the app sits in a phone frame next to a QR code you can scan to open it on your phone.

How it works

Every request is a send21 draft: payment instructions for one amount, asset and network, addressed to the receiver. Four details carry most of the safety:

The receiver address is fixed on the server. The client sends who to ask and how much. The server creates the draft with the receiver's saved address, and fails if the draft comes back with a different one. A tampered client can't change where the money goes.
V2 signed webhooks. send21 reports status (draft.seen, draft.confirmed, …) by webhook. dewby verifies the x-send21-signature-v2 header: an HMAC over the timestamp, the delivery id and the raw body. It turns off the legacy body-only signature and refuses deliveries more than five minutes old, so an old delivery can't be replayed.
Its own dedupe, on top of send21's. dewby stores each delivery id in the same transaction as the status change, so a repeated delivery is a no-op and can't confirm twice.
A check against the stored request. On draft.confirmed, dewby compares the asset, network and amount with what it stored when it created the request. If anything differs, the request goes to review instead of Paid.

The app is a vanilla PWA: no framework, no build step, a service worker and Web Push.

Three modes

mock: no key and no network. It runs on a local server, or fully in the browser like the GitHub Pages demo, where links and QR codes carry the data between phones.
demo: real testnet drafts from send21's public demo API, with status checked by polling.
api: your own scoped send21 key and webhooks. send21 accounts use live networks, so this mode refuses to start unless you set APP_ALLOW_LIVE=1.

Rebrand it with one file

Everything brand-specific is in web/brand.js:

window.BRAND = {
  name: "dewby",                 // UI name and wallet memo prefix
  tagline: "Pay friends back. Fresh.",
  storagePrefix: "dewby",        // keeps two apps on one origin apart
  siteUrl: "https://…/dewby/",   // share card URLs
  poweredBy: true,               // a small "powered by send21" line in Settings
  light: { bg, surface, ink, mint, lime, sea, pop, link, ok, warn, bad },
  dark: { … },
  forcedDark: { … },             // palette for browsers that force dark mode
};

theme.js turns the palette into CSS variables before first paint, so the stylesheet never hard-codes a brand color. The server reads the same file, so the memo in the payer's wallet shows your app's name. To rebrand:

Edit web/brand.js and swap web/icons/mark.svg.
Run npm run brand. It rewrites the manifest, title, theme color and share-card meta, and redraws the icons from your mark.
Run npm test. It checks every text color for WCAG AA contrast, that the manifest and HTML match the brand file, the share card size, and that no stray send21 branding is left in the UI.

The lesson: keep the brand as data, and let tests check what's easy to forget when you rebrand, like contrast, storage keys and leftover strings.

Honest limits

Testnet only. The demo uses Solana Devnet and Base Sepolia with test tokens. Nothing has value.
A prototype. It's an example to read and fork, not a product.
One extra tap on phones. A notification can open a web page but not a wallet, so the payer taps Open wallet to sign.

Try the demo friend, then open brand.js and change the colors. Questions or ideas: info@send21.io.

Let your agent get paid without holding keys

send21 — Thu, 15 Oct 2026 19:42:47 +0000

Sooner or later an agent you build has to deal with money. A booking agent hits a deposit. A freelancing assistant needs to send an invoice. A support bot has to collect a fee before it ships a replacement part.

The quick answer is to hand the agent a wallet. Fund it, put the private key in an environment variable, let the model call a send tool. That works in a demo. In production it means a single prompt injection, a confused tool call or a leaked log line can empty the wallet, and nothing in the stack can tell a legitimate payment from a manipulated one, because the agent is the one signing.

There is a simpler split that removes most of that risk: the agent prepares the payment, and a human signs it in their own wallet. This article shows how to do that with send21, a non-custodial service that prepares payment instructions, over its MCP server.

The split: preparing is not paying

A payment has two halves:

Preparing: who gets paid, how much, in which asset and network, with what reference, and at which exchange rate if the price is in euros or dollars.
Authorising: signing a transaction with a private key and broadcasting it.

Agents are good at the first half. It is structured data, it benefits from context, and mistakes are cheap if someone checks before signing. The second half is where the risk lives, and it is exactly the part an agent does not need.

send21 only does the first half. It never holds keys or funds, never signs and never broadcasts. Funds go straight from the payer's wallet to the receiver's wallet. Since there is no signing code on the server, an API key you give an agent cannot move money, however it is misused. The worst an abused key can do is create payment instructions that a human then has to approve in their own wallet.

What the agent can do

The send21 MCP server runs at https://send21.io/mcp over Streamable HTTP and is listed in the official MCP Registry as io.github.send21io/mcp. It exposes 11 tools, including:

create_payment_request: create a pay link where you are the receiver. Price it in a fiat currency, list the assets you accept with your own receiving addresses, and get back a link.
get_payment_request: read its status (Open, Completed, Cancelled, Expired).
create_draft and get_transaction_template: the other direction, where the owner pays someone. The template gives the wallet everything it needs to fund, review and sign.
get_rate and get_fee_schedule: rates with their source, and the public fee table.

Listing the tools and reading the fee schedule work without a key. Everything else needs a scoped API key that the account owner creates. For an agent that only issues pay links, drafts:write plus drafts:read is enough.

Supported today: BTC on-chain and over Lightning (paid to the receiver's own Lightning address), USDC on Solana, Ethereum, Base, Arbitrum and Polygon, USDT on Solana and Ethereum, EURC on Solana, Ethereum and Base, plus native SOL and ETH. Prices can be set in 161 fiat currencies.

Connect it in one block

In Cursor, .cursor/mcp.json from the send21-examples repo looks like this:

{
  "mcpServers": {
    "send21": {
      "url": "https://send21.io/mcp",
      "headers": {
        "Authorization": "Bearer ${env:SEND21_API_KEY}"
      }
    }
  }
}

Claude Desktop needs a stdio bridge, so the example uses mcp-remote:

{
  "mcpServers": {
    "send21": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://send21.io/mcp",
               "--header", "Authorization:${SEND21_AUTH_HEADER}"],
      "env": { "SEND21_AUTH_HEADER": "Bearer s21_your_key_here" }
    }
  }
}

Then ask: "Create a pay link for 40 EUR for invoice 1042, payable in USDC on Solana to my address." The model fills in create_payment_request and hands you a link.

Doing it from code

Inside your own agent you can call the same tool with the MCP TypeScript SDK. This is trimmed from examples/mcp-payment-request in the examples repo:

import { randomUUID } from "node:crypto";
import { Client } from "@modelcontextprotocol/sdk/client/index.js";
import { StreamableHTTPClientTransport } from "@modelcontextprotocol/sdk/client/streamableHttp.js";

const client = new Client({ name: "my-agent", version: "1.0.0" });
const transport = new StreamableHTTPClientTransport(new URL("https://send21.io/mcp"), {
  requestInit: { headers: { Authorization: `Bearer ${process.env.SEND21_API_KEY}` } },
});
await client.connect(transport);

const result = await client.callTool({
  name: "create_payment_request",
  arguments: {
    fiatCurrency: "EUR",
    fiatAmount: 40,
    options: [
      { currency: "Usdc", network: "Solana", address: process.env.MY_SOLANA_ADDRESS },
      { currency: "Btc", network: "Mainnet", address: "name@wallet.com", method: "Lightning" },
    ],
    orderId: "inv-1042",
    memo: "Logo design, round 2",
    idempotencyKey: randomUUID(),
  },
});

The response carries an id, a payPath and an expiry. Join payPath with https://send21.io and send it to the payer. They open the page, pick a currency (the rate locks for 15 minutes at that point), scan one QR code with any wallet and sign.

The example also has a dry-run mode that needs no key. It connects, fetches the live tool list and checks your arguments against the published input schema without creating anything:

npm run dry-run -- 25 EUR --option Usdc:Solana:<your-solana-address>

That is a cheap way to catch a wrong enum value before an agent does.

Three details that matter for agents

Fix the addresses in code, not in the prompt. The receiving address is the one field an attacker would want to change. If your app passes its own addresses into options and ignores whatever the model suggests, a prompt injection can at worst change the amount or memo on a link that a human still has to pay.

Retries are safe. Agents retry. Every create call can carry an idempotency key: the same key with the same parameters returns the original request, and the same key with a different amount, currency or address is refused with a 422 and creates nothing. If your agent might retry with a new key, set reuseOpenForOrder: true with an orderId, and you get the existing open link back instead of a second one for the same order.

Say what happens if nobody pays. When an agent hits a purchase over its budget and hands it to a human, the pay link can carry a declineNote, shown on the pay page as "If you don't pay: the booking is released at 18:00." The human gets the context the agent had.

Knowing when it was paid

You do not need to poll. send21 sends HMAC-signed webhooks with your orderId, for example draft.confirmed when the payment has its confirmations. Verify the X-Send21-Signature-V2 header: t=<timestamp>,v1=<hex>, an HMAC-SHA256 of "<timestamp>.<delivery id>.<raw body>" keyed with your signing secret. Because the time and the delivery id are signed too, refuse anything older than 5 minutes and a copied delivery cannot be replayed. The webhook receiver in the examples repo does this in constant time:

import { createHmac, timingSafeEqual } from "node:crypto";

export function verifySignatureV2(rawBody, header, deliveryId, secret) {
  if (!secret || typeof header !== "string" || typeof deliveryId !== "string" || !deliveryId) return false;
  const parts = Object.fromEntries(header.split(",").map((p) => [p.slice(0, p.indexOf("=")).trim(), p.slice(p.indexOf("=") + 1).trim()]));
  if (!/^\d+$/.test(parts.t ?? "") || !parts.v1) return false;
  if (Math.abs(Date.now() / 1000 - Number(parts.t)) > 300) return false; // older than 5 minutes
  const signed = Buffer.concat([Buffer.from(`${parts.t}.${deliveryId}.`), rawBody]);
  const expected = Buffer.from(createHmac("sha256", secret).update(signed).digest("hex"));
  const received = Buffer.from(parts.v1);
  return received.length === expected.length && timingSafeEqual(received, expected);
}

The original X-Send21-Signature (HMAC of the raw body only, no timestamp) is still sent so existing integrations keep working; use it only as a fallback when no V2 header is present. The webhook guide at send21.io/docs/webhooks describes both. Deliveries are retried with the same X-Send21-Delivery id, so skip one you have already handled.

Real payments are messy, and the events reflect that. A transfer from an exchange often arrives a little short because the exchange took its withdrawal fee. When a transfer within 10% of the billed amount reaches the address, send21 does not mark it paid; it sends draft.amount_mismatch and the receiver accepts or declines it, with a reason. Your agent can surface that to a human instead of guessing.

What a human sees before signing

The person who signs is the safety net, so the pay page tries to make the unusual visible. It shows a short "what changed" line only when something is out of pattern, such as a first payment to an address or an amount about three times the usual. Agents get the same signals through get_payment_request as changeSignals and changeNotes, so an agent can stop and ask before forwarding a link that looks off. Addresses are shown with the characters a look-alike address would have to copy highlighted, so the payer can compare them with their wallet.

What this is not

To be precise about the boundaries:

It is not an agent wallet. An agent cannot sign or pay on its own through send21.
There is no escrow and no "pay now, release later". Money moves once, wallet to wallet.
There are no payouts to bank accounts and no conversion to fiat.

If you need fully autonomous spending, this is the wrong tool. If you want an agent that does the paperwork while a human keeps the keys, it fits.

Try it

Fees are 0.49% on small payments, falling by size to 0.01%, capped at $100, and the receiver always gets the exact amount. You can try a real payment with test coins at https://send21.io/demo without an account or email, and the configs and examples above are in https://github.com/send21io/send21-examples. MCP setup details are at https://send21.io/docs/mcp. Questions go to info@send21.io.

What should an AI agent do when it hits its budget?

send21 — Sat, 10 Oct 2026 18:26:28 +0000

Give an agent a budget and sooner or later it reaches the edge of it. A research agent has spent 4.20 of its 5.00 USD cap, and the next step (one more paid API call, a dataset, a GPU minute) costs 1.50. What should happen now?

This post looks at three options and shows one way to build the third, with a small open-source example you can run offline.

Disclosure: I'm with send21. The example uses send21 to prepare a payment request, but the pattern works with any approval channel.

The problem

Spend caps exist because agents are not good judges of when something is worth paying for. A loop, a bad plan, or a prompt injection can turn "one more call" into a large bill. So we put a hard number in front of the agent.

The cap is the easy part. The hard part is what the agent does when the cap says no, because that is exactly the moment when the task is often nearly done and the extra spend is often justified.

Option 1: raise an error

The simplest thing: throw, log, stop.

It is safe. Nothing gets spent. But the run is lost, the context is gone, and someone has to notice the failure, read the logs, bump a config value and start again. In practice people respond by setting caps high enough that they never trigger, which defeats the point.

Option 2: overspend

Let the agent go over "just this once", maybe with a soft limit and an alert.

This keeps the task alive, but now the cap is a suggestion. If the agent can decide to exceed it, so can a buggy plan or an injected instruction. Any limit the agent can talk itself past is not a limit.

Option 3: hand off to a human

The agent stops at the cap, explains what it needs and why, and waits. A human decides. If they approve and pay, the agent continues from where it paused, with its state intact.

This keeps the cap hard and the task alive. It needs three pieces:

A guard that says "ok" or "handoff" before each paid step.
A way to ask a human for exactly the shortfall, with a link they can act on.
A way to resume the paused run safely when the human has acted.

Building option 3

The example repo is send21-over-budget-handoff: Python, MIT, a LangGraph adapter, an offline mock mode and 25 tests. It is an example, not an official LangGraph integration.

1. The guard

The cap check is deliberately boring:

@dataclass
class BudgetGuard:
    cap: Decimal
    spent: Decimal
    currency: str = "USD"

    def check(self, cost: Decimal) -> Literal["ok", "handoff"]:
        return "handoff" if self.spent + cost > self.cap else "ok"

4.20 + 1.50 > 5.00, so the step does not run.

2. The ask

On "handoff", the agent calls the send21 MCP tool create_payment_request with an amount, a payee address, a memo and an orderId. It gets back an id and a payPath, prints the pay link, and pauses with LangGraph's interrupt():

def wait(s: State):
    run = store.get_run(s["run_id"])
    data = interrupt({"pay_link": run["pay_link"], "order_id": run["order_id"]})
    # Resumed by a verified draft.confirmed. Raise the cap by the confirmed amount.
    cap = Decimal(s["cap"]) + Decimal(str(data.get("fiatAmount", run["pending_cost"])))
    return {"cap": str(cap), "handoff_step": None}

The important part is what the agent's key can do. It is created with the drafts:write scope only. send21 prepares payment instructions; the human opens the link and signs in their own wallet, and funds go straight from the payer's wallet to the receiver's wallet. send21 never holds keys or funds, and the agent's key cannot move funds. There is no signing code and no private key in the repo. The only way past the cap is a human signature.

3. The resume

When the payment is confirmed, send21 sends an HMAC-signed draft.confirmed webhook. The receiver checks X-Send21-Signature-V2 in constant time before parsing anything. It is an HMAC-SHA256 of "<timestamp>.<delivery id>.<raw body>", so the time and the delivery id are signed too: deliveries older than 5 minutes are refused and a copied delivery cannot be replayed. The legacy X-Send21-Signature (raw body only, no timestamp) is still sent for compatibility and is used only when no V2 header is present:

def verify_signature_v2(raw: bytes, header: str | None, delivery_id: str | None, secret: str) -> bool:
    if not secret or not isinstance(header, str) or not delivery_id:
        return False
    parts = dict(p.split("=", 1) for p in header.split(",") if "=" in p)  # t=<timestamp>,v1=<hex>
    t, v1 = parts.get("t", "").strip(), parts.get("v1", "").strip()
    if not t.isdigit() or not v1 or abs(time.time() - int(t)) > 300:  # refuse > 5 minutes old
        return False
    mac = hmac.new(secret.encode(), f"{t}.{delivery_id}.".encode() + raw, hashlib.sha256).hexdigest()
    return hmac.compare_digest(mac.encode(), v1.encode())


def verify_delivery(raw: bytes, headers: dict, secret: str) -> bool:
    v2 = headers.get("X-Send21-Signature-V2")
    if v2 is not None:  # V2 first; no fallback when a V2 header is present
        return verify_signature_v2(raw, v2, headers.get("X-Send21-Delivery"), secret)
    return verify_signature(raw, headers.get("X-Send21-Signature"), secret)  # legacy fallback

Then it stores the delivery id so retries do nothing, matches orderId to the paused run, and resumes it with Command(resume=...). Run status only moves forward, so a late or out-of-order event cannot undo a resume. A draft.amount_mismatch event marks the run for review instead of resuming.

Try it without paying anything

python3.11 -m venv .venv && . .venv/bin/activate
pip install -e ".[dev]"
python scripts/run_demo.py --mock
pytest

Mock mode uses a fake client and a locally signed fake webhook, so it needs no network and no account. The output is the same every run, and it is what the GIF above shows.

Using another framework

The core in handoff/ has no LangGraph imports. To port it, keep the guard, the client and the webhook receiver, and replace the adapter: pause at the handoff, and call resume(run_id, event_data) when the webhook arrives.

What is still open

The README lists what is not yet verified against the live API, for example testnet support for API keys and the exact payPath format. Live mode keeps checkpoints in memory, so use a persistent checkpointer for anything beyond a demo.

Takeaway

A spend cap is only useful if hitting it is a normal, recoverable event. Erroring throws work away, overspending makes the cap meaningless. Handing off keeps the cap hard and puts the decision with a person, who approves with a signature the agent cannot forge.

Repo: https://github.com/send21io/send21-over-budget-handoff
More examples: https://github.com/send21io/send21-examples
send21 MCP: https://send21.io/mcp
Questions: info@send21.io

How to invoice in EUR or SEK and get paid in EURC to your own wallet

send21 — Tue, 06 Oct 2026 09:36:24 +0000

Disclosure: this is written by the team behind send21.

You have a client in another country who is happy to pay in stablecoins. You invoice in EUR or SEK, because that is what your books are kept in. Then the questions start. Which rate turns the invoice into a stablecoin amount? What exactly should the client send? What if the amount that arrives is a little short?

This guide shows how to handle that with send21, non-custodial software that creates pay links and prepares payment instructions. The payer signs in their own wallet, and the funds go from their wallet straight to yours. send21 never holds keys or funds.

The problem

Card and bank fees on cross-border payments add up. Stablecoins avoid some of that, but bring bookkeeping questions:

The invoice says 10 000 SEK. The client pays in EURC. What rate was used?
When was that rate taken, and from which source?
Which document goes into your books?

A wallet address pasted into an email answers none of these.

What you need

A self-custody wallet that can receive EURC or USDC on Solana, Ethereum or Base.
A send21 account. You sign in with a passkey, or with email and password plus a second factor.
A client who can pay in EURC or USDC from a wallet or an exchange.

If you want to see the whole flow first, the testnet demo at send21.io/demo runs a real payment with test coins. No account and no email needed.

Step by step: a pay link priced in EUR or SEK

New accounts start on a "Get paid" screen. It helps you create your first pay link. The steps:

Start a new payment request from the "Get paid" screen.
Set the price in your invoice currency, such as EUR or SEK. Prices work in 161 fiat currencies.
Choose where you want to be paid: your own wallet, on the network you use for EURC or USDC.
Create the link and send it to your client together with your invoice.

For clients in the EU, EURC is the natural first choice, with USDC as the alternative. EURC and USDC both work on Solana, Ethereum and Base.

What your client sees

The client opens the link and picks a currency. They scan one QR code and pay from any wallet. They do not need a special wallet or a send21 account.

The client signs the payment in their own wallet. send21 does not sign anything and does not broadcast anything.

The rate is locked and recorded

The fiat price is converted at an exchange rate that is locked for 15 minutes. send21 records the rate source and the time.

send21 also creates a branded PDF with the payment details. Keep it with your invoice. Rules for recording stablecoin payments differ between countries, so check your bookkeeping with your accountant.

When an exchange withdrawal arrives a bit short

Exchanges often deduct a withdrawal fee from the amount sent. Your invoice says one amount and slightly less arrives.

send21 flags this. When a payment within 10% of the billed amount reaches your receiving address after the pay link was created, send21 alerts you by email, in the app and by webhook. You decide what happens next. You can accept it as paid with one click, or ask the client for the difference. The client sees a notice not to pay again, so they do not pay twice.

This has limits. A payment more than 10% off is not flagged, and neither is one that could belong to several open payments on the same address. Then you check your wallet yourself.

What it costs

The fee is 0.49% on payments under $10, falling by tier to 0.01% above $100,000. The minimum is $0.01 and the maximum is $100 per payment. On pay links the fee is billed to your account and settled later in one payment. It is never taken out of the client's payment, so you receive the exact amount. There is no subscription, no setup fee and no exchange-rate spread. The full schedule is at send21.io/pricing.

For developers

If you build tools for freelancers, the same flow is available in code:

MCP server at https://send21.io/mcp (Streamable HTTP), with tools for drafts, payment requests, rates and fees. An AI agent can create and track a pay link. It cannot pay, because no key send21 issues can move funds. A human signs.
REST API with scoped keys, idempotency keys and batch creation of up to 25 per call. Docs are at send21.io/swagger.
Webhooks signed with HMAC, so your backend can verify that an event came from send21 before marking an invoice as paid.
A machine-readable overview at send21.io/llms.txt.

The public examples repo at github.com/send21io/send21-examples has a script that creates a pay link through MCP and a webhook receiver that verifies the signature.

Honest limits

Know what send21 does not do:

No payouts to bank accounts and no conversion to fiat. You receive stablecoins in your own wallet.
A human always signs. Neither send21 nor an agent using its API can pay on anyone's behalf.
Payments that are more than 10% off, or that could match several open payments, are not flagged and need a manual check.
This guide covers EURC and USDC, the stablecoins we suggest for EU clients.
It is for people who are comfortable holding stablecoins and looking after their own wallet.

Try it

Run a test payment in the demo at send21.io/demo. No account needed. Then create a real pay link from the "Get paid" screen for your next invoice.

Questions, or a workflow we do not cover yet? Write to info@send21.io.

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