Even before Solana’s congestion issues this spring, a number of notable projects had already transitioned to off-chain execution. These teams are building applications, not infrastructure--they’ve developed L2s and appchains to meet their own needs rather than as a product for others.
The independent adoption of various alternative blockspace solutions indicates that Solana mainnet isn't fully addressing the diverse demands of the ecosystem. Let's take a closer look at the different architectures that’ve emerged and the motivation behind this shift.
.png)
There are three main types of off-chain architectures, each with a different set of tradeoffs.
An appchain or SPE (Solana Permissioned Environment) is an independent network that runs Solana code but operates with its own security and trust assumptions. As the name suggests, SPEs have a restricted validator set, which provides a controlled environment.
Pyth, the oracle network, along with several tradFi and RWA projects all utilize SPEs to power their applications.
A rollup executes business logic off-chain but submits the relevant transactions and resulting state to Solana, which serves as the DA and settlement layer. This allows the rollup’s state to be challenged to prevent fraudulent behavior.
Projects like Grass, an AI data layer, and Zeta, a perps DEX, both leverage a rollup architecture. The rollup posts summaries of Grass’s datapoints and Zeta’s trades to Solana.
Similar to a rollup, a batcher consolidates transactions off-chain. But unlike a rollup, a batcher doesn’t submit the resulting summary on-chain but instead executes the net movements on Solana itself. Although execution occurs after a delay, the final state on L1 is eventually consistent with that of the batcher. This design anchors the source of truth and security to Solana directly.
Projects like Code, the P2P payments network, and Cube, the hybrid CEX/DEX, use a batcher to aggregate transactions off-chain then execute them on-chain so that a user's funds are always on the L1.
Let’s delve into the specific use cases that've been enabled by off-chain architecture.
The primary reason that various projects use L2s is for scalability. These teams prioritize speed, cost, and reliability over other potential benefits of an L2 such as customization and privacy.
For payments, Solana may experience dropped transactions and exceed block times of one second. However, payment platforms require the movement of money to be dependable and instant. Regarding micropayments in particular, Solana's gas fees may be non-trivial relative to the amount that's transferred. As an example, Code aims to serve micropayment use cases, such as when a user pays $0.75 to unlock a blog article. Its sequencer batches transactions off-chain and only executes the net movements on-chain to keep fees low and ensure a cost-effective experience.
In the realm of DEXs, high round-trip latency and gas fees negatively impact UX for both traders and market makers on decentralized exchanges. Some market makers on Zeta have reported paying 5-6 SOL per day on gas, which cuts into their profit margins. To address this, Zeta and Cube have adopted off-chain order matching to control costs and offer speeds that are competitive with CEXs.
Lastly for data, no L1 can handle the volume of transactions required for large-scale data operations, making off-chain solutions more efficient. For instance, Grass needs to achieve a throughput of millions of transactions per minute. With a dedicated L2 network, it now becomes economically and technically feasible to validate the provenance of every data point for AI model training.
Besides scalability, a number of teams are leveraging appchains and SPEs for a permissioned environment. Many are in tradFi, such as banking and fixed-income assets, which require a gated environment for privacy and regulatory compliance. These sectors need to ensure that only authorized participants can access their networks, and SPEs offer the controlled environment necessary to meet these stringent requirements.
Although not as common as scalability or permissions, a few projects are also using L2s for privacy. In particular, Code believes that payments should be private--by using the batcher design, they’re able to offer specific privacy guarantees to their customers. For example, their batching algorithm waits until approximately one out of ten payments have the same type before forwarding them to Solana and opens anonymous accounts on-chain on behalf of their users. This approach helps obscure individual transactions and makes it more difficult to trace a single payment to its source.
Although Solana lacks important infrastructure to support L2s, it’s interesting to note that this doesn’t affect many of the teams mentioned above.
Issues such as liquidity fragmentation and the absence of SVM wallet standards aren’t necessarily relevant because they don’t need to interoperate with other projects and instead operate independently. This is especially true for those in non-DeFi verticals, where synchronous composability between protocols is less crucial.
In addition, for specific DEXs, a L2 design may promote greater liquidity for the protocol. Zeta’s philosophy is that a rollup with CEX-like endpoints, minimal gas fees, and rapid confirmations can allow for tighter spreads and in turn encourage market makers to contribute greater liquidity to the network.
Alternative Solana blockspace solutions, such as L2s and SPEs, are driven by the need for speed, cost-efficiency, reliability, and permissioned settings. These solutions offer unique advantages and are being adopted by leading projects, indicating a potential trend for the future of the Solana ecosystem.
Termina is rapidly approaching devnet. Nitro Labs is looking for ambitious teams looking to deploy applications that are only possible on the SVM. Register for the Termina builder waitlist, hop in our Discord, and follow us on Twitter for updates on our progress, new initiatives, and the rapidly growing ecosystem.
