Docs

protocol

An invoice is nothing but an address whose private key was generated in the recipient's browser. To pay one, a payer calls pay(invoice, token, amount): the tokens land in the shared vault and claimable[invoice][token] goes up by whatever actually arrived, after the fee. To release them, anyone calls claim(invoice, token, to, deadline, signature). The contract recovers the EIP-712 signer and refuses the call unless it matches the invoice address. Permission rides in the signature rather than in the sender, which is why any wallet can broadcast the claim and pay for it.

Each signature works once, because a per-invoice nonce is part of the signed struct. It only pays out to the destination it was signed for, because to is part of it too. And it stops working at its deadline. Intercept one in flight and there is nothing useful to do with it.

keys

Connect a wallet and one signature over a fixed message becomes the root: seed = keccak(signature), with invoice N keyed by keccak(seed, N). Sign the same message on another device and every invoice that wallet ever made comes back. Only the resulting public addresses leave the browser. Skip the wallet and the root is 32 random bytes held in this browser's storage, with the backup button under the create form as the sole other copy anywhere. Lose both and the money is gone. Nothing is kept on a server, which is the point.

contracts

network

Robinhood Chain · id 4663

vault

not deployed yet

fee pool

not set

fee

0.5% on payment · ceiling 1%, enforced on chain

Pooled balances are out of the owner's reach. rescue is limited on chain to the surplus that no invoice has a claim on, and the fee ceiling is a constant the owner has no way to raise.

assets

USDG

0x5fc5…d168

NVDA

0xd060…9EEC

AAPL · paying existing links only

0xaF3D…93f9

TSLA · paying existing links only

0x322F…3b2d

AMZN · paying existing links only

0x12f1…bF54

These come from the chain's own registry and should be checked against a fork before anything real depends on them. The vault keeps an allowlist, so a token wearing the right ticker at the wrong address gets rejected.

privacy model

What stays hidden is the connection between an invoice and you. Keys never leave the browser. An invoice address shows up on chain only once someone pays it. The vault's Claimed event does not record where the money went. Your note never enters the link, and the link's payload lives in the URL fragment, which browsers do not send anywhere.

What is visible is what any chain makes visible: who paid, how much, when, and which address a claim paid out to. Because the vault is pooled, an incoming payment and an outgoing claim are two transactions against one busy contract rather than an obvious pair on a single-use address. Claim into a fresh wallet and there is nothing linking the two ends.