OP_NET Technical FAQ

Introduction

OP_NET is a smart contract execution layer built directly on Bitcoin Layer 1. This means no separate blockchain, no bridges, no locked funds, and no mirrored assets. When you interact with OP_NET, you're sending actual Bitcoin transactions that OP_NET nodes read and execute.

This challenges the usual way we think about Bitcoin scaling. OP_NET isn't a traditional Layer 2 that moves computation off-chain and settles disputes on Bitcoin. It's not a metaprotocol like Ordinals or Runes that relies on indexers interpreting Bitcoin data through social agreement. It's something fundamentally different: a consensus mechanism that uses Bitcoin's own immutability as its foundation to create a mathematically deterministic state.

The key innovation is fork-impossible consensus. Through time-delayed attestations and deterministic winner selection, OP_NET makes disagreement between honest nodes mathematically impossible rather than just unlikely. This isn't about having enough validators or honest majorities,it's about designing a system where the correct answer is provable through mathematics.

User Onboarding & Asset Flow

How are user assets spent by smart contracts on OP_NET?

They are Bitcoin transactions on Layer 1 interacting with OP_NET-specific scripts. Every smart contract interaction is a real Bitcoin transaction sent to a contract's SegWit address using Tapscript. The transaction contains the function call and parameters, which OP_NET nodes detect and execute.

How does a user transfer BTC on OP_NET?

To transfer native BTC, users simply send normal Bitcoin transactions. OP_NET doesn't change how Bitcoin works,it operates on top of regular Bitcoin transactions.

Architecture & Consensus

Is P2OP supported through a Bitcoin soft fork?

No. P2OP uses witness version 16 as an addressing scheme interpreted solely by OP_NET nodes, not by Bitcoin Core.

Why are OP_NET forks mathematically impossible?

OP_NET forks are mathematically impossible, not just unlikely, but actually impossible. Traditional blockchains can fork because they make decisions about events happening right now, where network latency and timing create ambiguity. OP_NET completely sidesteps this by never making decisions about the present.

When epoch 103 ends at block 519, miners compete to create the winning solution. But every valid solution must include an attestation about the state at the end of epoch 99 (block 499). By the time anyone can submit a solution, block 499 is already 21 blocks deep in Bitcoin's history.

For two nodes to disagree about epoch 103's winner, they would need to disagree about what happened at block 499. But at 21 blocks deep, every honest node has exactly the same view of block 499's contents and state. The historical reference point is so deeply buried that all nodes must agree on it.

How does OP_NET handle Bitcoin reorganizations?

While OP_NET's design makes internal forks impossible, it must handle Bitcoin reorgs. When Bitcoin reorganizes, OP_NET nodes detect the common ancestor block and revert to that state, then replay the new blocks in order. Since reorgs only affect recent epochs that haven't been finalized yet, no epoch winners need to be changed.

Decentralization & Security

How many validator nodes currently exist?

The system is permissionless,anyone can run a full node. There are bootstrap nodes that provide canonical state, but consensus comes from deterministic execution of Bitcoin data, not from validator voting.

OP_NET achieves a unique form of decentralization. The protocol doesn't require a minimum number of nodes because it achieves consensus through mathematical determinism rather than voting. Whether there's 1 node or 10,000 nodes, they will all independently arrive at the exact same state.

How does OP_NET prevent malicious behavior?

OP_NET doesn't have validators in the traditional sense and therefore doesn't need slashing mechanisms. Instead, it prevents malicious behavior through economic incentives and mathematical impossibility.

Epoch miners must invest computational resources to find SHA-1 collisions. If they submit invalid epochs (wrong state calculations or incorrect attestations), their submissions are simply rejected,they lose their computational investment with no reward.

How does OP_NET ensure overall network security?

OP_NET ensures security through multiple layered mechanisms that make attacks either mathematically impossible or economically irrational:

• SHA-1 proof-of-work mining combined with time-delayed attestations.
• Deterministic winner selection with no ambiguity.
• Three-epoch reward delay preventing manipulation.
• Security grows exponentially over time (attacking a week-old epoch costs over $1 billion).
• Leverages Bitcoin's immutability as its security foundation.

Transaction Finality

Is there a rollback mechanism for OP_NET transactions?

No. OP_NET transactions cannot be rolled back once they're included in Bitcoin blocks. Transaction finality occurs in stages:

• Immediate inclusion: When the Bitcoin block is mined.
• Computational finality: When the epoch processes (every ~50 minutes).
• Absolute finality: After 21 blocks (~3.5 hours) when the epoch attestation references that state.

After 21 blocks, the transaction is so deeply embedded in Bitcoin's history that reversing it would require reorganizing Bitcoin itself. The protocol grows stronger over time: after 100 blocks, reversal is economically irrational; after 1000 blocks, it's physically impossible.

Incentive Mechanism

Are validators rewarded?

OP_NET's incentive mechanism rewards epoch miners with transaction fees from future epochs. Specifically, miners receive all gas fees from transactions processed three epochs after their winning epoch (approximately 150 minutes later).

This delay serves multiple purposes:

• Ensures the winning epoch is deeply confirmed before rewards are distributed.
• Prevents miners from manipulating their own epoch for profit.
• Creates long-term investment in network health.

What is used to pay gas fees on OP_NET?

Native Bitcoin (BTC). No governance token exists, and none is needed.

Comparisons

How does OP_NET compare to Bitcoin Ordinals, Runes, and Alkanes?

OP_NET fundamentally differs by implementing actual consensus through proof-of-work mining rather than being an indexer that interprets Bitcoin data. While Ordinals/Runes/Alkanes are metaprotocols that rely on social agreement about which indexer to trust, OP_NET creates mathematically deterministic consensus where disagreement is impossible.

This architectural difference enables fundamentally different use cases: Ordinals focuses on NFTs, Runes on fungible tokens, and Alkanes attempts smart contracts but without consensus guarantees. OP_NET provides true smart contract functionality with deterministic finality suitable for DeFi applications like lending protocols, DEXs, and cross-chain bridges.

What are the "blocks" shown on Opscan?

The "blocks" aren't actually blocks in the traditional blockchain sense,they're visual representations of Bitcoin blocks that contain OP_NET transactions. When you see "block 871,234" on Opscan, you're looking at Bitcoin block 871,234, along with the decoded OP_NET transactions that occurred in this block.

Technical Details

How does the system handle large contracts?

Contract bytecode is stored in Bitcoin transactions using Tapscript and OP_PUSHDATA opcodes. Contracts use ZLIB compression to reduce size. The maximum contract size is 400kb. The bytecode goes directly into the witness data of the Bitcoin transaction.

What data is submitted to Bitcoin?

Everything is on Bitcoin Layer 1: full contract bytecode, all function calls, all parameters. OP_NET nodes read Bitcoin blocks and execute contracts based on what's written in those blocks. Users submit their own transactions directly to Bitcoin miners, just like normal Bitcoin transactions.

How is the data processing scope of each epoch defined?

Each epoch consists of exactly 5 consecutive Bitcoin blocks. The mapping formula is:

For example, Epoch 113 processes transactions from Bitcoin blocks 565-569.

Governance & Upgrades

Does OP_NET have a governance token?

No. There is no governance token.

How does OP_NET handle protocol upgrades?

OP_NET has upgrades planned post-mainnet (4x/first year, 2x/second year, 1x/year after second year). The protocol will use OP_NET Implementation Proposals (OIPs) similar to Bitcoin's BIPs and Ethereum's EIPs, handling upgrade consensus similarly to how Bitcoin handles upgrades with community consensus.