Overview

About the Library

The Transaction library is a low-level component of the client-side SDK responsible for constructing, signing, and broadcasting Bitcoin transactions within the OP_NET ecosystem. It covers the full scope of cryptographic operations, from ECDSA and ML-DSA key derivation to message signing and verification, with optional quantum-resistant security available across all signing workflows. The library also provides fine-grained control over UTXO selection, fee calculation, and multi-transaction chaining.

Transaction

Transaction Types

The library supports several transaction types, each serving a distinct purpose. The TransactionType enum defines the complete set of supported operations.

The Two-Transaction Model

The TransactionFactory handles the two-transaction construction automatically: you provide the parameters, and it returns both the interaction transaction and the funding transaction fully signed and ready to broadcast.

Simple Bitcoin transfers that do not involve smart contract logic use a single transaction and do not require this pairing.

For more details on the Two-Transaction Model, see Understanding the Protocol Design.

UTXO Model

Bitcoin operates on a UTXO model rather than an account-based balance system. Every transaction consumes one or more existing UTXOs as inputs and produces new UTXOs as outputs. The library handles UTXO selection, change calculation, and fee estimation internally. Each method on TransactionFactory returns the resulting UTXOs (nextUTXOs) that your application must track and pass as inputs to subsequent transactions. Failure to do so will result in double-spend rejections.

Addresses

Every wallet derives two keypairs: a classical ECDSA keypair for standard Bitcoin signing, and a quantum-resistant ML-DSA keypair for post-quantum security. This dual-key model follows the BIP360 specification for quantum-resistant key management, ensuring wallets are prepared for both current and future cryptographic requirements.

Wallet Key Derivation

Both addresses derive from the same Wallet, which is derived from a single BIP39 mnemonic via parallel derivation paths:

• Classical path: m/84'/0'/0'/0/0 (BIP84 for secp256k1)
• Quantum path: m/360'/0'/0'/0/0 (BIP360 for ML-DSA)

Classical (On-Chain)

Standard Bitcoin addresses used for transaction inputs and outputs on the Bitcoin layer. The library generates Taproot (P2TR) addresses by default, with optional P2MR (BIP 360) support.

Quantum (OP_NET Protocol Identity)

The quantum public key is hashed (SHA-256) to produce a 32-byte OP_NET address that serves as the user's identity across the OP_NET protocol.

For quantum-safe transaction outputs, the library supports P2MR (Pay-to-Merkle-Root, BIP360), a SegWit version 2 output type that commits directly to a Merkle root without exposing an internal public key. All transaction builders accept a useP2MR flag to enable P2MR outputs (bc1z...) addresses instead of the default P2TR (bc1p...).

Dual Environment Support

The library operates identically in both Node.js and browser environments. In the browser, MessageSigner auto-detects installed OP_WALLET extensions and methods such as signMessageAuto() and signMLDSAMessageAuto() automatically delegate signing to the browser wallet when available, falling back to a locally provided keypair otherwise. This allows the same application code to work seamlessly across server-side scripts and client-facing dApps without conditional logic.

Offline Transaction Signing

Transactions can be constructed in an online environment where UTXO data and network access are available but private keys are not present, then exported as a serialized binary payload and transferred to a network-isolated signing device. After signing, the completed transaction is returned to the online machine for broadcast. The OfflineTransactionManager orchestrates this workflow, handling serialization, deserialization, and state management across both environments.

Network Support

The library supports multiple Bitcoin networks and chains, configured through the networks object from @btc-vision/bitcoin and the ChainId enum. The chainId parameter is optional when constructing transactions. When omitted, it defaults to ChainId.Bitcoin (mainnet).