AI agents
An agent that pays a few thousandths of a cent per API call, data point or inference. One channel per service, thousands of calls, and no one waits for the chain.
Payment channels · EIP-712 · Robinhood Chain
Pay a thousand times.
Settle once.
Move your cursor. The bird follows, and every sip is a real ticket.
on-chain
OPENSETTLEEXIT
1 tx
Open
One transaction locks the deposit.
The payer picks a payee, an asset (ETH or any ERC-20), an amount and a dispute window. The contract records the channel and holds the deposit. The only cost is the gas of this one transaction.
Keep scrolling. It goes sideways.
channel record4 storage slots
- payer
- ...
- payee
- ...
- asset
- ETH
- deposit
- 0.02 ETH
- window
- 1 day
- cost
- gas, once
Pay
Every payment is a signature.
"I owe you this much in total." The newest ticket replaces the last. No fee, no wait, no transaction. These are real EIP-712 tickets, signed and checked by your browser as you scroll.
Payer-
off-chain tickets
Payee-
Signing a thousand tickets, one second...
Settle
The payee sends the last ticket.
The contract recovers the signer from the signature, checks it is the payer, and pays out exactly what it says. The rest of the deposit goes back to the payer, and the channel closes. Whatever the number of payments, that is transaction number two.
0ETH to the payee
0.0200ETH back to the payer
ticket #1000
Leave
Nobody gets trapped.
If the payee vanishes, the payer asks to close and a window starts. The payee can still settle inside it. If nobody comes, the whole deposit returns to the payer when the window ends. The payer cannot cheat the payee, and the payee cannot take more than was signed.
payer asks to closewindow: payee can still settlerefund
day 0: the payer asks to close.
What it saves
Drag the number of payments.
one transaction each
-
in network fees
- transactions, each one waits for a block
one channel
-
in network fees
2 transactions, one signature per payment, no waiting
Execution gas only, at the price read from the chain: 0.020 gwei (last value seen). One ETH transfer is 21,000 gas, about -. Opening a channel is about - gas and settling about -. Gas here is already tiny, so the gain is not magic: it is one settlement instead of thousands, no block to wait for, and payments that can be smaller than their own fee.
What is under it
A ticket is just a signature.
The payer signs a typed message (EIP-712) with the same secp256k1 key as their Ethereum wallet. The contract recovers the signer with ecrecover, then pays out the amount in it.
one ticket, signed
// EIP-712 typed data, signed by the payer (65 bytes) domain Hummingbird v1, chain 4663, the contract channel bytes32 // which channel amount uint256 // total owed so far seq uint64 // goes up every ticket
- Each ticket replaces the last. The payee only ever needs the newest one.
- The amount can only grow. A lower amount or an old seq is refused.
- The payee cannot take more than the payer signed, or than the deposit.
the contract interfaceread the spec
open(payee, token, deposit, window, nonce) // payer: locks the deposit, ETH or any ERC-20 settle(id, amount, seq, signature) // payee: recovers the signer, pays amount, refunds the rest requestClose(id) // payer alone: starts the dispute window finalize(id) // anyone, after the window: refunds the payer if no ticket came cooperativeClose(id, amount, payeeSignature) // a payee-signed final amount: close at once, no waiting
62,000gas to settle, measured
29tests that pass, on a real EVM
0admin keys, by design
Status: written, compiled and tested, not audited, not deployed. Its address is already fixed by the compiled bytecode (CREATE2, salt 0): -
Who it is for
Anything too small for a transaction.
Pay-per-use APIs
Charge by the request without sign-ups, invoices or card fees. The caller signs, the server verifies in well under a millisecond and answers.
Streams and games
Pay by the second of video, the minute of compute or the move in a game, and settle once the session is over.
Safety
Nobody can take more than you signed.
What the design guarantees
- The payee can only receive what the payer signed, and never more than the deposit.
- A payer who tries to leave early cannot cheat: the payee has the whole dispute window (1 hour to 30 days) to submit the newest ticket.
- Old tickets are useless: only a higher amount with a higher seq counts, and the rules check both.
- If the payee disappears, the payer gets the full deposit back after the window.
- No owner, no admin, no fee, no upgrade. A transfer that fails (a contract that refuses ETH, a blocked token holder) never blocks the other side.
Things you should know
- The payee has to watch. If the payer asks to close, the payee must settle inside the window or lose the unsettled tickets.
- The deposit is locked in the channel until it closes. Size it for what you will really spend.
- One payee per channel. To pay many services, open many channels.
- Tickets only prove what was owed. They do not prove the service was delivered.
- Not audited and not deployed. Nothing here holds funds today. Treat the contract as unreviewed until it is audited.
- Payers are normal wallets (EOAs): smart-contract wallets cannot sign these tickets. Fee-on-transfer tokens are not supported.
FAQ
The honest answers.
Are the tickets on this page real?
Yes. Your browser creates fresh secp256k1 keys, opens a simulated channel and signs EIP-712 tickets with the same code the tests run, for every sip in the garden and every step of the scroll. No funds exist and nothing is sent anywhere.
What if the payer stops paying?
The payee settles the newest ticket and is paid what was signed. Nothing is lost beyond the next unsigned payment, which is why services usually ask for the next ticket before the next response.
What if the payee disappears?
The payer asks to close. After the dispute window anyone can finalize and the contract refunds the whole deposit.
Is it live?
No. The contract is written, compiled and tested on an in-process EVM (29 tests), but it is not audited and not deployed. The read-only checks against Robinhood Chain confirm it: there is no code at its future address yet. Nothing on this site sends a transaction.
Do I need $HUM?
No. The contract has no token and no fee. See the $HUM page.
Why not just batch the payments?
Batching still needs the payer to be online and the payee to wait. A ticket is paid the moment it is signed, from a phone, a script or an agent, with no transaction in the loop.
Drink a little, often.
Open a channel in the playground, pay it as many times as you like and settle it. No wallet, no signing prompt, nothing to install.
$HUMCommunity coin on Robinhood Chain: address to be announced. It will be posted here and on the project's X first. Token page.