From an unsigned intent to settled stablecoin in two seconds.
A walk through the path a payment takes on Tab — from the moment a buyer hits Pay to the moment your webhook fires.
- 01
Wallet generated on your device
When you claim a handle, your browser creates a fresh keypair locally. It's encrypted with your PIN using AES-256-GCM and stored as an opaque blob. Tab's servers never see the unencrypted key — they couldn't sign for you if they wanted to.
- 02
Buyer signs an intent
When someone pays, their wallet signs an EIP-712 message describing exactly one transfer: recipient, amount, fee, deadline, nonce. No actual transaction is sent. The signature is the authorization, and it can't be modified after it's signed.
- 03
Relayer pays the gas
A Tab relayer takes that signed message and submits it to the on-chain router. The relayer can't change the amount, swap the recipient, or pocket extra fees — the contract recomputes the fee on-chain and rejects anything that doesn't match the signed values.
- 04
Router settles atomically
TabRouter pulls amount+fee from the buyer in one transferFrom, sends amount to the seller and fee to the treasury. Replay is blocked by a per-user nonce set. Reentrancy is blocked by a guard on every state-changing call.
- 05
Indexer fires the webhook
An off-chain indexer watches PaymentRelayed events and matches them to your open orders. Your endpoint gets a signed POST inside two seconds of settlement. From your application's perspective, the buyer just paid.
What Tab can and can't do
Can
- · See public handles and on-chain settlement events
- · Refuse to relay a transaction (the user can submit it themselves)
- · Rotate the treasury or pause the bot executor list
Can't
- · Freeze, claw back, or redirect a settled payment
- · Sign for a user — we never have the key
- · Reset a PIN or recover a wallet on your behalf