# State Channels & EIP-712

State channels are the settlement infrastructure of the OpenSeed network. They are the mechanism that makes the economics of per-request AI inference payments viable — that bridges the gap between the instant, zero-cost payment authorizations that the x402 protocol provides and the on-chain settlement that converts those authorizations into actual USDC transfers.

### Why State Channels Are Necessary

To understand why state channels are necessary, it helps to think about the alternative. Imagine settling every inference request on-chain at the moment it is served. A Buyer makes a request, the Seller serves it, and a Base Mainnet transaction transfers the USDC for that request from Buyer to Seller.

The problems with this approach are multiple and compounding. Each Base transaction, even at Layer 2 costs, carries a gas cost. Even if this cost is very small — fractions of a cent — it represents a fixed overhead that cannot be avoided regardless of the payment size. For a one-cent inference request, a fixed on-chain overhead is economically significant.

More fundamentally, the latency of on-chain settlement is incompatible with real-time inference. Even Base Mainnet, one of the fastest EVM networks, requires several seconds for a transaction to confirm with high confidence. An inference call that takes two hundred milliseconds to compute cannot be gated on a two-second blockchain confirmation for each request. The overhead would make the service unusable.

State channels solve both problems simultaneously. The setup cost — the ReserveAuth transaction — is paid once per channel. After that, all payment activity is off-chain, instant, and free. Settlement — the final on-chain transaction that converts accumulated authorizations to actual USDC — happens infrequently, amortizing the settlement cost across hundreds or thousands of individual requests.

### ReserveAuth: Establishing the Channel

A state channel on OpenSeed begins with a ReserveAuth transaction. This is an on-chain transaction submitted by the Buyer to the OpenSeed smart contract on Base Mainnet. Its function is to lock a specified amount of USDC in the smart contract as a committed budget for a specific Seller relationship.

The ReserveAuth transaction records three key pieces of information on-chain: the Buyer's wallet address, the Seller's wallet address, and the amount of USDC being locked. Once confirmed, this creates a payment channel — a bilateral agreement, enforced by the smart contract, that the locked USDC is available for the Seller to claim through the settlement process, subject to the rules of the channel.

From the Buyer's perspective, the ReserveAuth is a commitment of funds. The locked USDC is no longer freely transferable — it is reserved for this channel until the channel is closed, either through mutual agreement or through the channel's expiration timeout. The Buyer should lock an amount sufficient to cover their expected usage for the duration of the session, with some buffer. If the locked amount is consumed before the session ends, the Buyer can top up the channel with a new ReserveAuth transaction.

From the Seller's perspective, the ReserveAuth is a guarantee of payment capacity. Before the channel exists, the Seller must trust that the Buyer can and will pay. After the channel exists, the Seller can verify that the locked USDC exists in the smart contract and that valid SpendingAuths from this Buyer can be settled against it. The Seller's trust requirement is reduced from "I trust this Buyer to pay" to "I trust the smart contract to enforce payment" — a much stronger guarantee.

The gas cost of the ReserveAuth transaction is real but bounded. On Base Mainnet at current gas prices, this transaction costs a fraction of a cent. Even at higher gas conditions, the cost is negligible when amortized across the hundreds or thousands of requests a typical session involves. A developer who runs a session of one thousand inference requests pays the ReserveAuth cost once, then conducts all one thousand payment authorizations at zero marginal cost.

### SpendingAuth: The Per-Request Authorization

For every inference request served after the ReserveAuth is established, the Buyer generates a SpendingAuth. This is an EIP-712 typed data signature — described in detail in the x402 Protocol section — that authorizes the Seller to claim a specific cumulative amount from the Buyer's channel deposit.

The cumulative structure of SpendingAuths is an important design choice. Each SpendingAuth authorizes a total amount that includes all previous requests plus the current one. If the first request authorizes 0.001 USDC and the second request authorizes 0.0015 USDC, the second SpendingAuth specifies a total cumulative authorization of 0.0025 USDC — not an incremental 0.0015 USDC.

This cumulative structure simplifies settlement logic considerably. The Seller does not need to track every individual SpendingAuth from a Buyer to know their total entitlement — they need only the most recent SpendingAuth, which represents the maximum cumulative authorization. At settlement time, the Seller submits the highest-value valid SpendingAuth from each Buyer, and the smart contract releases the corresponding USDC.

It also provides a natural mechanism for handling lost or out-of-order messages. If the Seller fails to receive a SpendingAuth for a particular request, the next SpendingAuth they do receive will have a cumulative value that includes the missed request. The Seller's earned amount is preserved regardless of message delivery issues within the session.

SpendingAuths are generated locally by the Buyer's Internal EVM Signer. The generation process is computationally trivial — it requires only a standard ECDSA signature operation — and adds single-digit milliseconds to the request latency. For comparison, a typical inference request takes hundreds of milliseconds. The payment authorization overhead is genuinely negligible from the user experience perspective.

### Lazy Settlement: The Batching Advantage

Settlement is the process by which a Seller converts accumulated SpendingAuths into realized USDC. It is "lazy" in the sense that the Seller controls when it happens — there is no protocol-enforced settlement schedule or deadline beyond the expiration of individual SpendingAuth deadlines.

A Seller node continuously accumulates SpendingAuths as it serves requests. These accumulate in the node's local storage — a log of validated payment authorizations, each representing a Buyer's commitment to pay for a specific request. The total value of this accumulated log is the Seller's unrealized earnings — money that is cryptographically committed but not yet on-chain in the Seller's wallet.

At any point of the Seller's choosing, they can initiate a settlement transaction. This transaction submits the accumulated SpendingAuths — specifically, the highest-value valid SpendingAuth from each active channel — to the OpenSeed smart contract. The smart contract verifies each signature, checks the channel state, and releases the corresponding USDC from the locked deposits to the Seller's address.

The economics of settlement reward intelligent batching. The gas cost of a settlement transaction is largely fixed regardless of how many SpendingAuths are included — the marginal cost of adding another channel's settlement to the batch is very small. This means that a Seller who settles daily, accumulating a full day's earnings before submitting a single transaction, achieves dramatically lower per-request settlement costs than a Seller who settles after every request.

For a high-volume Seller serving thousands of requests per day, daily settlement might amortize to a settlement overhead of a hundredth of a cent per request. For a lower-volume Seller, weekly settlement achieves similar amortization. The Seller has full flexibility to optimize their settlement frequency according to their liquidity needs and gas cost tolerance.

### Channel Lifecycle Management

Payment channels in OpenSeed have a defined lifecycle beyond the basic open-and-settle flow described above. Understanding this lifecycle is important for operators who want to manage their payment infrastructure efficiently.

Channel opening is the ReserveAuth transaction. This establishes the channel with a specified locked USDC amount and a channel expiration time. Channels expire after a protocol-defined period — typically measured in days to weeks — after which any unclaimed SpendingAuths are no longer settleable and the remaining locked USDC can be reclaimed by the Buyer.

Channel topping-up is possible at any time during the channel's life. If a Buyer's locked balance is running low before the session ends, they can submit a new ReserveAuth that increases the locked amount without closing and reopening the channel. This is done smoothly and does not interrupt in-flight requests.

Channel closing happens either through explicit mutual close (both parties agree that the channel is done and the final balance is settled) or through expiration (the channel reaches its timeout and the smart contract handles final settlement automatically). Mutual close is generally preferable as it settles immediately. Expiration-based close requires waiting for the timeout and may be slightly less gas-efficient.

<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.openseed.gg/core-concepts/state-channels-and-eip-712.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.