Every smart contract platform has a fee asset baked in. For example, Ethereum (ETH) has ETH, Solana (SOL) has SOL, but with Bitcoin (BTC), however, things get messy. If you want expressive apps, you usually end up adopting a second network’s economics. 

On Stacks, for example, you pay fees in STX. On EVM-style Bitcoin layers, you might be told that BTC is the gas token, but it’s typically an L2-native representation with EVM-like conventions (including 18 decimals), and you’re still operating inside that L2 environment. Bitcoin itself, meanwhile, already has a clean fee market, where users bid for block space in sat/vB, and miners prioritize higher fee rates.

With this in mind, what if a smart contract interaction could be initiated and paid for as a normal Bitcoin transaction, with fees in BTC terms (no extra gas token or fork) while the smart part runs elsewhere and stays provably tied back to Bitcoin? OpNet is setting out to provide an answer. 

Bitcoin doesn’t meter compute (that’s a problem)

Bitcoin’s fee market is excellent at one thing: pricing block space. You compete in sat/vB, miners pick the highest fee rates, and the network stays simple and adversarially robust. What Bitcoin does not do is run a general-purpose execution environment where the chain can measure and charge for arbitrary computation. Bitcoin Script is deliberately stateless and not Turing-complete, specifically lacking loops or gotos, so every node can validate scripts predictably without opening the door to unbounded computation.

That’s why most Bitcoin smart contract approaches end up placing execution on a separate system that can meter compute and run a fee market of its own. Once you have that separate execution layer, it usually comes with a separate fee asset (Stacks, for instance, charges fees in STX).

This isn’t ideal, and a system where you could keep payment within Bitcoin’s native fee market while moving execution elsewhere would be preferable.

Execution isn’t what Bitcoin needs to do

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

Indeed, execution can happen in a dedicated virtual machine that’s built to run smart contract logic deterministically, while Bitcoin remains the base layer that timestamps, orders, and prices the interactions through its existing fee market.  In OpNet’s design, contract logic is evaluated by a Wasm-oriented VM (OP-VM), while the broader node stack is explicitly built to manage and execute smart contracts using Bitcoin’s existing transaction and UTXO mechanics.

Crucially, this isn’t paired with a new fee asset. Bitcoin doesn’t need to meter computation to be the gas currency. It needs to be the final settlement layer that everything ultimately pays into and anchors to.

What a BTC-paid contract call looks like

Our interaction model follows a simulate-then-spend flow rather than a conventional smart contract execution pattern, with the final execution step taking place as an actual Bitcoin transaction. First, your app calls a contract method in simulation mode. That request goes through a provider to an OPNet node, which executes the contract in its VM and returns a CallResult (including gas/fee estimates) without broadcasting anything to Bitcoin.

If the call is state-changing, you take that CallResult and send it as an execution. At this point, the library builds a Bitcoin transaction, signs it, and broadcasts it to the Bitcoin network. Two points are worth remembering:

• Miner fees are Bitcoin-native. You choose a feeRate in sat/vB, optionally add a priorityFee in sats, and set a hard cap on fee spending via maximumAllowedSatToSpend (the parameter is literally named maximumAllowedSatToSpend).
• The contract target is expressed as a P2OP-style contract address. The contract instance exposes its p2op address format, and transactions reference a “p2op contract address” as the contract destination.

Meanwhile, OpNet’s own compute metering still exists. But it’s priced in satoshis (estimated SATS Gas, refunds in SATS, etc.), so the unit never drifts into a separate token economy. 

Less friction, cleaner incentives

Users no longer have to adopt a second fee economy just to interact with apps. On Bitcoin, fees are already an auction for 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 churn, and miner incentives), without having to learn a separate gas token market.

Also, the tooling leans into standard Bitcoin workflows such as UTXO handling, provider connections, and even offline/cold signing. Contracts live in a Wasm runtime and are written in AssemblyScript, aiming for Solidity-like expressiveness without pretending Bitcoin Script suddenly became a VM.

Bitcoin as gas, without a second token

The claim that BTC cannot function as gas usually rests on the assumption that the base layer must meter computation to price it. Bitcoin does not meter computation; it meters block space and settles value. 

The solution is to let a virtual machine handle execution deterministically, and then route every state-changing interaction through a standard Bitcoin transaction, where fees are expressed in familiar terms such as sat/vB and capped in satoshis. In our case, this is implemented at the client level through parameters like feeRate and maximumAllowedSatToSpend.

So maybe BTC-as-gas is truly plausible. Fees stay BTC-native from end to end, while the contract runtime stays WebAssembly-based (AssemblyScript → Wasm), which keeps the logic expressive without changing the fee currency.