Solving the Bitcoin gas problem (without a fork)

Every smart contract platform has a payment asset baked into it. For example, Ethereum (ETH) has ETH, Solana (SOL) has SOL, but with Bitcoin (BTC), however, things get messy. If you want specific applications, you usually end up using secondary network economics.

In Stacks, for example, you pay fees in STX. In EVM-style Bitcoin layers, you might be told that BTC is a gas token, but it usually represents L2 with the same principles as EVM (including 18 decimal places), and you’re still working in that L2 environment. Bitcoin itself, meanwhile, already has a pure currency market, where users bid for a block in sat/vB, and miners bid for higher coin prices.

With this in mind, what if a smart contract transaction could be initiated and paid for like a normal Bitcoin transaction, with payments in BTC terms (no additional gas token or fork) while the smart part works elsewhere and remains tied to Bitcoin? OpNet is preparing to provide an answer.

Bitcoin doesn’t meter (that’s the problem)

The Bitcoin market currency is very good at one thing: a place to set prices. You compete in sat/vB, miners choose high prices, and the network remains simple and robust against opposition. What Bitcoin does not do is use a general purpose environment where the chain can measure and charge illegal computations. Bitcoin Script is intentionally stateless and incomplete, it has no loops or gotos, so everywhere can validate scripts predictably without opening the door to unlimited calculations.

That’s why many Bitcoin smart contract methods end up putting the work into a separate system that can calculate meters and run a standalone currency market. Once you have that separate execution layer, it usually comes with a separate payment property (Stacks, for example, fee payments on STX).

This is not ideal, and a system where you can keep the payment within the Bitcoin currency market while moving the transaction elsewhere would be better.

Execution is not what Bitcoin needs to do

Once you accept that Bitcoin Script is intentionally limited (it is stateless and not designed for unlimited calculations), you start thinking about how to make Bitcoin settle results and payments.

Indeed, the execution can take place on a dedicated virtual machine designed to use the smart contract logic decidedly, while Bitcoin remains the basic layer of time stamps, orders, and transaction prices through its existing payment market. In OpNet’s architecture, the contract logic is tested by a Wasm-centric VM (OP-VM), while the extensive node stack is specifically designed to manage and execute smart contracts using existing Bitcoin transactions and UTXO hardware.

Importantly, this is not associated with a new payment asset. Bitcoin does not need to be metered to be a gas currency. It needs to be the last layer where everything finally pays off and sticks to it.

What does a BTC paid contract call look like

Our interaction model follows a flow that is simulated and then discarded rather than the traditional pattern of executing a smart contract, the final execution step occurring as a real Bitcoin transaction. First, your application calls the contract method in simulation mode. That request goes through the provider to the OPNet environment, which executes the contract in its VM and returns a CallResult (including gas/cash rates) without broadcasting anything in Bitcoin.

When the call changes state, you take the CallResult and send it as a grain. At this point, the library creates the Bitcoin transaction, signs it, and broadcasts it to the Bitcoin network. Two points to remember:

• Miners’ fees are Bitcoin-native. You select a charge in sat/vB, optionally add a value of Sats, and set a hard limit on spending using maximumAllowedSatToSpend (the parameter is literally named maximumAllowedSatToSpend).
• The target of the contract is expressed as a P2OP-style contract address. The contract instance exposes the p2op address format, and the transaction refers to the “p2op contract address” as the contract location.

Meanwhile, OpNet’s compute metering is still available. But it has a value of satoshis (SATS gas rate, SATS cashback, etc.), so the unit never drifts to a different token economy.

Less conflict, cleaner motives

Users no longer have to use the secondary payment economy just to interact with apps. In Bitcoin, fees are already auctions of block space, priced per byte and paid to miners. If contract calls are simply Bitcoin transactions, you’re back to familiar territory (with sat/vB fees, mempool churn, and miner incentives), without having to learn a different gas token market.

Also, the tool relies on standard Bitcoin functionality such as UTXO management, provider connections, and even offline/cold signing. Contracts live in the Wasm runtime and are written in AssemblyScript, intended for Solidity-like exposure without pretending Bitcoin Script has suddenly become a VM.

Bitcoin as gas, without a secondary token

The claim that BTC cannot function as gas is often based on the assumption that the underlying layer must be measured in meters in order to have a price. Bitcoin does not include a meter; blocks space and resolves value.

The solution is to let the virtual machine handle the execution by decision, then move all transactions that change the state through a normal Bitcoin transaction, where the payments are expressed in standard terms like sat/vB and put in satoshis. In our case, this is implemented at the client level with parameters such as feeRate and maximumAllowedSatToSpend.

So maybe BTC-as-gas really makes sense. Payments are always BTC native end-to-end, while the contract runtime is always based on WebAssembly (AssemblyScript → Wasm), which keeps the logic clear without changing the payment currency.