TAB

Keep a tab open

One transaction per request is the right shape for one request. It is the wrong shape for a loop. A tab is the loop’s shape: one deposit, metered off-chain per call for nothing, settled on-chain when the service feels like it.

How it runs

1The payer opens a tab for one service, funds it in USDG, and names a session key. That key never holds money and can only ever authorise spending from this tab, up to its deposit.
2Per call, the session key signs Voucher(uint256 tabId,uint256 cumulative). Vouchers are cumulative, so the latest one is the only one that matters and a lost voucher costs nothing.
3The service claims when it likes. The contract pays min(cumulative, deposit) − claimed and takes its fee at the source. Claiming is permissionless: the money goes to the service whoever sends it.
4The payer can always get the rest back. requestClose starts a challenge window it chose when it opened the tab; after it, withdraw refunds the remainder. A service in a hurry closes cooperatively instead.

A worked meter

Arithmetic, not a reading: this is what the numbers do, at the price the demo endpoint charges.

deposit10.00 USDG
price per call0.01 USDG
after 400 calls, voucher says4.00
service claims4.00 → paid 3.996, fee 0.004
after 300 more, voucher says7.00
service claims again, moving3.00
onchain transactions so far3 (open, claim, claim)
signatures so far700, all free
payer closes, gets back3.00 USDG

A voucher beyond the deposit is capped at the deposit: a tab is a ceiling, and the contract cannot be made to pay past it.

An agent that never holds ETH

openWithAuthorization and topUpWithAuthorization fund a tab from one EIP-3009 signature, submitted by anyone. The nonce of that authorization commits to the merchant, the session key and the challenge window, so a relayer carrying the signature cannot open the tab against a merchant of its choosing, with a session key it controls, or with a window it shortened. claim and withdraw are permissionless with fixed destinations. An agent can live its whole life holding nothing but dollars.

The book, live

TabBook—
tabs opened—
deposited—
claimed—
refunded—
fee taken—

Look up a tab

Every field below comes out of the contract’s own storage in one eth_call.

Sign a voucher

The real thing: the digest below is built the way TabBook.voucherDigest builds it — EIP-712, domain Tab Book v1 on chain 4663, typehash — — and signed by a key in this browser. A service would hand this to the contract and be paid.

session key—
domain separator—
cumulative, atomic—
digest—
signature—

Fill in a TabBook address: the domain of an EIP-712 signature includes the contract that will verify it, so a voucher signed for one book is worthless to another. That is the point of the field.