State Channels, Round Two. // Aayush Giri

ERC-7824 was opened as a pull request on November 22, 2024 and posted to Ethereum Magicians on January 17, 2025. It is a chain-agnostic standard for state channel interfaces. Author is Louis Bellet, co-founder of Yellow Network. The reference implementation is Nitrolite. Yellow is deploying it as the clearing layer of a real crypto settlement business, with the YELLOW token generation event on March 8, 2026.

State channels are not new. Poon and Dryja's Lightning Network paper came in January 2016. Raiden has been on Ethereum in some form since 2017. Nitro Protocol came out of the Magmo / ConsenSys line between 2019 and 2023 and is the direct ancestor of what ships now.

What is new is a chain-agnostic standard, a production deployment whose business model forces the protocol to work, and the start of a tooling layer between raw protocol and shippable app. I am going to argue the third piece is the one that matters for 2026.

What a State Channel Actually Is

A state channel is a smart contract holding collateral for two or more parties, plus a rule for resolving the latest state those parties co-signed. Updates happen off-chain. The chain sees one open and one close. If the parties disagree, the chain adjudicates on the highest-versioned co-signed state.

Two parties deposit into a custody contract. They run a counter off-chain: balances, game state, trade P&L, whatever the application needs. Every update is versioned and signed by both sides. Either party can post the latest version at any time. Post a stale one and the other party has a dispute window to publish something newer.

Three-stage diagram of a state channel. On-chain opening with Alice and Bob each depositing 100 USDC into a custody contract. Off-chain state updates co-signed by both parties, versioned. On-chain settlement at close using the final co-signed state. — On-chain open, off-chain co-signed updates, on-chain close. The chain sees the ends, not the middle.

01Both parties must sign every update. If one side refuses, the other closes the channel at the last state everyone did agree to.
02Updates carry versions. The contract enforces the highest-versioned co-signed state either party can produce. Old states cannot be revived.
03Disputes have windows. The chain waits before finalizing, giving the honest party time to publish something newer if they have it.

Jeff Coleman coined the term in 2015. Lightning was the first production deployment, payments on Bitcoin. Raiden ported the pattern to Ethereum in 2017. Nitro and the Magmo line generalized from balance-only payments to arbitrary state machines. Nitrolite picks up that thread.

State Channels vs. Rollups

Rollups scale the case where everyone is doing a little. State channels scale the case where a few parties are doing a lot.

A rollup gives you a shared execution environment. Permissionless entry. Global state. Settlement amortized across the chain's traffic. A state channel gives you a private execution environment scoped to the parties that opened it. Instant finality between them. Zero gas per interaction. Locked capital for the duration. Fixed counterparty set until close.

Channels and rollups get framed as competing L2 narratives. They are not. They compose. Open liquidity on a rollup. High-frequency session on top of that liquidity in a channel. Most of the historical confusion came from trying to use one primitive for the other's workload.

Yellow Network and the Clearing Insight

Yellow Network is the first production deployment willing to bet a real business on state channels. Legal entity is Layer3 FinTech Ltd. Chairman is Alexis Sirkia, co-founder of GSR, one of the largest crypto market makers; he exited GSR in 2025. Chief architect is Louis Bellet, the ERC-7824 author. Seed round was $10M led by Chris Larsen of Ripple, plus $1M+ through a Reg D sale on Republic.

The design move that separates Yellow from earlier channel networks is that it clears P&L, not principal. Lightning and Raiden move balances. Every payment updates locked principal. Which means every participant needs capital proportional to their throughput. Yellow moves P&L between brokers instead. Two brokerage firms open a channel with stablecoin collateral. Their clients trade through them at sub-second speeds. Net P&L between the brokers hits chain only when the channel closes.

This is how prime brokerage has worked for fifty years. Nobody wires money every time a client places a trade. A clearinghouse nets positions and settles on an interval. Yellow is applying that in crypto, with a state channel standing in for a DTCC. Channel primitives have existed for almost a decade. What is new is somebody running a crypto clearing business as a clearing business rather than another DEX.

Yellow's stack has three layers. A Custody contract holds collateral and adjudicates disputes. A margin-call protocol updates collateral state over RPC as positions move. A matching engine sits at the application layer. The off-chain nodes are called ClearNodes. Brokers operate them. Users get a unified balance across chains without having to bridge funds for every trade.

ERC-7824

The status is still Draft. PR opened November 22, 2024. Magicians thread landed January 17, 2025. Dedicated site launched February 2025. First Nitrolite SDK alpha on npm April 2, 2025. Draft is the right status for a standard still being proved in production.

The interface is what the spec specifies. Channel open, update, close, dispute. The message format for co-signed state transitions. The state machine the application runs inside the channel, the transport, and the dispute-watching logic on the client are all deliberately out of scope. The portability you get is this: a channel opened by one implementation can be adjudicated by another, and custody contracts work across EVM chains.

Nitrolite

Nitrolite is the reference implementation of ERC-7824. The repo describes itself as a simplified version of Nitro for prototyping state-channel applications. Solidity custody contracts. TypeScript SDK. Go client. ClearNode server. An interactive REPL called Cerebro. The TypeScript SDK first landed on npm on April 2, 2025 as @erc7824/nitrolite, shipped through 0.x up to 0.5.3 in December 2025, and migrated to @yellow-org/sdk on March 2, 2026, with v1.2.0 shipping on YELLOW TGE day (March 8). A @yellow-org/sdk-compat package exists as a migration layer. Repo is under the erc7824 and layer-3 GitHub orgs.

The v1 client gives you typed channel-lifecycle methods on a unified client. deposit(chainId, asset, amount). transfer(wallet, asset, amount). checkpoint(asset) for on-chain settlement. challenge(state) for raising disputes. closeHomeChannel(asset). acknowledge(asset) for incoming states. State advancements are validated on the client: StateAdvancerV1 throws on version mismatch, asset mismatch, or malformed transitions before a proposed state leaves the process. Typed events flow through a Listener interface for the full channel lifecycle.

Three pieces it intentionally leaves to the app layer. That is the right call for a reference SDK. Every product will want these solved a little differently. I built on top with an actual application in mind and ended up solving the same three each time.

01Dispute response is manual, by design. The client exposes challenge() and emits HomeChannelChallengedEvent; the app decides when and how to watch, reconstruct the latest co-signed state, and submit before the window closes. This lets each product pick its own reliability model.
02Channel-state persistence is app-side. ClientAssetStore caches asset metadata, and channel state across browser refresh or process restart is wired up per app: which storage backend, what TTL, what recovery semantics. That is a choice, not an oversight.
03No framework bindings, and that is the right call for a framework-agnostic SDK. Transport initialization, hydration, and SSR are each project's problem to solve for its own stack.

Protocols ship. SDKs ship. What defines the next year is the opinionated layer above, the one that makes shipping an app on state channels feel like shipping on anything else.

The Tooling Gap

Every protocol goes through the same phase after it ships. Ethereum had it until ethers and then viem matured. Rollups had it until Conduit, Caldera, and similar tooling showed up. State channels are in exactly that phase now. The primitives are there. The spec is there. The v1 SDK is there. What the next round of work is about is the opinionated layer above: the piece that lets a product team ship without also having to become a state-channel library author.

I started NitroGuard against Nitrolite 0.5.x with a list of five things an app would need on top. When the v1 release landed in March, Yellow had solved two of those five at the SDK layer (state-transition validation and a typed client), and that is exactly the right layer for them. The three that remain are app-shaped: a dispute watcher plus ClearNode silence monitor that auto-submits the latest co-signed state when a challenge lands, channel-state persistence across browser refresh with pluggable storage adapters, and React and Next.js bindings that survive SSR. NitroGuard also adds a channel-lifecycle FSM above Nitrolite's state-advancement validation, so open, send, close, and withdraw can only be called from valid source phases. Version 0.1.1 is on npm as nitroguard. Repo is at github.com/Giri-Aayush/nitroguard.

The channel-lifecycle state machine is the piece I care about most. Nitrolite v1 validates individual state transitions; NitroGuard sits above that and validates which method you can even call from which lifecycle phase. Every public method maps to a valid transition in the FSM below. Call the wrong method in the wrong phase and you get an InvalidTransitionError at the call site instead of a channel that corrupts quietly and blows up three operations later.

nitroguard channel state machine

VOID        ->  INITIAL       # open(): deposit confirmed on chain
INITIAL     ->  ACTIVE        # both parties co-signed the opening state
ACTIVE      <-> DISPUTE       # either party can raise; window starts
DISPUTE     ->  FINAL         # highest co-signed version wins
FINAL       ->  VOID          # withdraw(): settled on chain

# Any public method called outside its valid source state
# throws InvalidTransitionError synchronously. No silent corruption.

The framing I use for NitroGuard is the same framing wagmi has against raw ethers, or React Query against raw fetch. It does not replace the protocol library. It lives on top, doing the three app-layer pieces each team would otherwise re-solve. If a different team ships a better tooling layer next quarter, the protocol wins either way.

Where State Channels Win (And Where They Do Not)

The fit is any interaction that looks like a session. Bounded counterparty set. High frequency within the session. Natural netting at session end. Trading between two brokers clearing P&L is the canonical case. A four-player racing game where every move is a signed state update and only the final ranking hits chain is another. TurboWheel at ETHIstanbul 2025 was an early proof point. Pay-per-token AI inference, where each call is a signed update and the chain sees a weekly settlement, is a third.

01High-frequency trading where brokers net P&L on an interval
02Multi-party game matches where session length is bounded and only the final state settles on chain
03Pay-per-action AI inference metered per token and settled weekly or daily
04Streaming payments and payroll
05Subscriptions and metered APIs priced per call rather than per month
06Prediction markets with sub-second position updates between a small set of counterparties

The limits matter as much as the fit. Channels require counterparties to stay online, or to delegate to a node that stays online for them. They require collateral locked for the duration of the session, which is wrong for one-off payments. They grow quadratically in a fully-connected interaction graph, which is wrong for the open-DEX model where everyone transacts with everyone. A channel is the right primitive for a session between a few parties. It is the wrong primitive for an open market.

What to Watch in 2026

Four things worth tracking this year. YELLOW TGE on March 8, 2026 is the first real economic test of Nitrolite in a production clearing business, and the fact Yellow is running the network on their own protocol is the kind of skin-in-the-game I want to see more of. Yellow is funding a $50K grant program and $22K+ hackathons to seed third-party apps; whichever vertical produces the first breakout (trading, gaming, AI billing) shapes where the app-layer tooling investment goes next. Other projects picking up ERC-7824 alongside Yellow is the moment the spec grows past its first adopter into a shared primitive across teams. And the app-layer tooling above the SDK is about to be contested; NitroGuard is one attempt, others will ship, and the protocol wins either way.

01March 8, 2026. YELLOW TGE and the first economic test of Nitrolite in production clearing.
02Grant-funded apps on Nitrolite across trading, gaming, and AI billing through 2026.
03Other teams picking up ERC-7824 alongside Yellow's reference implementation.
04A tooling layer that closes the protocol-to-application gap. NitroGuard is one attempt; others will ship.

How the Pieces Fit

The layer between a user clicking and a transaction settling on a chain has been missing for a decade. Call it the session layer. It is starting to exist because the standard is open, the production deployment has a business reason to make it work, and the tooling between protocol and application is beginning to show up.

State channels as an idea are not the story. Three pieces landing in the same year is the story: the standard in draft, the production deployment live, and the app-layer tooling beginning to show up. Yellow has done the first two with a discipline most protocols never get. What the rest of us build on top defines the third.

State Channels, Round Two.