Skip to content
LogoLogo
Blog

Friday, June 12, 2026

An improved sessions experience

Faster, cheaper billing and formally specified

Sessions are one of MPP's core primitives. They power the cost-efficient, high-throughput, usage-based billing that modern APIs and services depend on: metering payment at the granularity of a single LLM token, API call, or byte transferred.

Today we're shipping two improvements that make sessions the cheapest and easiest machine payments primitive to integrate:

  1. The session intent is now a formal spec. Sessions are standardized as an MPP intent (session), so extending them to new payment methods and networks is faster and more predictable.
  2. Sessions on Tempo are faster and cheaper. The new TIP-1034 precompile path cuts channel costs by as much as 72% and greatly improves reliability.

An overview of sessions

A session lets a client authorize spending once, then incrementally increase the authorized amount as it consumes a service, paying exactly for what it uses. Instead of one payment per request, the client and server maintain a single running authorization that grows with usage.

By keeping payment verification close to instant, sessions make metering at the granularity of a single LLM token, API call, or byte transferred practical and remove credit risk, reconciliation complexity, and complex billing workflows.

The HTTP shape is the same as every MPP flow: the server returns a 402 Challenge, the client answers with an authorization Credential, and the server returns a Receipt confirming payment.

Changes with the new session interface

A formal, cross-network intent

Sessions are now a formal MPP intent rather than a Tempo-only feature. The Tempo session IETF Specification defines the unidirectional channel and cumulative voucher model normatively, so the same developer experience can map onto different settlement layers well beyond blockchains.

Each payment method has different mechanics, but the model is shared: open a funded session, meter usage, top up if needed, and close with unused funds returned to the client.

A simpler SDK surface

To make sessions easier to integrate, we have simplified the SDK and made several improvements for common use-cases, including:

  • Automatic settlement lets the server settle accepted usage in the background. A server-owned settlementSchedule triggers settlement by spend amount, metered units, or elapsed time, so the hot path stays off-chain while usage accumulates. No manual settlement job is required.
  • Session resumption lets a client reuse an existing channel across restarts. Pass a sessionStore to persist channel hints, and the next session resumes from the stored channel and server snapshot instead of opening and funding a new one.

All of these changes are backwards compatible with the existing interface, so you and your clients can migrate gradually.

Performance and improvements

Moving the channel lifecycle onto the TIP-1034 reserve precompile makes session operations dramatically cheaper.

OperationLegacy Sessions (gas used)Improved sessions (gas used)Change
Open, existing reserve balance1,055,229294,425-72.1%
Open, first reserve balance1,302,429791,625-39.2%
Settle, existing payee balance312,037301,631-3.3%
Settle, new payee balance312,037559,871+79.4%
Top up existing channel53,72446,805-12.9%
Request close31,75230,123-5.1%
Close after settlement85,11862,913-26.1%

The new payee balance case costs more because it writes a fresh storage slot for the payee balance. That is a one-time cost for a new payee, not the steady-state settlement path.

In addition to lower costs, the new implementation makes channel operations payment-lane traffic on Tempo. Opens, top-ups, settlements, close requests, closes, and withdrawals get the same congestion treatment as payments. That matters because session settlement is not crowded out by other onchain activity during congestion, so providers can settle many channels while the network is busy.

How to integrate

On the server, use an account from the local account store and register tempo.session:

server.ts
import { resolveAccount } from 'mppx/cli'
import { Mppx, Store, tempo } from 'mppx/server'
 
const account = await resolveAccount('server')
 
const mppx = Mppx.create({
  methods: [
    tempo.session({
      account,
      currency: '0x20c0000000000000000000000000000000000000', // pathUSD on Tempo
      settlementSchedule: {
        amount: '10', // settle in the background after $10 of accepted usage
      },
      store: Store.memory(),
    }),
  ],
})
 
export async function handler(request: Request) {
  const result = await mppx.session({
    amount: '0.00001',
    unitType: 'llm_token',
  })(request)
 
  if (result.status === 402) return result.challenge
 
  return result.withReceipt(Response.json({ data: '...' }))
}

On the client, connect with the Tempo Accounts SDK, then register tempo.session with the connector client:

client.ts
import { Fetch, tempo } from 'mppx/client'
import { createConfig, http } from 'wagmi'
import { getConnectorClient } from 'wagmi/actions'
import { tempo as tempoChain } from 'wagmi/chains'
import { tempoWallet } from 'wagmi/connectors'
 
const config = createConfig({
  chains: [tempoChain],
  connectors: [tempoWallet()],
  transports: {
    [tempoChain.id]: http(),
  },
})
 
const fetch = Fetch.from({
  methods: [
    tempo.session({
      getClient: (parameters) => getConnectorClient(config, parameters),
      maxDeposit: '1',
    }),
  ],
})
 
const response = await fetch('https://openai.mpp.tempo.xyz/v1/responses')
console.log(response.status)

Learn more