HOW TAB WORKS

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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