Session lifecycle
The client-side session flow has four main actions:opento create the channel and sign the first vouchervoucherto increase the cumulative paid amounttopUpto add more depositcloseto finalize with a last voucher
1. Install the package
2. Create the client session method
deposit is the default human-readable token amount to escrow unless the server challenge provides suggestedDeposit.
3. Register the server session method
4. Request shape
Session requests can include:amountcurrencydecimalsunitType- optional
recipient - optional
channelId - optional
escrowContract - optional
suggestedDeposit - optional
minVoucherDelta
5. Operational guidance
- pick a
suggestedDepositthat supports several expected requests - settle when the open channel has accumulated enough value or when you need finality
- use
topUpinstead of reopening when the remaining deposit is too low - expect cumulative amounts, not independent per-request signatures
When to use session mode
Use session payments when:- your agent will call the same paid API repeatedly
- per-request on-chain overhead is too high
- you want the HTTP flow to stay fast after the initial channel open