Solving Bitcoin’s gas issue (without a fork)
Every major smart contract platform has a built-in fee asset: Ethereum uses ETH, Solana uses SOL, and that native token doubles as “gas” to pay for computation. Bitcoin, by contrast, was never designed with a general-purpose execution layer in mind, which is why things get complicated the moment you try to build expressive applications on top of it.
Instead of a unified “BTC gas” model, most current approaches rely on parallel economies. On Stacks you pay in STX. On EVM-like Bitcoin layers you might be told that BTC is the gas token, but what you actually use is an L2-wrapped representation of BTC, usually with EVM-style conventions (such as 18 decimal places). You end up living in that L2’s economic system, not in Bitcoin’s native one.
Meanwhile, Bitcoin itself already runs a very clean, efficient fee market. Users compete to get into blocks by bidding satoshis per virtual byte (sat/vB). Miners simply prioritize transactions with the highest fee rates. This market is simple, adversarially robust, and tightly aligned with what Bitcoin cares about most: block space, not arbitrary computation.
The question, then, is whether you can have the best of both worlds: keep smart contract execution off-chain or on a separate layer, yet still initiate, meter, and settle everything directly in Bitcoin’s existing fee market, paid in BTC, without forking the protocol or inventing a new gas token. That is exactly the class of solution that systems like OpNet are pursuing.
Bitcoin’s design: great at fees, limited at compute
Bitcoin’s architecture makes one thing crystal clear: it is not supposed to be a world computer. Bitcoin Script is intentionally constrained. It is stateless, not Turing-complete, and purposefully excludes constructs like loops or gotos. This keeps validation straightforward and predictable; every node can verify a transaction without worrying about unbounded computation or runaway execution.
That design choice has huge implications. Because the base layer cannot meter arbitrary compute, it cannot natively charge for CPU time, storage, or complex state transitions the way Ethereum does. It only prices one resource directly: block space. You pay for how many bytes your transaction consumes, not for how many operations your code runs.
Most Bitcoin “smart contract” solutions therefore push computation onto another layer that can track and meter execution. Once that layer exists, it typically needs its own internal gas unit and its own fee market. That is how you end up with separate fee tokens such as STX, or with wrapped BTC assets that obey a totally different set of rules than the main chain.
Why a second fee token is a problem
Splitting execution from settlement isn’t inherently bad; modular architectures are powerful. The problem arises when the execution layer drags along its own fee currency. Users have to maintain balances in multiple tokens, juggle exchange rates, and navigate different liquidity conditions just to interact with applications “on Bitcoin.”
Developers inherit that complexity. Pricing models get opaque: a user might pay one fee in an L2 token to execute a contract, and another fee in BTC to eventually settle results on-chain. Incentives for validators or sequencers on that secondary layer can drift away from the incentives of Bitcoin miners. Over time, the system behaves more like a completely separate network loosely connected to Bitcoin, rather than an extension of Bitcoin’s own economic design.
A more elegant approach would preserve Bitcoin’s native fee market as the main pricing layer, even if the heavy lifting of execution happens elsewhere. Users would still pay in BTC. Miners would still earn BTC. And the economic logic of block space auctions – sat/vB – would remain at the heart of the system.
Rethinking “gas”: Bitcoin as settlement, VM as executor
Once you accept that Bitcoin Script is supposed to remain small and predictable, the natural next step is to move full smart contract logic into an external virtual machine (VM), while using Bitcoin only for ordering, timestamping, and final settlement.
In such a design, the VM is responsible for deterministically executing contract code, tracking state, and metering resource usage. But crucially, it does not introduce a new currency. Instead, all computation is conceptually priced in satoshis, and the final, authoritative payments happen directly on the Bitcoin base layer.
OpNet illustrates this model with a Wasm-centric VM called OP-VM. Contracts run in this environment, written in languages like AssemblyScript that can deliver Solidity-like expressiveness without pretending that Bitcoin Script itself has become a fully featured VM. Around this execution engine is a node stack designed specifically to handle smart contracts while remaining fully aligned with Bitcoin’s UTXO and transaction mechanics.
The key insight: Bitcoin doesn’t need to track every CPU cycle to serve as “gas.” It just needs to be the place where value is ultimately settled and where the cost of interacting with the network is denominated. The metering can happen off-chain; the pricing and payment can remain on-chain in BTC.
From “execute-on-chain” to “simulate-then-spend”
The interaction model looks very different from traditional smart contract platforms. Instead of sending a transaction directly to a contract and letting the chain execute it, you follow a simulate-then-spend flow.
1. Your application first calls a contract method in simulation mode.
2. This request is forwarded to an OPNet node, which runs the contract logic inside its VM.
3. The node returns a CallResult containing the outcome of the call and an estimate of the required fees, expressed in satoshis.
4. At this stage, nothing has touched the Bitcoin blockchain. You have simply obtained a deterministic “dry run” of the action.
If you decide to proceed with a state-changing operation, your client library turns that CallResult into a real Bitcoin transaction. You sign it with your standard Bitcoin keys and broadcast it to the network. Miners then treat this transaction just like any other: they include it or ignore it based on its sat/vB fee.
The last step – the actual commit – is thus a native Bitcoin transaction. It consumes and creates UTXOs. It pays miners directly in BTC. The “smart” part of the process, including compute metering, has already been resolved off-chain, but the settlement, ordering, and fee payment all happen on the main chain.
Compute metering in sats, not in a new token
Even though execution runs in a separate VM, OpNet still needs to meter compute: how much gas a call uses, how much storage it touches, and so on. The difference is that this metering is denominated in satoshis from the start.
The system estimates required “SATS Gas,” issues refunds in SATS when overestimates occur, and expresses all costs in the same unit that miners already care about. There is no floating side-token with its own speculative dynamics. The execution economy remains pegged to Bitcoin’s monetary unit and its fee environment.
The practical effect is to erase the cognitive and operational overhead of dealing with multiple fee assets. Users only need BTC. They can understand costs in terms of sat/vB and total sats per operation. Developers can design pricing models and UX flows that plug seamlessly into Bitcoin wallets and infrastructure.
Aligning incentives: miners, users, and developers
By anchoring contract calls as native Bitcoin transactions, the economic incentives of all participants remain tightly aligned with the base chain.
– Miners are paid in BTC and compete to include the most fee-dense transactions, as always.
– Users pay one type of fee, in one currency, for access to block space, whether they are making simple transfers or invoking complex contracts.
– Developers can rely on the predictability of Bitcoin’s fee market rather than on the volatility of a new token economy that might or might not gain traction.
This alignment matters especially in periods of high demand. When block space becomes scarce, the same auction mechanism that governs ordinary transactions also governs contract-related transactions. There’s no hidden secondary market or parallel congestion dynamic; everything converges on the single fee market that Bitcoin has always used.
Tooling that feels like Bitcoin, not a foreign L2
The developer experience in this model intentionally mirrors established Bitcoin workflows. You still deal with UTXOs, transaction construction, and standard signing practices. You still connect through providers that speak Bitcoin-oriented protocols. You can even integrate offline or cold-signing setups, because the final transaction is just a standard Bitcoin transaction with additional semantics the VM layer understands.
The contract environment itself lives inside a Wasm runtime. AssemblyScript and similar languages offer a familiar, high-level way to write logic, but all of that stays off-chain. Bitcoin Script is not being twisted or extended into a general-purpose VM. Instead, it remains what it does best: a constrained, verifiable language that defines spending conditions for UTXOs.
For teams that have already invested in Bitcoin infrastructure, this is critical. They don’t have to reorient around an entirely separate stack that behaves like Ethereum or Solana. They can extend their existing Bitcoin toolchains upward into smart contract territory while staying rooted in the same transaction model.
Why “BTC can’t be gas” is a misleading claim
The argument that “BTC cannot function as gas” usually assumes that the base layer itself must meter and charge for every unit of computation, like Ethereum does. Under that assumption, Bitcoin’s limited scripting capabilities and lack of a built-in gas meter make it unsuitable.
But that is a narrow definition of gas. If you instead define gas as the asset in which you ultimately pay for access to the system’s core resource – in Bitcoin’s case, block space and settlement – then BTC is perfectly capable of being the gas currency. You just separate the concerns:
– The VM layer measures resource usage and expresses it as a cost in satoshis.
– The user pays that cost inside a transaction that competes in Bitcoin’s fee market.
– Miners enforce the economic reality by including transactions that compensate them appropriately.
In this framing, Bitcoin’s role is to be the final arbiter of cost, ordering, and settlement. It does not need to introspect every instruction in the smart contract; it only needs to anchor the result and enforce the fee auction that underpins security.
Practical implications for scaling Bitcoin applications
This approach has several concrete benefits for the broader Bitcoin ecosystem:
1. Simpler user onboarding
New users don’t need to manage unfamiliar tokens just to try a dapp. If they already hold BTC, they already hold the gas asset. Wallets can present a unified balance and a single fee slider, instead of juggling token lists and bridging flows.
2. Reduced fragmentation
Today, “Bitcoin apps” often live on islands: one on Stacks, another on a specific sidechain, others buried inside wrapped-asset environments. Each comes with its own fee logic. A Bitcoin-native gas model consolidates at least the economic layer, even if execution remains modular.
3. Compatibility with existing infrastructure
Exchanges, custodians, and payment processors are set up for BTC, not for dozens of niche fee tokens. A design that keeps BTC at the center makes institutional integration far more straightforward.
4. Smoother regulatory and accounting treatment
Organizations that already track BTC on their books don’t necessarily want to add more volatile tokens just to interact with smart contracts. Paying fees in BTC simplifies both compliance and internal accounting.
5. Stronger narrative coherence
Bitcoin’s story has always been about a single, scarce digital asset that underpins the system. Letting that same asset serve as the universal fee currency for advanced applications preserves the narrative integrity that has made Bitcoin resilient.
Limitations and trade-offs
A Bitcoin-native gas model with external execution isn’t magic. It comes with trade-offs that need to be understood:
– Trust assumptions in the execution layer
While settlement is anchored to Bitcoin, the correctness of contract execution depends on the VM network’s security model. Different implementations will handle this with varying degrees of decentralization, verification, and fraud-proofing.
– Latency and UX complexity
The simulate-then-spend flow adds steps to the user journey. Tools and abstractions have to make those steps feel seamless, so users don’t get lost between simulation results and on-chain confirmation.
– Fee volatility
Because everything ultimately competes in Bitcoin’s fee market, application usage is exposed directly to BTC fee spikes. That is a feature in terms of alignment, but it can make UX more challenging during congested periods.
– No escape from Bitcoin’s script limits on-chain
The base layer remains intentionally constrained. Any on-chain logic still has to fit Bitcoin Script’s boundaries. The power comes from off-chain VMs, not from extending Script itself.
These constraints are not flaws; they are deliberate consequences of choosing to respect Bitcoin’s original design while expanding its capabilities.
The bigger picture: modular Bitcoin without a fork
What emerges is a modular vision of Bitcoin: the base layer retains its conservative design, focused on sound money and robust settlement, while specialized execution environments handle the complexity of smart contracts. Instead of forking Bitcoin to turn it into something it was never meant to be, you wrap richer logic around it and let BTC serve as the universal fee primitive.
Users interact with applications that feel as expressive as those on other chains, yet they pay with BTC, broadcast standard Bitcoin transactions, and rely on the same mempool dynamics and miner incentives that have governed the network for years. Developers gain an execution canvas without abandoning the economic and security foundations that make Bitcoin distinct.
In that sense, “solving Bitcoin’s gas issue” is less about bolting a gas meter onto the base protocol and more about reframing what gas actually is. When computation is metered off-chain but priced and settled in Bitcoin’s native fee market, BTC itself becomes the gas – without forking the chain, minting a new token, or diluting the core design that has kept Bitcoin secure and predictable.