We kicked off 2023 with a hackathon, and one of the experiments my team ran had a simple premise: take the Arbitrum rollup SDK and plug it into a Stacks Subnet. Rollups work brilliantly on Ethereum, and Stacks Subnets give us programmable app-specific chains anchored to Bitcoin, so the intersection of those two ideas could produce something worth building toward.
Part 1 of this series covered the fundamentals of rollups and compared Arbitrum’s approach with Optimistic rollups more broadly. This post is about what happened when that theory met code, when we tried to make rollups work on top of Stacks infrastructure, and what we found at that intersection.
It worked far better than we expected, and the implications go well beyond what we originally scoped for a hackathon project.
Stacks Subnets in Brief
Subnets are a scaling architecture that lets developers spin up purpose-built blockchains anchored to the Stacks layer, which itself settles to Bitcoin. They’re app-specific execution environments anchored to Bitcoin’s finality through Stacks, without every transaction needing to touch the main chain.
Different applications have different performance characteristics, and forcing every dApp to compete for the same block space on a single chain creates unnecessary trade-offs. A DeFi protocol needs fast finality and high throughput; a digital collectibles platform needs cheap storage and batch processing; a gaming application needs sub-second responses. Subnets let each of these run in an environment optimized for their specific needs, whilst still anchoring state to Stacks and ultimately to Bitcoin for security.
The piece that matters most from an engineering standpoint is execution environment flexibility. A Subnet doesn’t have to run Clarity, Stacks’ native smart contract language; it can run any VM the operator chooses to deploy. That property is exactly what made our hackathon experiment possible.
The Hackathon Experiment
Our hypothesis: the Arbitrum Nitro stack, which compiles down to WASM and provides a complete rollup execution environment, could serve as the VM layer for a Stacks Subnet. If it worked, developers could write Solidity contracts, use existing Ethereum tooling, and deploy on a chain that settles to Bitcoin through Stacks, combining Ethereum-compatible developer tooling with Bitcoin-anchored settlement.
The integration challenge came down to bridging two module boundaries. Stacks Subnets expose a well-defined interface for custom execution environments: a Subnet operator registers the chain with the Stacks L1, defines how state commitments flow between the Subnet and the parent chain, and implements the block production logic within the Subnet itself. The Arbitrum Nitro stack packages rollup execution into a modular architecture with clear boundaries between the sequencer, the state transition function, and the proof system. Making Nitro’s state transition outputs feed into the Subnet’s commitment scheme, and making the Subnet’s settlement layer serve as the data availability and dispute resolution backbone that Nitro expects from its L1, was the core engineering problem.
The Arbitrum SDK Surprise
The Arbitrum SDK worked with far less modification than we anticipated. Nitro’s architecture separates rollup logic from L1 settlement logic cleanly enough that swapping out the settlement layer required changes to a thin adapter layer rather than deep surgery on rollup internals.
The SDK’s modularity meant that existing tooling (Hardhat deployments, ethers.js interactions, Solidity contract libraries) all worked against our Subnet with minimal changes. A developer who’d built on Arbitrum One could redeploy their contracts on a Stacks-anchored Subnet and get Bitcoin settlement without rewriting anything.
The Arbitrum SDK’s modularity turned what we expected to be months of integration work into a hackathon project, and the developer experience carried over almost entirely intact.
From our perspective, developer experience is one of the biggest bottlenecks for ecosystem growth in blockchain. Ethereum has years of accumulated tooling, tutorials, libraries, and developer muscle memory, and any new chain that asks developers to learn a new language or abandon their tools faces a steep adoption battle. Plugging Nitro into a Stacks Subnet preserves the entire Ethereum developer experience whilst redirecting trust assumptions toward Bitcoin.
Three Paths Compared
Working hands-on with the Arbitrum stack on Stacks Subnets sharpened the comparison from Part 1.
Arbitrum on Ethereum settles rollup state to Ethereum L1, inheriting Ethereum’s security and paying Ethereum’s gas costs for data availability. The ecosystem is mature, the tooling is excellent, and the liquidity is deep. The trade-off is full dependence on Ethereum’s economic and governance model.
Optimistic rollups more broadly share Arbitrum’s general approach, posting transaction data to L1 and using fraud proofs for dispute resolution, but differ in implementation details around proof systems, challenge periods, and EVM compatibility. The comparison I drew in Part 1 between Arbitrum and Optimism’s approaches to fraud proofs and EVM equivalence applies here.
Stacks Subnets with Arbitrum offer a third path: the same rollup execution model with the same developer tooling, anchored to Bitcoin through Stacks instead of settling to Ethereum. The security model differs from Ethereum L2 security inheritance in important ways; Stacks anchors to Bitcoin’s finality and proof-of-work, but the trust assumptions flow through the Stacks layer rather than being enforced directly by Bitcoin’s consensus the way Ethereum rollups are enforced by Ethereum’s. The economic model differs as well, and the philosophical alignment of building on Bitcoin rather than alongside it appeals to a different set of builders and users.
Beyond philosophical alignment, there’s a concrete argument for Bitcoin settlement: Bitcoin’s proof-of-work provides the longest-running, most battle-tested finality guarantee in the industry. For applications where censorship resistance and long-term durability of settlement matter more than smart contract composability with DeFi liquidity, anchoring to Bitcoin through Stacks offers a distinct threat model. The trade-off is that you lose native access to Ethereum’s liquidity and contract ecosystem, so the choice depends on whether your application’s security requirements outweigh its need for Ethereum-native interoperability.
Arbitrum on Ethereum gives you the deepest liquidity and most mature ecosystem, Optimistic rollups give you EVM equivalence with minimal friction, and Subnets with Arbitrum trade that Ethereum-native liquidity for Bitcoin-anchored settlement whilst keeping Ethereum-compatible developer tooling intact. The right choice depends on what your application values most.
What This Unlocks
The hackathon proved a concept, but the implications extend well beyond a prototype.
First, with a thin adapter layer, Subnets can host execution environments from other ecosystems. Nitro doesn’t know it’s running on a Stacks Subnet; it sees a settlement layer that satisfies its interface. We demonstrated this data flow in the hackathon, albeit the adapter was held together with scripts and manual configuration. Productionizing it would require hardening the adapter, building robust bridge contracts, and defining a proper data availability scheme. The Subnet architecture is modular enough to host any execution environment that can be adapted to its commitment scheme, and the adapter layer is what makes that bridging possible.
Second, it opens a path for Ethereum-native projects to gain Bitcoin settlement without migration cost, in principle, once the adapter and dispute resolution layers mature. A project running on Arbitrum One today could deploy on a Stacks Subnet and settle to Bitcoin. Contracts, tooling, and developer workflow all carry over unchanged; only the trust assumptions shift. We proved the data flow works at the hackathon level, but the bridge contracts, operational tooling, and dispute resolution mechanisms needed for production use remain unbuilt.
Third, the rollup design space is far larger than the Ethereum ecosystem has explored so far. Rollups don’t have to settle to Ethereum. The rollup pattern of executing transactions off-chain and posting commitments on-chain is a general scaling strategy applicable to any base layer with sufficient security guarantees. Bitcoin, through Stacks, provides a highly secure base layer, and Subnets make it programmable enough to serve as a rollup settlement layer, albeit the security properties differ from Ethereum L2 rollups where the L1 directly enforces fraud proofs.
Looking Ahead
The core thesis held up under the pressure of a hackathon prototype: Arbitrum’s rollup execution model and Stacks Subnets’ settlement architecture are compatible, and the combination opens a path toward Ethereum-compatible developer tooling with Bitcoin-anchored settlement, mediated by a Subnet architecture flexible enough to host both. Whether this path leads to production-grade infrastructure depends on the maturity of the adapter layer, the dispute resolution design, and the broader Stacks ecosystem’s evolution.
Part 3 looks at how the Nakamoto upgrade changes the Subnets picture, what fast block times and improved finality mean for rollup settlement, and where this design space is headed. The foundation we laid in this hackathon is about to get a much more capable base layer to build on.