Therm credits

Therms are issued as a standard ERC-20 token, Therm Credit (THERM), with 18 decimals. One whole token is one therm, which is 100,000 gas. There is nothing exotic about the token contract: it implements transfer, approve, transferFrom and EIP-2612 permit, and it can be held by any address, EOA or contract.

Minting and burning are restricted. Only the pool can mint, and only when a pass is purchased. Only the paymaster can burn, and only in postOp for gas actually consumed.

Properties#

Transferable#

You can send therms to anyone. A trader can fund a second wallet, a desk can distribute gas to its operators, and a protocol can move therms into a sponsorship policy. The receiving address can spend them through the paymaster immediately, subject to its own hourly cap.

Because the token is fungible, the locked rate does not travel with it. The rate is a fact about what the original buyer paid, recorded in their pass. A therm always pays for 100,000 gas regardless of who holds it or what anyone paid for it, so for the recipient the rate is irrelevant: the therm is simply gas.

Non-refundable#

There is no function that returns USDG for therms, and there will not be one. This is a design decision, not an oversight.

If therms were redeemable, the pool would be offering a free option. Holders would redeem whenever the base fee fell below their locked rate and keep their therms whenever it rose above it. The pool would be left holding only the losing side of every position, which it cannot price or survive. Non-refundability is what lets the pool offer a fixed rate at all.

Buy what you expect to use. If you over-buy, your options are to keep the therms, which do not expire, or to transfer or sell them to someone else. Therm does not operate a secondary market and makes no promise that one will exist.

No expiry#

Therms carry no timestamp and no decay. A therm bought today will pay for 100,000 gas in five years, provided the paymaster is operating and the pool is solvent. The pool's pricing assumes therms may be held indefinitely, which is part of why coverage is measured against the full outstanding supply.

Composability notes for integrators#

Treat therms as gas, not money. Displaying a therm balance in USD is misleading, because its value depends on the future base fee. Display it in therms, and optionally as an estimate of transactions covered at a typical gas cost.

Balances decrease without a transfer from the user. The paymaster burns therms in postOp, emitting a standard Transfer to the zero address. Indexers that assume balances only fall when the holder signs a transfer will be wrong.

Reserved therms are not locked. During validation the paymaster reserves therms for the in-flight operation, but it does this in its own accounting, not by moving tokens. A user can, in principle, transfer therms away between validation and execution; the paymaster handles this by burning whatever remains up to the actual cost and flagging the shortfall against the address's future sponsorship. Do not build logic that relies on a reservation being visible in balanceOf.

Contracts can hold and spend therms. A smart account that holds therms can use the paymaster exactly like a user. A protocol can hold therms in a vault and allocate them to a sponsorship policy with fundPolicy, after which they are spent on behalf of that protocol's users. See Integrate.

Do not use therms as collateral without a haircut. They cannot be redeemed, so their liquidation value is whatever a buyer will pay, and during a spike, when gas is most valuable, sponsorship is also the most likely to be constrained by the pool's circuit breaker.

Permit works. permit lets a user approve a protocol to pull therms with a signature instead of a transaction, which pairs naturally with sponsored flows where the user holds no ETH.