Paid instantly. Protected anyway.
Backstop lets a merchant spend a crypto payment the moment it arrives, while the buyer keeps a defined right to a refund. The refund is paid from a reserve that was locked before the payment was accepted.
Backstop separates payment finality from risk finality: the transfer is final, and the liability for a later refund sits with a funded provider reserve.
Final transfers are not chargebacks.
A blockchain transfer cannot be recalled by the sender once it is final. That is good for merchants and hard for buyers and payment platforms, who need a defined way to get money back when something goes wrong.
| Approach | Merchant | Buyer |
|---|---|---|
| Plain crypto transfer | Gets funds immediately | No recourse once the transfer is final |
| Escrow only | Waits for settlement | Protected |
| Backstop | Gets funds immediately | Protected by a funded reserve |
Backstop does not undo finalized blockchain transactions. It makes the refund obligation a funded contract that exists before the payment is accepted.
Separate payment finality from risk finality.
A protection provider commits capital from an independently funded reserve for each protected payment. The merchant is paid directly. If a claim is approved later, the buyer is refunded from the reserve, not from a merchant wallet that may already be empty.
Committed reserve ≥ protected payment, at all times, until the claim period ends or the claim is paid.
Refund after the merchant spends everything.
Reserve pool of 5,000 simulated USDC, one protected payment of 1,000. Balances after each step:
| Step | Buyer | Merchant | Locked | Uncommitted |
|---|---|---|---|---|
| Start | 1,000 | 0 | 0 | 5,000 |
| Protected payment | 0 | 1,000 | 1,000 | 4,000 |
| Merchant spends all | 0 | 0 | 1,000 | 4,000 |
| Dispute filed | 0 | 0 | 1,000 | 4,000 |
| Two reviewers approve | 0 | 0 | 1,000 | 4,000 |
| Appeal window ends, refund paid | 1,000 | 0 | 0 | 4,000 |
The pool is 1,000 smaller after the refund (4,000 instead of 5,000). That is the loss the provider reserve absorbs. The merchant wallet is never touched.
From payment to payout.
- Protected. Payment and reserve commitment happen together. The merchant has the funds.
- Disputed. The buyer opens a case inside the protection period. An allegation alone moves no money.
- Review. Two reviewers decide. Both must approve. A single rejection denies the claim and releases the commitment.
- Appeal. After two approvals a waiting period starts. Payout is blocked until it ends.
- Refunded. The buyer is paid from the reserve once. The commitment is released and the claim cannot be paid again.
What the reference model enforces.
Each rule below is a check in the reference model, and the interactive demo runs one test per rule against fresh ledgers.
| Rule | Prevents |
|---|---|
| Coverage check | A payment larger than the uncommitted reserve. Nothing is paid if it fails. |
| No double pledging | The same reserve backing two payments. |
| Two reviewers | A single operator deciding a claim. |
| One vote each | A reviewer voting twice. |
| Appeal wait | Payout before the appeal window ends. |
| Single payout | Duplicate or replayed refunds. |
| Release on denial | Reserve staying locked after a rejected claim. |
| Merchant wallet untouched | Clawbacks from a merchant who already spent the funds. |
| Conservation | Value appearing or disappearing: buyer + merchant + spent + pool stays constant. |
Who does what.
Pays protected
Opens a dispute inside the protection period. Receives the refund if the claim succeeds.
Receives instantly
Can spend the funds immediately. Is not asked to return them after a refund.
Funds the reserve
Commits capital before acceptance. Absorbs the loss on an approved claim.
Decide claims
Two independent reviewers. Appeals use fresh reviewers.
Insurance-like promises need real capital.
An AI recommendation or a signed status message is not collateral. Backstop is designed around four constraints.
No new guarantee without unencumbered capital.
No double payout, no replayed claims.
No single operator should bypass committed reserves.
Evidence, two reviewers, appeal and auditable rules.
Exchange hacks and merchant-payment disputes are separate products with separate security and liability models. Backstop covers the second.
Clear boundaries, not invented traction.
Local immediate credit, pooled collateral, two reviewers, appeals, limits, pause controls, locally signed provider messages, key rotation and replay tests. Original source files and test output were not supplied for independent verification.
A separate Python reference implementation and a browser walkthrough. Ten local tests pass, covering zero-balance refund, single refund, unique payment IDs, coverage, double pledging, dispute denial, fresh appeal reviewers, appeal wait, pause and expiry.
A real blockchain transaction, enforceable smart-contract collateral, an authenticated partner API, external providers, key custody, a security audit, licenses, real protection funds and a signed exchange pilot.
Try to break it.
The demo is a single HTML file that runs entirely in the browser. It uses the same ledger code for every button and for its self-test.
- Set the numbers. Choose a payment amount and a reserve pool. A reserve smaller than the payment makes the coverage check refuse the payment.
- Step through. Pay, let the merchant spend, file a dispute, then have each reviewer approve or reject.
- Attack it. Over-commit the reserve, request an early refund or claim a second refund and read the rejection.
- Auto-play. Run the refund path or the denied path from start to finish.
- Self-test. Eleven rules, each checked on a new ledger.
The demo holds no cryptocurrency, verifies no identity and executes no signatures. It shows the accounting model, not the infrastructure.
One standard. Independent reserves.
The longer-term design is a shared set of payment and dispute rules, with each exchange, payment provider or wallet partner keeping its own vault. Exchanges keep economic ownership of unencumbered funds. Committed capital is locked to defined obligations.
Payment rules · dispute rules · claim states
Exchange A
VAULT
Payment provider
VAULT
Wallet partner
VAULT
This is a target design: a provider registry, enforceable reserves and shared claim states. It is not a deployed network.
From simulation to a verifiable pilot.
The next milestone is a testnet-backed reserve that can be enforced. Pilot gates matter more than launch dates.
- Trust model and APIReal identities, signed requests, a map of who has authority over reserve funds, signing keys, dispute decisions and failure handling.
- AccountingDurable ledger, idempotent postings, reconciliation.
- CollateralBinding control that prevents double pledging, through a limited on-chain vault or independent custody and signing.
- TestnetOne chain and one stablecoin-like test asset with verifiable deposits, seller credit, dispute and payout.
- Pilot gateIndependent security assessment, risk and legal scoping, partner design sign-off.
No real customer funds before independent technical and legal review.
B2B infrastructure, not a consumer wallet.
First users are payments, risk and engineering teams at exchanges, wallets and stablecoin payment providers that want to offer opt-in protection from their own segregated reserves.
API, SDK and sandbox for protected payment acceptance.
Protocol usage fee on completed protected payments.
Optional claim-processing and risk services. Premiums compensate the capital providers for their actual loss exposure.
Gross payment volume is not revenue. No customers, revenue, token, funded protection pool or exchange agreements are claimed.
Common questions.
Does Backstop reverse a blockchain transaction?
No. The transfer stays final. The buyer is refunded from a reserve that was committed beforehand.
What if the merchant has already spent the money?
It does not matter for the refund. The payout comes from the provider reserve, and the merchant wallet is not touched.
Who pays for a successful claim?
The provider whose reserve backed the payment. Protection premiums are meant to compensate capital providers for that exposure.
Can a buyer get a refund just by filing a dispute?
No. A dispute moves no money. Two reviewers must approve, then an appeal window must pass.
What stops the same reserve backing many payments?
The coverage check refuses any payment that exceeds the uncommitted reserve, and committed capital stays locked until the claim ends.
Is this live?
No. It is a local proof of concept. There is no blockchain, no real funds and no audit yet. The roadmap lists the steps toward a testnet pilot.
Is the original code verified?
No. The original source files were not available for independent review. The reference model and the demo were newly written from the founder's roadmap.
What this documentation does not claim.
- No live exchange integrations, customers, revenue, funded pools or audits.
- No guaranteed investment returns and no guaranteed buyer protection.
- The demo is a simulation of the accounting model. It does not prove security, solvency under attack or regulatory compliance.
- The partnership request is for exploratory talks, one design partner for a strictly limited testnet trial, and pre-seed or grant support for engineering, security and regulatory scoping.
Gökhan Acilanmak · Backstop