Spending therms

The ERC-4337 paymaster flow, which transactions are sponsored, and the hourly throughput cap.

Therms are spent by the Therm paymaster, an ERC-4337 (opens in a new tab) paymaster deployed against the canonical EntryPoint on Robinhood Chain. You never send therms anywhere to pay for gas. The paymaster pays the network in ETH from the pool and burns the matching therms from your balance.

The flow#

text

  YOUR ACCOUNT            BUNDLER              ENTRYPOINT             THERM PAYMASTER          THERM POOL
  (smart account)
       │                     │                     │                         │                      │
  1    │── sign UserOp ─────▶│                     │                         │                      │
       │   paymaster = Therm │                     │                         │                      │
  2    │                     │── handleOps ───────▶│                         │                      │
  3    │                     │                     │── validatePaymaster ───▶│ balance ≥ max gas?   │
       │                     │                     │   UserOp                │ under hourly cap?    │
       │                     │                     │                         │ target allowlisted?  │
       │                     │                     │◀──── ok + context ──────│ reserve therms       │
  4    │◀──────────────────── execute your call ───│                         │                      │
  5    │                     │                     │── postOp(actualGas) ───▶│ burn actual therms   │
       │                     │                     │                         │ release the rest     │
  6    │                     │                     │                         │── draw ETH ─────────▶│
       │                     │◀── gas refund ──────│◀── deposit debited ─────│   pay base fee       │

Step by step:

Your wallet builds a user operation for the call you want to make and names the Therm paymaster in paymasterAndData.
A bundler picks up the operation and submits it to the EntryPoint.
The EntryPoint calls validatePaymasterUserOp. The paymaster checks your therm balance against the operation's maximum gas, checks the hourly cap, checks the target against the allowlist, and reserves enough therms to cover the worst case.
Your call executes. Whether it succeeds or reverts, gas has been used and must be paid.
The EntryPoint calls postOp with the actual gas used. The paymaster burns exactly that many therms, plus a fixed 35,000 gas overhead for its own validation and accounting, and releases the rest of the reservation.
The paymaster's EntryPoint deposit pays the bundler in ETH, and the pool tops the deposit back up.

Gas used on Robinhood Chain includes the L1 data component, which Arbitrum-based chains charge as additional L2 gas. It is covered like any other gas and burns therms at the same rate.

What is sponsored#

The paymaster only sponsors operations it can reason about. The allowlist is public and changes only through the timelock.

Transaction	Sponsored	Notes
Stock-token swaps on allowlisted DEX routers	Yes	Single and multi-hop.
Limit order placement and cancellation	Yes	On allowlisted order-book contracts.
USDG transfers	Yes	Standard ERC-20 `transfer` and `transferFrom`.
Token approvals	Yes	`approve` and `permit` on allowlisted tokens.
Therm protocol calls	Yes	Buying passes, staking, claiming.
Arbitrary contract calls	No	Anything off the allowlist.
Contract deployments	No	`initCode` is sponsored only for first-time smart-account creation.
Operations above 2,000,000 gas	No	The per-operation ceiling.
Protocol-sponsored calls	By policy	A sponsoring protocol sets its own targets and caps.

If the paymaster declines, nothing is burned. Most wallets then offer to send the same transaction with you paying gas in ETH.

The hourly throughput cap#

Each address can burn at most 50 therms per rolling hour through the paymaster. That is 5,000,000 gas, enough for about fifteen stock-token swaps an hour, which is well above what an individual trading by hand will use.

Why it exists#

The cap closes the most direct way to drain the pool. Without it, the strategy is obvious:

Buy a very large balance of therms during a calm period, when the rate is close to the floor.
Wait for a spike.
Burn the entire balance in minutes, on high-gas activity chosen precisely because gas is expensive — arbitrage loops, liquidations, spam — so that every therm is redeemed at the moment it costs the pool the most.

Each therm burned during a spike costs the pool far more ETH than it was sold for. Concentrated burning turns that into a transfer from the pool, and ultimately from stakers, to whoever can burn fastest. Ordinary users who happen to transact during a spike are exactly who Therm is for; a single actor redeeming a stockpile against the pool in one burst is not.

The cap bounds that. A holder can still use every therm they bought, at the rate they locked, but only at a pace that looks like usage rather than redemption. Spikes are usually short; a balance that can only drain at 50 therms an hour cannot extract much from one.

What the cap does not do#

It is per address, so a determined actor can split a balance across many addresses. Two further controls address that: the pool-wide circuit breaker, which pauses sponsorship for operations above a network-wide hourly burn budget, and the quote curve, which makes the stockpiling step more expensive as coverage falls. The cap is one layer, not the whole defence.

Protocol sponsorship policies have their own caps, set by the sponsoring protocol, and do not count against the burning user's personal limit.