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 · Ed25519 · Solana
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 amount and a dispute window. The program creates a small channel account and holds the deposit in it. This is the only part the payer pays rent for, and it is refunded when the channel closes.
Keep scrolling. It goes sideways.
channel account146 bytes
- payer
- ...
- payee
- ...
- deposit
- 2 USDC
- window
- 1 day
- rent
- 0.0019 SOL, refunded
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 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 program checks the signature against the payer's address 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.
0USDC to the payee
2USDC 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, ~0.4 s each
one channel
-
in network fees
2 transactions, one signature per payment
Base fee only, 5 000 lamports per signature. Priority fees would make the on-chain side worse. The channel account's rent (about 0.0019 SOL) is refunded when it closes.
What is under it
A ticket is just a signature.
The payer signs 61 bytes with the same Ed25519 key as their Solana wallet. The program checks that signature with Solana's native Ed25519 verifier, then pays out the amount in it.
one ticket, signed
// 61 bytes, signed by the payer domain HUMMINGBIRD01 // 13 bytes channel 32 bytes // which channel amount u64 // total owed so far seq u64 // 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 program interfaceread the spec
open(payee, deposit, window) // payer signs: creates the channel, locks the deposit settle(ticket) // payee: checks the signature, pays amount, refunds the rest request_close() // payer alone: starts the dispute window finalize() // anyone, after the window: refunds the payer if no ticket came cooperative_close(final_amount) // payee: close at an agreed amount, no waiting
146bytes in the channel account
12rule tests that pass
0admin keys, by design
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 authority.
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.
FAQ
The honest answers.
Are the tickets on this page real?
Yes. Your browser creates fresh Ed25519 keys, opens a simulated channel and signs 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 the program refunds the whole deposit.
Do I need $HUM?
No. The program 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 Solana: address to be announced. It will be posted here and on the project's X first. Token page.