Local proof of concept No real funds Not audited
Launch App Local prototype

Crypto payment protection / local preview

Paid instantly. Protected anyway.

A crypto payment can stay final without leaving buyers without recourse. Backstop explores a separate refund path, funded before the payment is accepted.

Launch App How the model works
Simulated funds only Wallet connection preview
Local sandbox · no real funds See the flow

01 / The principle

No chargebacks.
A different kind of protection.

A finalized crypto transfer cannot simply be reversed. Backstop separates payment finality from a potential refund claim backed by a reserve committed in advance.

01 Payment

The merchant receives the payment.

After a simulated provider confirmation, the test balance becomes available to the merchant in the protocol.

No clawback from the merchant wallet
02COVERAGE

A reserve stays separate.

Before acceptance, the simulation checks that the pool can fully cover the potential refund.

Committed up front / simulated locally

Important: A database reservation is not custody or an independently enforceable guarantee. No real funds move here.

02 / From purchase to outcome

Every step has
a clear boundary.

This is the flow modeled by the local protocol. The website does not run it interactively yet; browser integration comes after the UI and API are ready.

  1. 01
    BUYER + MERCHANT

    Agree on the terms

    The amount, purchase terms and parties are clearly defined.

    Core modeled
  2. 02
    BACKSTOP / POOL

    Check coverage and limits

    The pool reserves the full potential refund; admission rules constrain each commitment.

    Core modeled
  3. 03
    PAYMENT PROVIDER

    Confirm the payment

    The prototype verifies a signed test message. It does not prove that a real payment was received.

    Test message
  4. 04
    BUYER + REVIEWERS

    Review and decide a claim

    Claims, merchant responses, independent votes and appeals follow defined time windows.

    Core modeled
  5. 05
    LEDGER / POOL

    Refund or release the reserve

    The case ends with a recorded refund from the pool or the release of committed coverage.

    Ledger in progress

Protection is a separate claim — not a chargeback and not a promise that a real reserve already exists.

BACKSTOP RECOVER / CONCEPT

A separate path
for a refund claim.

Backstop Recover is the protocol concept behind the local sandbox: the original merchant payment stays separate from a potential buyer refund, which is limited by coverage reserved in advance.

01 / PAYMENT

Merchant settlement remains distinct

The local model credits the merchant after a simulated provider confirmation. Backstop does not reverse that transfer when a refund is later approved.

LOCALLY TESTED
02 / CLAIM

Evidence and independent review

The sandbox exercises a non-delivery claim, triage, two reviewer votes and a simulated appeal window using the existing protocol rules.

LOCAL SANDBOX
03 / LIMIT

Recovery is not guaranteed

A refund depends on eligibility, reserved test coverage and the protocol decision. The concept does not promise a real-world recovery or legal chargeback.

PRODUCT DESIGN

The browser demo uses TEST-USD and pre-provisioned roles. It is not connected to an exchange, wallet or real reserve.

PROTECTION POOLS / TWO LOCAL MODELS

Coverage must be
reserved, not implied.

The Node.js sandbox and Solidity vault are separate local prototypes. Neither currently proves a shared, funded pool or a single atomic off-chain/on-chain payment.

LOCAL SQLITE

Sandbox pool

Pool total, available coverage and reservation balances are read from the existing API and ledger-backed reservation flow.

Open sandbox pool view
LOCAL EVM

Mock-USDC vault

The isolated Hardhat prototype tests six-decimal mock collateral, protected payments, reserves, disputes and refunds on local chain ID 31337.

Read vault limits
Not Base Sepolia.No deployment, testnet address, transaction receipt or link between the two prototypes has been verified.

INTEGRATION SURFACES / PLANNED

Designed for the
existing payment stack.

Integration targets are architecture directions, not available connectors. Each needs its own security, identity, settlement and operational acceptance before any partner claim.

01 / EXCHANGES

For exchanges

Potential connection to provider settlement and reserve operations, after a persistent integration adapter and partner controls exist.

PLANNED · NO EXCHANGE
02 / WALLETS

For wallets

Connect a browser wallet in the app and check testnet readiness. Transaction signing and token approvals await verified testnet contracts.

CONNECTION PREVIEW
03 / PAYMENT PROVIDERS

For payment providers

The local signed mock provider validates a test message only. Provider SDK, live settlement and external credentials are not available.

PLANNED · MOCK ONLY

SECURITY & TRUST / CURRENT EVIDENCE

Show the boundary.
Then show the evidence.

Local tests and role checks are engineering evidence, not an audit or a guarantee. The current prototype is intentionally limited to a loopback sandbox and local mock assets.

Local authorization

Sandbox personas exercise the existing API roles. They are fixed test identities, not production authentication.

Read-only checks

Reconciliation reports local findings and does not change balances, reserves or case decisions.

No external proof

No independent contract audit, testnet deployment, real token custody or provider settlement is evidenced.

Read security boundaries

ECOSYSTEM / FUTURE GATES

One protocol idea.
Separate integration gates.

Backstop Recover is the protection concept. Exchange, wallet and provider integrations, multi-chain adapters and risk operations remain separate planned workstreams.

Recover Local prototypeWallets Connection previewProvider SDK PlannedMulti-chain PlannedRisk & operations Later gatesAI Assist / Prevent Not available

IMPLEMENTATION / CURRENT EVIDENCE

What works today.
What remains planned.

EVIDENCE STATUS / LOCAL ONLY

Available cards link to the current local website, sandbox and repository documentation. Planned integrations are labeled and are not represented as working services.

Local UI available Local logic / separate prototype Current gate Planned / not available

Showing all product and integration surfaces.

01

The web experience

PUBLIC → PURCHASE → CLAIM
01Available
/ — BACKSTOP WEBSITE

Product model and trust context

Explains the reserve concept, current evidence and the boundaries between local simulation and future integrations.

Static websiteCurrent statusNo live transaction
LOCALWebsite content
02Sandbox only
/app — LOCAL SANDBOX

Buyer, merchant, pool and reviewer workspaces

Runs the API-backed TEST-USD payment, pool reservation, simulated transfer, claim, reviewer decisions and read-only reconciliation.

Loopback APIFixed test identitiesIn-memory data
LOCALLaunch sandbox ↗
03Sandbox only
/app — BUYER WORKSPACE

Protected test payment

The local flow asks the API to create the offer, record terms acceptance and authorization, reserve pool coverage and accept a signed mock-provider confirmation.

TEST-USDAPI rolesIdempotency
LOCALNot a wallet checkout
04Sandbox only
/app — MERCHANT WORKSPACE

Received test funds

Shows the current sandbox payment and merchant balance; the merchant can transfer its received TEST-USD to the simulated external account.

One fixture paymentLocal balanceIn-memory data
LOCALNo production account
05Sandbox only
/app — CASE REVIEW

Claim, evidence and decision state

One local claim can be opened, triaged and decided by two pre-provisioned reviewers under the protocol's simulated deadlines.

Local test evidenceReviewer rolesNot production governance
LOCALOne current fixture case
06Read-only sandbox
/app — RECONCILIATION

Financial consistency report

Surfaces local checks, statuses and findings without correcting balances or making decisions. `NOT_VERIFIABLE` is not a clean bill of health.

Read-only APIFindings exposedNo external proof
LOCALSQLite records only
02

Operations and integrations

DECISION → COVERAGE → TEST
07Local prototype
LOCAL EVM / HARDHAT

Separate Solidity mock vault

Mock-USDC collateral and refund paths run in local Hardhat tests. The contract is not connected to the website or SQLite sandbox.

Local chain 31337Mock tokenNo deployment
ISOLATEDNo Base Sepolia evidence
08Docs local
/docs — DEVELOPER GUIDES

API contract and sandbox instructions

Repository-owned quickstart, lifecycle, pool, dispute, reconciliation, vault and security-boundary documentation.

OpenAPIExamplesNo SDK package
LOCALOpen developer docs ↗
09Planned
EXCHANGE / WALLET / PROVIDER

External partner integrations

There is no live exchange settlement, payment provider SDK, production credential flow or external partner agreement.

Architecture neededPartner controlsNot available
FUTUREGate F and later
10Later
WALLET / CONNECTION PREVIEW

Wallet access and testnet readiness

Connect an injected browser wallet and request Base Sepolia explicitly. Payment signing waits for verified deployment and backend receipt validation.

Read-only accessTestnet firstSigning next
BLOCKED UNTILPool controls + testnet approval

Local UI is not a production service. The app runs real API calls against the repository's local protocol and fixture. It does not provide production login, a durable account history, live settlement, on-chain reserve custody or external identity verification.

DEVELOPERS / LOCAL DOCUMENTATION

From first run
to protocol details.

Repository-owned guides explain the local sandbox, payment lifecycle, pool coverage, claims and technical limits. OpenAPI describes the implemented API routes; no SDK or public developer account is available.

Open developer docs Open the API specification
01Run the sandboxRequirements, startup and guided local flow 02API referenceOpenAPI contract, roles and idempotency 03Ledger & reconciliationLocal evidence, report statuses and limitations 04Solidity vaultSeparate local EVM prototype and boundaries

05 / Project status

What exists.
And what does not.

A development project with local evidence — not a finished financial product. Status labels distinguish tested simulation from real infrastructure.

ALocally tested

Protocol, ledger and claim lifecycle

SQLite ledger v4, reservations, signed mock-provider messages, case decisions, time windows and refunds have local tests.

BLocal sandbox

Website, API and sandbox workspaces

Buyer, merchant, pool, review and reconciliation views call the loopback API with fixed test personas.

CNot integrated

SQLite-to-EVM transaction bridge

The local Solidity vault is a separate prototype. Durable cross-system transaction state and reorg-safe reconciliation are not implemented.

NOT AVAILABLE YET

A production deployment is still a long way off.

  • Wallet or Base Sepolia app
  • Live provider settlement
  • SQLite/EVM transaction bridge
  • Production identities and operations
  • Independent security audit

GATES A–G / MASTER ROADMAP

Build evidence
before integrations.

Gate order is authoritative. Local test results do not imply hosted release, testnet deployment, audit or production readiness.

  1. A

    Engineering foundation

    Local Git baseline, CI configuration, tests and reproducible verification. Hosted CI remains externally unverified.

    LOCAL PASS
  2. B

    Website, docs and sandbox application

    Local functional flow and bounded B3 browser, UI and documentation acceptance passed. No public deployment or accessibility certification is claimed.

    LOCALLY ACCEPTED
  3. C

    Persistent blockchain/backend integration

    Durable transaction journal, retry handling, confirmation, event reconciliation and reorg safety.

    PLANNED
  4. D

    Base Sepolia testnet product

    Requires Gate C, explicit approval, test-only assets and verified deployment/receipt evidence.

    PLANNED
  5. E

    Financial security, risk and operations

    Independent review, operating controls, incident response, monitoring and recovery evidence.

    PLANNED
  6. F

    Provider network and bounded pilot

    Named partner evidence and controlled pilot only after operational and security acceptance.

    PLANNED
  7. G

    Ecosystem expansion

    Wallet, exchange, multi-chain, Recover and other modules are separate future scopes, not current features.

    LATER

A prototype, not a promise

Good infrastructure
starts with clear boundaries.

Wallet connection preview. Simulated browser payments. No real-funds settlement, confirmed partner integration or independent audit.

Launch local sandbox Developer documentation