AgentTab — one screen, two readers
- Problem
- Payments accumulate as off-chain vouchers and settle in netted batches, so the numbers the ledger emits — cumulative voucher totals, base units, raw wallet addresses — are not the numbers a person needs to decide whether to keep the tap open.
- Solution
- One live event stream, two views behind a header toggle: a plain-language board for the person paying, and the untranslated ledger for the developer.
- Result
- 2nd place at the Algorand x402 hackathon, June 2026 — x402 being the open standard for agents paying per API call. Co-built with a software engineer; the dashboard and its dual-audience framing are mine.
AgentTab is a clearing layer for agent-to-agent payments. Rather than one on-chain transaction per call, agents sign cumulative off-chain vouchers backed by money in escrow; a backend accumulates them per channel, nets what two agents owe each other, and settles the net position on chain in batches. Ten calls between two agents cost zero transactions while they happen and one at redemption.
Two of us built it at the Algorand x402 hackathon in June 2026, where it took 2nd place. My part was the dashboard: I rebuilt it as a dual-audience surface, built the entry path for someone opening a tab for the first time, and wrote the language it speaks. It was also where I first worked with x402 — groundwork I used again a month later building ValidPay on my own.
The dashboard had two audiences, and I stopped trying to merge them:
- A person funding a tab needs to know what is running, what it is costing, and how to stop it.
- A developer in the same room needs the raw stream — intents, bundles, circuit state, escrow holds, events — with nothing translated.
- Both views read the same live event stream, so they cannot drift apart while the demo is running.
One toggle, two whole views
The header carries the decision: two buttons, one per audience, and the view switches whole rather than revealing extra panels. The person's board takes three columns — her tab and its protection on the left, the live payment flow in the middle, savings and an audit log on the right. The developer's view is the same data laid out as a monospace column grid: a stats bar, agent controls, the netting engine with its bundle threshold, settled bundles, circuit state per agent, escrow holds and the raw event log, under a Developer Mode header badged with the two sources it reads.
The middle column is the one that had to survive a glance from across a room. It is a running list of payments in which her own agent always sits on the left, whichever direction the money went, and the arrow does the explaining: pointing right when she is paying, pointing back at her when she is being paid. Underneath it, what is queued and not yet settled — a progress bar against the bundle threshold and a line stating whether it settles when the bundle fills or when the timer fires. Below that, settled bundles as receipts, each one a link out to the chain.
The hand on the tap
The protection card is the reason a person would leave agents running unattended at all. A three-way switch — relaxed, balanced, maximum — writes the circuit breaker's threshold straight into backend policy, and the line under it states the actual limit in requests per minute instead of restating the mode's name. When a breaker is open, that line says so, and the status strip at the foot of the screen flips the system's safety reading from its normal state to elevated.
The audit log is the same event stream the developer view prints raw, rewritten one sentence per event: a tripped breaker becomes blocked suspicious activity from a named agent, a settlement becomes an automated settlement completed. The only events coloured red are the ones where a payment was stopped — a trip, an escrow hold — so scanning the column shows refusals rather than volume.
One card names a control that was not built and says so on its face: a quality guard that would block and refund payments for unusable output, carrying a coming-soon badge next to the sentence describing it.
Translating a ledger into money
Vouchers carry no names. Payment identity is the payer's wallet address, which is what makes a voucher self-authenticating — and what makes the raw feed unreadable, since every row is a long string of characters. The human view resolves those addresses to agent labels through a registry the dashboard populates from the backend on boot; the developer view keeps the addresses exactly as they are.
Amounts get the same treatment. The ledger counts in base units at six decimals. The board prints money, and drops to four decimal places below a cent so a genuine micropayment reads as a number rather than as $0.00. Savings are labelled as what they are — an estimate derived from the count of on-chain transactions avoided — and sit next to the compression rate and the raw intents-to-bundles ratio that produced it, so the estimate can be checked against its own inputs.
The states before anything happens
Most of a live demo happens before the first payment lands, so the empty states carry the product. With no tab open, the screen is a single hero: open your agent tab, one button, and four claims in plain sentences — micropayments netted into one settlement, a circuit breaker that pauses a misbehaving agent, refunds on unusable output, one funded tab across many agents.
With a tab open but unfunded, the payment column does not sit blank. It says payments are paused because the tab is empty, explains that the agent cannot pay for services yet, and offers the top-up that resumes the flow. Every list beneath has its own resting line — waiting for your agents to start, no receipts yet, all clear and nothing to report — so a screen with no traffic still reads as a working system rather than a broken one.
The last pass was legibility. The primary blue was retuned for contrast against the dark ground, because the states that matter most on this screen — live, settled, safe — are the ones a room full of people reads from a distance.