How we count savings
The Savings block of the report (/app/informe) and the card on the panel show what Burnbound kept your organization from paying in a calendar month (UTC). This page explains what counts, what does not and why. Methodology version: 2.
Two figures, never added up
- Avoided for sure. Money that would have left and been lost for certain: a double charge, or a payment to an address that is not the seller's.
- Spend contained (estimate). Payments your caps and rules stopped, which the agent did not make another way afterwards. Spend that did not happen, not necessarily money thrown away.
Amounts are in USD (USDC 1:1). Your plan is billed in euros: the panel shows both side by side and never converts them with an exchange rate.
Avoided for sure
| Category | What counts |
|---|---|
| Double charge avoided | The agent repeated a payment with the same idempotency key and got the same authorization back, without paying twice. Counted once per payment, and only if the original payment was charged. A new signature for an MPP payment whose earlier signature expired does not count. |
| Payment to a fake address | A payment denied by the injection protection: resource_host_mismatch, pay_to_denied, pay_to_not_verified, challenge_host_not_allowed, challenge_path_not_allowed or challenge_amount_exceeded. |
| Hold rejected on a security signal | A person rejected a held payment because its 402 looked like instructions to the agent, or because it went to a new pay-to address. |
Spend contained (estimate)
| Category | What counts |
|---|---|
| Caps and pace | amount_exceeds_per_transaction, daily_cap_exceeded, velocity_tx_exceeded, velocity_usd_exceeded and member_cap_exceeded. |
| Custom rules | rule_denied, rule_limit_exceeded and decision_webhook_denied. Enforced rules and webhooks only: what an observe rule or webhook would have done never counts. |
| Unverified hosts and sellers | host_not_allowed and seller_not_verified. |
| Hold rejected by a person | A person rejected a payment held by the approval threshold, by a first payment to a catalog host, by a custom rule or by your decision webhook. |
To keep the figure honest:
- Retry another way. If the same agent pays the same host successfully within the next 24 hours, the block does not count: it was a delay, not a saving.
- Loops. The same block repeated (same agent, same resource, same amount, same network and same codes) counts once, as long as less than an hour passes between one attempt and the next. An injection attempt, a block over your per-payment max and a block for an unverified host or seller are grouped by host: each counts once even if the seller changes the resource or the amount, because the seller sets both. A block that did not count because the agent got round it does not silence the next one.
- Only what could really have left. The seller sets the amount of a denied payment, and a hostile 402 can ask for anything.
- If, when it decided, Burnbound already knew the wallet's balance did not cover the payment (with the fee cap on Tempo), that block does not count: the payment would have failed anyway, because an x402 or Tempo payment is all or nothing. Burnbound never waits to read the balance before deciding.
- If it did not know, a block that asks for more than your per-payment max, or for a resource on another host, adds no amount to either figure: the report says how many there are. Any other block passed your per-payment max.
- Card and refund amounts come from Stripe, not from a seller, and count as they are.
- A block with several codes goes to the first category, in table order, of the first table that matches. If none of that table matches, it goes to the first of the second, also in its order. The order the codes come in changes nothing.
What never counts
- A block whose balance did not cover the payment, counted as
insufficient_funds. - A block with a code that says the payment would have failed or was not possible, whatever other codes it carries:
insufficient_funds,invalid_amount,network_not_allowed,asset_not_allowed,method_not_allowed,currency_not_supported,no_payable_offer,offer_not_chosen,plan_limit_reached,card_not_linked,decision_timeoutanddecision_webhook_unavailable. - An approval that expired with nobody deciding: the agent can ask again.
- Payments that failed, expired or could not be signed (
payment.failed,payment.expiredandpayment.sign_failed). - Sellers that charge and do not deliver. There is no signal for that at payment time yet.
- Test money: testnets and Stripe's test mode. Shown apart.
- Blocks recorded before the audit noted the payment's network. Counted apart, as "no network".
What got through
Payments the on-chain watcher saw outside the policy (payment.out_of_policy, client-side signing) are shown next to the savings. They are not subtracted, but they are shown.
Plans
Team, Business and the 30-day trial see both figures with their breakdown, what got through, the month's largest savings and the month before. Free sees this month's two figures. No plan sees anything older than its audit shows: older days are left out, never estimated, and the block says from which date it counts.
The card on the panel shows the current month's two figures for the whole organization, on any plan.