Disclosure: The views and opinions expressed here are solely those of the author and do not necessarily represent the views or opinions of crypto.news.
Every smart contract platform has a paid asset. For example, Ethereum (ETH) has ETH, Solana (SOL) has SOL, but with Bitcoin (BTC), but things get complicated. If you want expressive applications, you usually accept the economy of the second network.
Conclusion
- Bitcoin does not show a price calculation, it just closes the space. Unlike Ethereum or Solana, the BTC fee market is built around sat/vB for transaction input rather than smart contract performance measurement.
- Execution can come off-chain, while settlement remains in Bitcoin. Systems like OpNet run the contract logic in the Wasm VM, while anchoring payments and final state changes via normal BTC transactions.
- BTC can function as a gas asset without a new token. By pricing performance costs in satoshis and regulating transactions through Bitcoin transactions, apps avoid creating a secondary payment economy.
In Stacks, for example, you pay in STX. In Bitcoin-style EVM layers, you might be told that BTC is a gas token, but it’s typically a native L2 representation with EVM-like conventions (including 18 decimal), and you’re still working within that L2 environment. Bitcoin itself, at the moment, already has a pure fee market where users bid for block space in sat/vB and miners prefer higher payment rates.
With this in mind, what if the smart contract interaction was initiated and paid for as a normal Bitcoin transaction, with payments in BTC terms (no additional gas tokens or forks), while the smart part works elsewhere and is potentially tied to Bitcoin? OpNet is determined to respond.
Bitcoin doesn’t count (that’s the problem)
The Bitcoin fee market excels at one thing: the pricing block space. You compete on sat/vB, miners choose the highest stakes, and the network remains simple and robust against adversaries. What Bitcoin does not do is provide a general purpose execution environment where the chain can scale and pay for arbitrary computation. Bitcoin script is intentionally stateless and not Turing complete, specifically no loops or gotos, so any node can validate scripts as expected without opening the door to unlimited accounts.
Therefore, most Bitcoin smart contract approaches perform execution on a separate system that can calculate and manage its own currency market. Once you have this separate layer of execution, it usually comes with a separate payment asset (eg Stacks on STX charge a fee).
It’s not ideal, and a system where you can keep the payment in the original Bitcoin fee market while transferring performance elsewhere is preferable.
Performance is not what Bitcoin is supposed to do
Once you accept that Bitcoin Script is intentionally limited (stateless and not designed for unlimited computation), you think about how Bitcoin handles results and payments.
In fact, the execution can take place in a special virtual machine built to execute the logic of the smart contract in a certain way, while Bitcoin remains the main layer that shows the time, orders and exchange prices through its existing payment market. In the OpNet design, the contract logic is evaluated by Wasm-oriented VM (OP-VM), while a wider node stack is built to manage and execute smart contracts using existing Bitcoin transactions and UTXO mechanics.
Most importantly, it is not associated with a new payment asset. Bitcoin doesn’t need to calculate to be gas money. It should be the final layer of settlement to which everything is ultimately paid and anchored.
What a paid BTC contract call looks like
Our interaction model follows a simulation-then-spend flow instead of a traditional form of smart contract execution, with the final execution step taking place as an actual Bitcoin transaction. First, your program calls the contract method in simulation mode. This request goes through the provider to the OPNet node, which executes the contract in its VM and returns a Bitcoin CallResult (including gas/payment bills) without pushing anything.
If the call is a variable state, you get that CallResult and send it as an execution. At this point, the library creates a Bitcoin transaction, signs it, and broadcasts it to the Bitcoin network. There are two points to keep in mind:
- Miner fees are Bitcoin-native. You select feeRate in sat/vB, optionally add priorityFee in sats, and set the maximum spend via maximumAllowedSatToSpend (the parameter is actually called maximumAllowedSatToSpend).
- The target of the contract is expressed as a P2OP contract address. The contract instance exposes its p2op address format, and transactions refer to “p2op contract address” as the contract destination.
Meanwhile, OpNet’s own computational metering is still there. But it’s priced in satoshis (assuming SATS Gas, refunds in SATS, etc.), so the unit never enters the separate token economy.
Less stress, more motivation
Users no longer have to accept a second economy just to interact with apps. In Bitcoin, fees are already an auction of block space, priced per byte and paid to miners. When contract calls are just Bitcoin transactions, you’re back on familiar ground (with sat/vB fees, mempool crunch and miner incentives), without having to explore a separate gas market.
Also, the tool relies on standard Bitcoin workflows such as UTXO processing, provider connections and even offline/cold signing. Contracts live in the Wasm runtime and are written in AssemblyScript, which aims to express similar persistence without pretending Bitcoin Script has suddenly turned into a VM.
Bitcoin as gas, without a second token
The claim that BTC can’t work like gas is usually based on the assumption that the underlying layer has to do the calculations to price it. Bitcoin does not count; it closes the gap and solves the value.
The solution is to allow the virtual machine to define performance and then each state variable interaction through a standard Bitcoin transaction, where payments are expressed in familiar terms like sat/vB and capped in satoshis. In our case, this is implemented at the client level through parameters such as feeRate and maximumAllowedSatToSpend.
So maybe BTC-as-gas is really plausible. End-to-end payments remain native in BTC, while the contract execution time remains based on WebAssembly (AssemblyScript → Wasm), which represents the logic without changing the fee currency.
