Introduction to P2OP (Pay-to-OP_NET)

Overview

P2OP (Pay-to-OP_NET) is the native address format for smart contracts on OP_NET, Bitcoin's first consensus layer. Unlike metaprotocols that rely on indexers interpreting data (where different indexers can show different balances), OP_NET provides cryptographic proof of correct execution where every participant must arrive at exactly the same result.

P2OP addresses use SegWit version 16 (OP_16) with a custom human-readable part (HRP) to create unique, easily identifiable contract addresses directly on Bitcoin. These addresses represent deployed smart contracts whose state is deterministically derived from Bitcoin blocks and finalized through OP_NET's epoch-based consensus system.

Consensus Layers (as defined by OP_NET)

OP_NET introduces the concept of a "consensus layer" as a novel architectural pattern distinct from traditional Layer 2 solutions. In existing blockchain terminology, "consensus layer" refers to the internal component of a blockchain responsible for block agreement (e.g., Ethereum's Beacon Chain). OP_NET redefines this term to describe an external system that observes a base layer blockchain's blocks and derives deterministic state according to its own ruleset, without requiring modifications to the base layer protocol.

Unlike Layer 2 solutions that typically require trust assumptions, bridges, or modifications to the base chain, a consensus layer as OP_NET defines it operates purely as an observer, processing the same blocks that all nodes see and arriving at the same derived state through deterministic execution. OP_NET is the first implementation of this pattern, enabling smart contracts on Bitcoin without protocol changes.

Security Properties

A consensus layer inherits the parent chain's security and can only be more secure, never less. This is because the consensus layer can implement its own consensus validation for "hard finality" or "soft finality" on top of what the base layer already guarantees.

Using OP_NET as an example:

• ML-DSA Requirement: OP_NET requires ML-DSA (post-quantum signatures) for contract interactions, adding security on top of Bitcoin's existing ECDSA.
• Epoch SHA-1 Mining: Uses a purely deterministic challenge for reward distribution. SHA-1 miners cannot decide the consensus - they only compete for rewards.
• Single Honest Node: The network requires only ONE honest node to maintain validity since all state is deterministically derived from Bitcoin blocks.
• Guaranteed Finality: Even if nobody mines the SHA-1 pattern, there is a fallback where the genesis block hash of the parent chain becomes the miner of that epoch, ensuring consensus finality never stops.
• Zero New Trust: Consensus layers are deterministic by nature. While you could theoretically add something like Proof-of-Stake, that introduces new trust assumptions. OP_NET has no new trust assumptions beyond Bitcoin itself.

Key Distinctions

• Not a Layer 2: L2s typically require trust assumptions, bridges, or base chain modifications. A consensus layer just observes, processes the same blocks everyone sees, and arrives at the same derived state through deterministic execution. There's no bridge, no custodian, no new trust.
• Not a Metaprotocol: Metaprotocols (like BRC-20, Runes) rely on indexers that can disagree. Tokens don't exist on Bitcoin; they exist in database entries maintained by indexers hoping everyone calculates the same results. Hope isn't consensus.
• Independent Ordering: A consensus layer can have its own block positioning algorithms, transaction ordering, or finality rules that work completely independent of how the base layer's miners order things. The base layer just provides data availability and timestamping.

P2OP addresses identify contracts within this consensus layer. Every contract interaction gets written to Bitcoin using tapscript witness data, confirmed by Bitcoin miners, and becomes part of Bitcoin's permanent record.

How P2OP Works

P2OP addresses are constructed through the following process:

1. Takes the contract's identifying bytes (derived from deployment parameters).
2. Prepends a deployment version byte (default is 0).
3. Applies HASH160 (SHA-256 followed by RIPEMD-160) to create a 20-byte hash.
4. Creates a witness program with the version byte and hash.
5. Compiles the script using OP_16 and the witness program.
6. Encodes using Bech32m with a custom OP_NET-specific HRP.

Technical Details

Witness Program Structure

The P2OP witness program consists of:

• Version Byte: A single byte indicating the deployment version (default 0).
• Hash: A 20-byte HASH160 of the contract's identifying bytes.

The total witness program must be between 2 and 40 bytes to comply with SegWit requirements.

Script Structure

The output script is compiled as:

OP_16
<witness_program>

OP_16
<witness_program>

OP_16 indicates SegWit version 16, reserved for future upgrades but utilized by OP_NET for contract addresses. This ensures P2OP addresses are valid Bitcoin outputs while remaining distinct from standard address types.

Bech32m Encoding

P2OP addresses use Bech32m encoding (not Bech32) which provides improved error detection for SegWit version 1+ addresses. The custom HRP (bech32Opnet) distinguishes OP_NET contract addresses from standard Bitcoin addresses.

Epoch Finality and Contract State

Contract state addressed by P2OP is finalized through OP_NET's epoch system:

• Each epoch consists of five consecutive Bitcoin blocks (roughly fifty minutes).
• Transactions are deterministically ordered within each block by gas price, priority fees, then transaction ID.
• Every node processes transactions through WebAssembly smart contracts, arriving at the exact same state.
• At epoch end, a checksum root (cryptographic fingerprint of all state) is created and embedded in Bitcoin.
• Miners compete to find SHA-1 near-collisions, with the winning solution becoming the official checkpoint.

This architecture means P2OP contract addresses point to state that becomes progressively more immutable. After one day, an epoch is buried under 144 Bitcoin blocks. Changing old contract state would require rewriting months of Bitcoin's history.

Security Considerations

OP_NET requires ML-DSA (post-quantum signatures) for contract interactions, adding security on top of Bitcoin's ECDSA. The quantum address (address.toHex()) is the user's universal public key - a 32-byte hash that can be encoded in various formats like P2OP.

P2OP addresses inherit OP_NET's security properties:

• Single Honest Node: OP_NET needs only ONE honest node to maintain validity since all state is deterministically derived from Bitcoin blocks.
• No Reorgs: The consensus layer cannot reorg independently. The only way to change OP_NET state is to reorg Bitcoin.
• Collision Resistance: The HASH160 provides 160-bit security against collision attacks.
• Error Detection: Bech32m encoding detects up to 4 character errors and catches common typos.
• Network Isolation: Custom HRP prevents accidental cross-network transactions.

Address Format

P2OP addresses use a custom human-readable part (HRP) defined in the network configuration (bech32Opnet) to differentiate them from standard Bitcoin addresses:

• Mainnet: Addresses start with opnet1s.
• Testnet: Addresses start with optest1s.
• Regtest: Addresses start with opregt1s.

The 1s after the HRP indicates SegWit version 16 in Bech32m encoding.