Backsies — Technical Whitepaper v0.1

November 4, 2026

Summary

Backsies is a security protocol on Robinhood Chain that adds an undo window to crypto transfers. Sent funds wait anywhere from a few minutes to a few hours. If the sender cancels during that time, the funds go back to a safe address registered in advance.

The name comes from crypto's unwritten rule: "no backsies" — once it's sent, you can't take it back. Backsies removes that rule.

• Product: Undo RPC, Backsies Account (a smart account module) and bUSDG (a reversible stablecoin)
• Network: Robinhood Chain (Arbitrum Orbit L2, chain ID 4663)
• Token: $BACKSIES, used for in-protocol payments, staking and governance
• Who it's for: Robinhood users who are new to crypto first, then wallets and exchanges (B2B)

The problem

Crypto transactions can't be reversed. Card payments have chargebacks and bank transfers can be cancelled, but on-chain a single bad signature loses the funds for good.

The main sources of loss:

1. Drainers and phishing: A fake site gets the user to sign a transaction that looks harmless, and the wallet is emptied within seconds.
2. Malicious approvals: The user gives a contract unlimited spending permission; the funds can be pulled days later.
3. Blind signing: The wallet doesn't clearly show what the signed transaction actually does.
4. Address poisoning: An attacker sends a small transfer from an address that looks like one in the user's history; later the user copies the wrong address.
5. Key theft: If the seed phrase is compromised, the attacker moves every asset instantly.
6. Plain mistakes: Wrong address, wrong amount, wrong token.

On Robinhood Chain this problem is sharper. Most users are investors coming from a brokerage with no crypto history. High-value assets such as tokenized stocks and USDG live on the same chain.

Existing security tools (transaction simulation, warning extensions) only warn beforehand. Once the signature is made, none of them can bring the funds back. That's the gap Backsies fills.

The solution

Backsies holds every outgoing transfer for a short time and gives the sender the right to cancel during it. There are six core mechanisms:

1. Undo window: The transfer first goes into the Backsies vault. When the time is up it passes to the recipient; if it's cancelled before then, it comes back.
2. Safe address: Cancelled funds don't return to the sending address but to a pre-registered safe address (a cold wallet or second wallet). Changing this address takes 48 hours. Even if an attacker who stole the key triggers a cancel, they can't get the funds.
3. Smart delay: Risk sets the waiting time. 0 minutes to an allowlisted address, 5 minutes for a small amount to a new address, 24 hours for a large amount to a suspicious contract. The upper limit is 72 hours.
4. Approval protection: Spending permissions given to an unknown contract also enter the window and can be cancelled.
5. Notifications: Telegram, push and email for every pending transaction: "5 ETH is going to a new address. Was that you?"
6. Guardian: A person or hardware wallet the user chooses can veto a pending transaction.

Design decision: the recipient can't shorten the window. If the recipient were allowed to pay a fee to receive funds early, a drainer would always pay that fee and the protection would be useless. Only two paths shorten the window:

• Express approval: The sender approves with a second factor (passkey, guardian or hardware wallet) and pays a small fee.
• Verified recipient: Exchanges and merchants join the Backsies registry with a stake; transfers to them go through instantly.

Architecture

Backsies has three entry points, and all three meet in the same immutable vault. The Undo RPC runs off-chain and doesn't touch the vault.

Robinhood Chain supports ERC-4337 account abstraction as a first-class feature and also supports EIP-7702, so users gain smart account features without changing their address (Robinhood Chain documentation). Alchemy can be used for the bundler and paymaster, with ZeroDev as an alternative.

Smart contract specification

The system is an immutable core vault that holds funds, with modules plugged in around it. Contracts are written in Solidity ^0.8.28, tested with Foundry and verified on Robinhood Chain testnet (chain ID 46630).

Transfer states

Queued → Released (time is up, anyone can trigger it) or Queued → Cancelled (the sender or a guardian cancelled; funds go to the safe address). Released and Cancelled are final states; there is no going back.

Rules

• cancel always sends funds to safeAddressOf(sender); if no safe address is registered, the transfer isn't queued.
• release is permissionless. The Backsies keeper bot triggers expired transfers automatically, but if the keeper stops, the recipient can trigger it themselves.
• The vault can never send funds to a third address without the owner's approval.
• The vault has no admin role.
• Reentrancy protection, checks-effects-interactions ordering and fee-on-transfer token checks are mandatory.
• The delay comes from the PolicyModule, but the vault enforces the 72-hour upper limit itself.
• An emergency pause only stops new queueing; cancel and release can never be paused, so users can always get out.

Security model and threat analysis

Full protection against key theft exists only in Vault Mode (ERC-4337 smart account). The Undo RPC and 7702 mode protect against bad transactions the user signs themselves. This distinction must be stated clearly to users.

Known limits

• 7702 re-delegation: An attacker who has the key can sign a new 7702 authorization, point the account at a different contract and disable the module. That's why key-theft protection isn't promised in 7702 mode; Vault Mode is recommended for serious balances.
• Off-chain signatures: Permit signatures made with the EOA key never pass through contract code. The Undo RPC and the interface scan these signatures and warn, but can't block them.
• The Undo RPC can be bypassed: An attacker can broadcast the transaction through a different RPC. For a cancelled transaction, the interface suggests a zero-value self-transfer with the same nonce, which invalidates the signed transaction.
• Recipient-side fraud: A sender could cancel after receiving goods or services. Merchants register as verified recipients, or accept payment once the window ends.

Security process

• At least two independent audits for the core contracts
• Fuzz and invariant tests with Foundry: total vault balance = sum of pending transfers
• A per-transaction amount limit for the first 90 days of mainnet
• A public bug bounty program

Upgradeability and the module market

The ground rule: the code that holds funds never changes; the rules keep evolving. The promise to users is: "Not even we can change the code that holds your money."

How upgrades work

1. Core (BacksiesVault, SafeAddressRegistry, bUSDG): No proxies. If a new version is needed, it's deployed to a new address; users migrate by choice and the old version keeps working.
2. Modules (ERC-7579): Every module is versioned (PolicyModule v1, v2…). Users plug the new version into their own account. There are no forced upgrades.
3. 7702 delegation target: New account code is published at a new address; users switch by signing a new authorization.
4. Registry parameters (RecipientRegistry, fees): Changed by a 3/5 multisig with a 48-hour timelock. Every change is announced on-chain and on the site.

Module market

Outside developers can write their own rule modules and list them in the Backsies Module Registry.

• Listing requires a $BACKSIES stake and the module's audit report.
• Users install modules from the interface in one click.
• Developers get a share of the fees their module generates.
• A module proven harmful or faulty has its stake burned and is delisted.
• Users remove already-installed modules themselves; Backsies can't delete them remotely.

Example modules: drainer address list, daily spending limit, new-token protection, AI risk score, family account (parent as guardian), company treasury rules.

Token

$BACKSIES is the tool for using, protecting and governing the protocol; it is not offered as an investment product. A total supply of 1,000,000,000 is proposed, with no later minting.

Uses

• Fees: Express approval and the Pro plan are 30% cheaper when paid in $BACKSIES; part of the tokens paid is burned.
• Verified recipient stake: Exchanges and merchants stake to join the registry. If abuse is proven, the stake is burned.
• Module stake: Module developers stake to list.
• Holder features: Holding a set amount unlocks the AI risk score, longer guardian periods and higher limits.
• Governance: Votes on fee rates, new chains and treasury spending.

Distribution (proposed)

Rug-proof launch

A security project's token should have the cleanest launch possible:

• Team and treasury wallet addresses are published on the site before launch.
• Liquidity locks and vesting contracts are verifiable on-chain.
• The treasury is protected by Backsies Vault Mode. Every transfer out of the treasury waits 48 hours and is visible to everyone.
• The token launches alongside a working product (at least the Undo RPC); there is no presale without a product.
• There is no revenue sharing and no promise of returns. See Risks for legal matters.

Revenue model

Basic protection is free. Revenue comes from people who want speed and advanced features, and from business partners. Fee amounts will be set after the beta, based on user data.

Part of the fees goes to the treasury and part to burning $BACKSIES. The ratios are set by governance.

Roadmap

The token comes last: each phase starts only after the previous one passes its gate.

At the end of Phase 1, Backsies applies for Arbitrum and Robinhood Chain ecosystem grants. If a gate isn't passed, no money is spent on the next phase; the product is reshaped instead.

Risks and legal note

The biggest risk isn't technical, it's distribution: users have to accept waiting, and merchants have to adopt reversible payments.

Legal note

This document is not investment advice or an offer to sell tokens. The project team is based in the United Kingdom. In the UK, cryptoasset promotions are subject to the FCA's financial promotion rules, and a token launch and social media promotion may fall within that scope.

Sources

• Robinhood Chain — Account abstraction (ERC-4337, EIP-7702)
• Robinhood Chain — Notices and upgrades
• ArbitrumDAO factsheet: Robinhood Chain mainnet
• Arbitrum ArbOS 40 Callisto and EIP-7702
• Chainstack — Robinhood Chain RPC, gas token
• Entrepreneur — wallet infrastructure and blind signing