# Payments ideas for Livepeer 2.0 — borrowing from The Graph (TAP/GraphTally, Indexing Payments) + x402

1

Payments ideas for Livepeer 2.0 — borrowing from The Graph (TAP/GraphTally, Indexing Payments) + x402

Disclaimer up front: I’m not heavily involved in the Livepeer ecosystem I spend most of my time in The Graph. I watched the Livepeer 2.0 direction with interest because the problems it’s solving (agentic demand, heterogeneous work verification, tying token value to fees) overlap heavily with problems The Graph has been working through for the last two years. These are just suggestions from an outsider’s seat. Take it or leave it.

1. Per-job payments: consider a receipt/voucher model over lottery tickets

Livepeer’s probabilistic micropayments were designed for continuous transcoding streams. They work in expectation, but small orchestrators eat real variance — you can serve work and hit no winning tickets.

Agentic workloads are the opposite shape: one-off, heterogeneous jobs (“generate this clip,” “train this LoRA”). That’s exactly where variance hurts and deterministic per-job accounting matters.

The Graph replaced its old payment system with GraphTally / TAP (Timeline Aggregation Protocol):

  • Every request carries a signed receipt
  • Receipts aggregate off-chain into a Receipt Aggregate Voucher (RAV)
  • The receiver redeems the RAV on-chain against a pre-funded escrow — one transaction settles thousands of micro-jobs
  • Trust-minimized in both directions: the payer can’t skip payment (escrow), the receiver can’t overclaim (signatures)

Two properties seem directly relevant to Livepeer 2.0:

  1. The “payment clearinghouse” concept maps 1:1 to TAP escrow. A clearinghouse funds escrow per orchestrator; agents spend against it; orchestrators redeem RAVs.
  2. Your new validator set needs “observable behavior” to score nodes 0–1. Signed receipts of work performed are a far more legible audit trail than ticket-redemption statistics. Exact fee amounts per redemption also make BME burn accounting clean, no lottery variance noise in the burn input.

Links:

2. The cold-start problem: consider an Indexing Payments analog

Per-job fees alone won’t convince anyone to keep a niche model warm on a GPU waiting for jobs that may never arrive. The deck acknowledges this (“Agent not hindered by what’s hot on network GPUs”) but the incentive design doesn’t obviously solve it.

The Graph hit the identical problem: indexing a chain has a large fixed upfront cost before a single query fee arrives. The answer is Indexing Payments (GIP-0081, formerly “DIPs”) standing agreements where a gateway pays indexers directly to guarantee availability of a specific dataset, separate from per-query fees. GIP-0087/0088 are now bringing those agreements on-chain and funding them partly from protocol issuance.

The Livepeer translation:

  • Per-job lane (TAP-style) pay for inference actually served
  • Availability lane (Indexing Payments-style) gateways/Foundation/demand-side deals pay orchestrators to keep capability X loaded with an SLA (model warm, N GPUs reserved, latency bound)

This also gives a concrete answer to one of your open questions “What is the role of delegation in helping to activate new nodes?” Delegation can back availability agreements as collateral rather than existing purely as passive reward-farming, which is essentially how The Graph’s Horizon upgrade reframes it.

Links:

3. x402 as the agent-facing rail

The deck mentions a payments clearinghouse and “USD based pricing” for gateways but never names a demand-side rail. Worth a serious look at x402 the HTTP 402-based payment standard (originated by Coinbase, now an open ecosystem, live on Base and other chains):

  • Agent hits an endpoint → gets a 402 challenge with price → signs a USDC payment → retries → served. No accounts, no API keys, no prepaid deposits.
  • It’s already the emerging standard for agent-to-service payments, which matters if the strategy is “Livepeer Agent loads into Claude/Codex.” Agents that already speak x402 can pay Livepeer with zero integration work.
  • It composes with the above rather than replacing it: x402 at the edge (agent → gateway/clearinghouse, USDC), TAP-style receipts internally (gateway → orchestrator settlement). The USDC fee flow then feeds BME directly — a clean, auditable input to the buy-and-burn.
  • Gateways get a real business model out of it: accept x402 from any agent, handle network-side settlement, take a spread. That’s the “payments abstraction / clearinghouse” role the stakeholder slide gestures at, made concrete.

Links:

Summary

Problem in Livepeer 2.0 Prior art What carries over
Per-job micropayments for one-off agent jobs GraphTally/TAP (GIP-0054) Signed receipts → RAVs → escrow redemption; deterministic earnings; audit trail for validators; clean BME accounting
Keeping capabilities warm without demand yet Indexing Payments (GIP-0081/0087/0088) Standing availability agreements alongside per-job fees; gives delegation a productive role
Demand-side rail for agents x402 Zero-friction USDC payments from any agent harness; feeds BME; gives gateways a clearinghouse business

None of this is a criticism of the PM system, it’s served the transcoding era well. But the 2.0 workload shape is different, and there’s now battle-tested, open-source prior art (TAP has been processing the majority of Graph query traffic since 2024) that seems worth evaluating before building a new payments layer from scratch.

1 Like
2

Thank you @Paulieb for writing this analysis. I’ve found the same gap while scoping x402 implementation for the Livepeer Payment Clearinghouse project, which is an abstraction above the Livepeer PM tickets protocol.

To describe the x402 integrator problem another way - deposit/reserve requirements for gateways are a blocker because x402 is normally used to pay per request, while Livepeer PM TicketBroker contract currently requires a significant amount of ETH for deposit and reserve locked in the smart contract (using your own wallet presumably), before you can start a job on the network.

Alternatively, a customer/agent looking to perform compute on the network can use a hosted gateway or remote signing service like the Payment Clearinghouse.

Livepeer Gateway users should be able to pay for a single job, settling payment for it without locking funds into a contract for an entire round.

For context, the Payment Clearinghouse project is using OpenMeter to track usage - Graph Protocol could help serve a more decentralized role in tracking usage events.

My suggested approach to solve this is to implement x402 on top of a remote signer that already has a reserve and small deposit on-chain. HTTP 402 statuses are returned by the clearinghouse’s balance gate: when the user’s authenticated request to start a new job session returns insufficient balance, the response can include payment instructions. A balance webhook like offered by TurnKey helps connect the web3 deposits to HTTP requests to apply credits to an OpenMeter customer account.

Much of this could be abstracted into smart contract or an improvement to the TicketBroker contract, (it sounds like that is what you’re exploring), but I just wanted to chime in here and share how I have been thinking of x402 interactions for Livepeer applications.

The Indexing Payments mechanism you mentioned looks interesting. This might be useful for automating some of the Burn-Mint-Equilibrium mechanisms proposed in the Livepeer 2.0 solution.

From what I can tell, the GraphTally solution appears to be nearly identical to PM Tickets protocol, without deposit and reserve requirements. So for our network it feels like a heavy lift / replacing something we already have.

Good discussion, thank you for bringing this up!

1 Like
3

PM is definitely a beast, but pretty much every aspect of it is there for a reason. The deposit / reserve requirements might seem onerous at first glance, but it has a couple of of nice properties:

  • Minimizes counterparty risk - it serves the same purpose as escrow in most other payment protocols
  • Avoids needing to pre-fund an escrow account per orchestrator which would be untenable with more than a few orchestrators on the network

The second point seems to rule out TAP escrow per orchestrator.

As noted, the clearinghouse allows for separating customer payments from network payments. Customer payments can be via any method. Someone build a barter clearinghouse please. Network payments could definitely use some improvements. But it’s a uniquely constrained design space, and most general-purpose payment protocols don’t quite fit without tradeoffs. We should fully understand and articulate those tradeoffs + benefits before going all-in on any one scheme. But we can still learn from others and incorporate their ideas into ours, eg the RAV mechanism seems interesting.

Thanks for sharing.

2 Likes
4

Someone build a barter clearinghouse please.

Here’s my shameless plug for pymthouse.com, built to serve businesses building websites and apps on Livepeer :grinning_face: Anyone can create a platform app and start streaming instantly. All builders get $5/month of free usage to try the Livepeer network. Payment processing is still on testnet, and the system does not bill real charges yet (sandbox mode, pending legal review).

Thinking about PM tickets deposit/reserve - there might be a special use case for distributed compute jobs that benefit from escrow requirements. If such a job type exists, it could differentiate our network from others. First that comes to mind is expensive, long-running jobs that require more than one node to process at a time with an unknown final cost, like model training.

1 Like