Tooling Suite
Self-custodial tools for Bitcoin transactions & assets
Yuzo’s tooling suite provides a vertically integrated transaction execution layer for Bitcoin Ordinals, BRC-20, and BRC2.0 assets.
Each tool manages key Bitcoin transaction construction and execution steps, including:
PSBT construction
UTXO selection and change management
Commit–reveal inscription flows
OP_RETURN contract invocation
Multi-step signing workflows
The interface reduces complex transaction assembly into deterministic, user-signed execution.
No custody. No intermediaries. Execution occurs directly on Bitcoin.
All tools share a common execution backbone:
Taproot script-path spending
Commit–reveal inscription architecture
OP_RETURN programmable payloads
Real-time mempool-aware fee estimation
Transactions are constructed client-side, signed by the user’s wallet, and broadcast to the Bitcoin network.
Info: Tools operate at the Bitcoin transaction and UTXO layer. They interact with BRC-20 and BRC2.0 standards through protocol-compliant envelopes but remain native to Bitcoin’s base settlement layer. Wrapping, transfer, programmable contract calls, and inscription logic are encoded directly into Bitcoin transactions. There is no off-chain execution engine. Indexers observe and interpret protocol state, but execution finality is determined solely by Bitcoin block confirmation.
BRC-20 / 2.0 Deploy & Mint
Permissionless Token Issuance: The Deploy & Mint tool provides a native issuance interface for fungible tokens on Bitcoin.
Supports:
BRC-20 (legacy 4–5 byte tickers)
BRC2.0 (programmable 6-byte tickers with EVM-compatible extensions)
Execution occurs through protocol-compliant inscriptions anchored directly to Bitcoin L1.
No custody. No intermediaries. Token state is derived from onchain inscription data.
Deployment
Deployment originates a new token by inscribing a protocol-compliant JSON envelope.
The deployer defines immutable token parameters before inscription.
Operator Inputs:
Protocol version (BRC-20 or BRC2.0)
Ticker (4–6 characters; validated against live index state)
Maximum supply
Per-mint limit
Decimals (BRC2.0 only)
Self-mint flag (optional restriction to deployer)
Parent inscription ID (BRC2.0 provenance linking)
Execution
BRC-20 Deployment
A single deploy inscription is created:
The inscription is embedded via Taproot witness data and confirmed through standard commit–reveal flow.
BRC2.0 Deployment (Hash-Commit Scheme)
BRC2.0 introduces a deterministic pre-commit mechanism to prevent ticker front-running.
Phase 1 — Pre-Deploy (Hash Commit)
A deterministic hash is computed:
SHA256(SHA256(ticker + salt + pkscript))
saltis auto-generatedpkscriptbinds the commit to the deployer's script
The pre-deploy inscription commits this hash on-chain without revealing parameters.
Phase 2 — Deploy (Reveal)
A second inscription reveals full token parameters.
Indexers verify:
Hash matches pre-commit
Ticker uniqueness
Parameter validity
This two-phase scheme eliminates mempool-level ticker sniping and ensures fair origination.
Transaction Flow
Commit PSBT → wallet signature → broadcast Reveal PSBT → wallet signature → broadcast
The commit funds a Taproot output derived from an ephemeral keypair. The reveal spends that output and publishes the inscription envelope in witness data.
Finality is determined by Bitcoin block confirmation.
Minting
Minting follows protocol-defined limits established at deployment.
The tool:
Fetches live token state (remaining supply, mint progress, holder count)
Validates requested mint amount
Constructs commit–reveal transactions
Supports batch minting (up to 20 mints per commit)
Each mint produces a separate reveal transaction.
State updates are derived from onchain inscriptions observed by indexers.
Fee
Service Fees
Deploy (BRC-20): 2,100 sats
Pre-deploy (BRC2.0): 3,333 sats
Mint: 2,100 sats (waived for staked Yuna Revelation holders)
Batch minting scales logarithmically:
floor(2100 × log10(10 + repeatCount − 1))
Design
Fully permissionless issuance
Deterministic hash-based ticker protection
Commit–reveal integrity
Taproot-native embedding
No offchain execution dependencies
Token state is derived from protocol-compliant inscriptions confirmed on Bitcoin.
Inscribe
The core inscription engine for creating permanent onchain data artifacts.
Functions as the platform's primary content commitment mechanism across four modalities.
Text
Publishes UTF-8 encoded plaintext using text/plain MIME type.
Use cases:
Onchain attestations
Messages
Protocol metadata
Structured JSON payloads
The content is embedded directly into the Taproot witness script.
File
Accepts binary uploads with automatic MIME detection.
Content is chunked into ≤520 byte segments (Bitcoin script push limit)
Embedded in Taproot witness data
Maximum payload size: ~395 KB per inscription
This supports images, SVG, JSON, binaries, and arbitrary file formats.
HTML
A development environment for interactive inscriptions.
Features:
Monaco editor (VS Code engine)
Sandboxed iframe live preview
AI-assisted code editing via SSE streaming
Prompt-based image generation for embedded assets
Snapshot capture for static rendering
All output is ultimately serialized and embedded in the witness script.
No offchain hosting dependency is required after inscription.
Delegate
Creates delegate inscriptions referencing a parent inscription.
This enables:
Capital-efficient collection issuance
Shared base content across child inscriptions
Reduced per-unit inscription cost
Up to 99 delegate inscriptions can be created per batch.
Children inherit content from a single parent reference while maintaining independent ownership at the UTXO level.
Inscription Envelope Architecture
Inscriptions follow the Ordinals Taproot witness structure:
Key characteristics:
Embedded in witness data
Executed via Taproot script path spend
Content chunked to 520-byte limits
Metadata encoded as CBOR
330 sats per inscription (standard pointer convention)
No external state machine is required for validation. The Bitcoin transaction itself anchors the data permanently.
Execution
All inscriptions follow a deterministic commit–reveal flow.
Metadata
Arbitrary JSON metadata is:
CBOR encoded
Chunked into witness script segments
Tagged within the envelope
This enables structured metadata for collections, traits, governance payloads, and protocol integrations.
Fee
Design
Taproot-native
Witness-embedded data
No external storage dependency
Non-custodial execution
Mempool-aware fee optimization
Fully permissionless
All data is anchored directly to Bitcoin consensus.
Cancel Transaction
Cancel transaction enables replacement of an unconfirmed Bitcoin transaction using BIP-125 Replace-By-Fee (RBF).
It constructs a higher-fee transaction that consumes the same inputs as the original and redirects outputs back to the user’s address, effectively reclaiming capital before confirmation.
This tool operates entirely at the Bitcoin transaction layer. No third party custody or relayer is involved.
Preconditions
A transaction can only be replaced if:
It is unconfirmed
It signals RBF (nSequence < 0xffffffff)
The connected wallet controls the original inputs
If these conditions are not met, replacement is not possible under Bitcoin consensus rules.
Execution
Replacement Construction
A new PSBT is constructed using:
The exact same inputs as the original transaction
Outputs redirected to the user’s recovery address
A higher absolute fee to satisfy mempool replacement policy
Under BIP-125 rules, the replacement must pay a higher fee and meet incremental relay requirements.
Fee
Network Fee
Calculated as:
Prior formula referencing fixed byte assumptions is replaced with actual PSBT-derived virtual size estimation for accuracy.
Replacement transactions must pay:
Higher total fee than original
Higher fee rate than original
Meet BIP-125 incremental relay threshold
Design
Non-custodial PSBT flow
Deterministic input reuse
BIP-125 compliant replacement
Mempool-aware fee escalation
Full UTXO-level control
This tool provides capital recovery and mempool control for advanced Bitcoin users operating in high-volatility fee environments.
Bulk Send
Bulk send enables multiple inscription transfers to be executed within a single Bitcoin transaction.
By aggregating inscription UTXOs into one PSBT, users reduce cumulative transaction overhead compared to sequential transfers. This is particularly relevant during elevated fee environments where per-transaction base weight materially impacts cost.
This tool operates directly at the UTXO layer and preserves inscription integrity under the Ordinals transfer model.
Execution
Transaction Construction
For each selected inscription:
The inscription UTXO is added as a transaction input
A corresponding output is created at the recipient address
The inscription sat is preserved within the transferred output
Non-inscription UTXOs are selected separately to fund miner fees. Inscription UTXOs are not used for fee payment unless explicitly required.
The transaction preserves the 1:1 mapping between inscription UTXO and recipient output to avoid accidental sat loss or ordinal misplacement.
Fee Funding & Change Management
Fee funding UTXOs are selected using deterministic coin selection.
If total input value exceeds:
and the remainder is greater than the dust threshold (546 sats), a change output is created.
If below dust threshold, excess is absorbed into miner fee per standard Bitcoin behavior.
Fee
Network Fee
Transaction weight scales approximately linearly with:
Number of inscription inputs
Number of outputs
Batching reduces repeated base transaction overhead compared to executing multiple standalone transfers.
Design
Non-custodial PSBT flow
UTXO-aware inscription handling
Ordinals-compatible transfer logic
Single-signature broadcast
Deterministic coin selection
Bulk Send functions as a portfolio management primitive for active inscription holders, enabling capital efficiency without modifying underlying Ordinals protocol rules.
BRC2.0 Wrapper
The BRC2.0 wrapper converts indexer-tracked BRC-20 balances into BRC2.0 programmable balances.
This process transitions a token from the legacy inscription-based accounting model into the BRC-20 programmable module, enabling contract-level interaction, EVM execution, and DeFi composability on Bitcoin.
The wrapper operates entirely through Bitcoin transactions. No custodial bridge or off-chain escrow is involved.
Execution
OP_RETURN Registration (Programmable Layer Entry)
After the reveal confirms, a separate Bitcoin transaction is broadcast containing an OP_RETURN payload.
This transaction:
References the wrapped BRC-20 transfer
Registers the converted balance on the BRC-20 programmable module
Burns the BRC-20 transfer allocation at the indexer level
The result is a deterministic supply transition:
BRC-20 balance decreases
BRC2.0 balance increases
Total supply remains conserved
Transaction Sequence
The full conversion consists of three onchain transactions:
Commit (Taproot funding transaction)
Reveal (inscription publication)
OP_RETURN programmable registration
The programmable registration binds the wrapped amount to a BRC2.0 EVM-compatible address derived from the user’s linked address mapping.
No synthetic asset is created. The wrapper performs a canonical state migration between two protocol layers.
Address Mapping
Wrapped balances become EVM-addressable.
If initiated from a Bitcoin address:
The scriptPubKey is hashed
The last 20 bytes of keccak256(scriptPubKey) define the BRC2.0 EVM address
This deterministic mapping ensures:
No custody handoff
No key migration
Cryptographic linkage between Taproot and EVM representations
Post-Wrap
Once wrapped, the asset can:
Interact with BRC2.0 smart contracts
Participate in staking vaults
Provide liquidity
Execute ERC-20 style transfers
Be included in programmable DeFi logic
The wrapper functions as the entry point into the programmable execution environment.
Fee
Network Fees
Standard:
Commit transaction fee
Reveal transaction fee
OP_RETURN registration fee
Total cost scales with selected fee rate and mempool conditions.
Design
Fully onchain conversion
Supply-conserving state migration
Deterministic address derivation
No custodial intermediary
Native Bitcoin settlement
The BRC2.0 wrapper formalizes the transition from inscription-indexed token state to programmable contract state, enabling composability while preserving Bitcoin-native settlement guarantees.
Transfer BRC2.0
Transfer BRC2.0 and LP tokens between Taproot-linked and EVM-compatible addresses.
This tool executes ERC-20–style transfer(address,uint256) calls on the BRC-20 programmable module, with execution instructions encoded inside Bitcoin OP_RETURN transactions and finalized through the standard commit–reveal inscription flow.
No offchain relay or custodial bridge is involved. State transitions are recorded via Bitcoin transactions and interpreted by the BRC2.0 execution environment.
Execution
Calldata Encoding
An ERC-20 transfer(address,uint256) function call is constructed using ABI encoding.
The encoded calldata represents:
This calldata defines the exact state transition to be executed by the BRC2.0 contract.
No synthetic wrapper logic is added. The call matches standard ERC-20 semantics.
Address Resolution
If the recipient provides:
A native EVM address → used directly
A Bitcoin address → deterministically converted
Bitcoin addresses are converted into BRC2.0 EVM addresses using:
The final 20 bytes of the hash define the EVM-compatible address.
This maintains cryptographic linkage between Taproot addresses and programmable balances without requiring key migration.
Compression
The ABI-encoded calldata is compressed using NADA encoding and prefixed with a 0x01 identifier byte.
The compressed payload is base64-encoded before inscription to reduce on-chain footprint and minimize fee overhead.
This step directly reduces witness size and therefore reduces network fees.
Protocol Envelope & Commit-Reveal
The compressed calldata is wrapped in the BRC2.0 programmable envelope:
Where:
pidentifies the programmable protocolop: "c"indicates contract callcis the contract addressbis the compressed calldata
The envelope is inscribed using the standard two-phase commit → reveal process:
Commit transaction funds a Taproot output
Reveal transaction publishes the envelope in the witness
The programmable layer interprets the inscription and applies the state transition.
Settlement Properties
Finalized by Bitcoin block confirmation
Deterministic state execution
No custody transfer
No external sequencer
The Bitcoin chain acts as the settlement anchor.
Fee
Network Fees
Standard commit–reveal transaction costs.
Typical cost range: ~2,000–5,000 sats depending on fee rate and calldata size.
Fees scale with:
Mempool congestion
Payload size
Selected sat/vB rate
Design
ERC-20–compatible execution semantics
Deterministic Bitcoin-anchored settlement
Cryptographically linked address mapping
Fully permissionless interaction
No reliance on custodial infrastructure
This tool provides direct programmable token transfers while preserving Bitcoin-native finality.
OP_RETURN Contracts
Deploy and interact with EVM-compatible smart contracts on Bitcoin through the BRC-20 Programmable Module, encoded as OP_RETURN inscriptions.
This is the base execution primitive for programmable DeFi on Bitcoin. Vaults, AMMs, staking contracts, emissions logic, and token mechanics ultimately resolve to this interface.
Execution data is committed to Bitcoin via commit–reveal inscriptions. Contract state transitions are deterministically interpreted by programmable module indexers.
Deploy Mode
Deploy a new smart contract by inscribing compressed EVM bytecode.
Deployment Mechanics
EVM bytecode is ABI-ready prior to submission
Bytecode is NADA-compressed to reduce inscription size
Deployment follows the standard commit → reveal inscription flow
Upon reveal confirmation, programmable module indexers instantiate the contract
The contract address is deterministically derived from deployment context
Deployment is immutable once the reveal transaction confirms on Bitcoin.
Call Mode
Invoke functions on contracts deployed within the BRC-20 Programmable Module.
The tool handles allowance checks, calldata construction, compression, and ordered execution.
Execution
Contract Call
After approvals confirm, the primary calldata is ABI-encoded and compressed.
Where:
op: "c"specifies a contract callcdefines the contract addressbcontains compressed ABI calldata
The envelope is inscribed via commit → reveal.
Upon confirmation:
The Programmable Module interprets the calldata
Contract state is updated deterministically
State transitions are reproducible by any compliant indexer
OP_RETURN transports execution payloads
Bitcoin provides timestamping, transaction ordering, and settlement finality
The BRC-20 Programmable Module interprets EVM-compatible instructions
State transitions are deterministic and replayable
This architecture preserves:
Bitcoin-native settlement
EVM-compatible programmability
Permissionless execution
Infrastructure neutrality
Bitcoin anchors the data. The module interprets execution. No intermediary.
Fee
Network Fees
3 sat/vB default for contract operations
Total cost scales with:
Bytecode size (deploy mode)
Calldata size (call mode)
Current mempool conditions
Design
This tool is a developer-level execution primitive.
It enables:
AMMs
Lending markets
Vault contracts
Emission schedules
Governance logic
All execution is anchored to Bitcoin transactions and interpreted by the BRC-20 Programmable Module.
Airdrop Module
Programmatic distribution of BRC2.0 tokens and LP positions to multiple recipients in a single on-chain execution.
The Airdrop Module enables batch transfers through a dedicated smart contract deployed on the BRC-20 Programmable Module, reducing operational overhead and minimizing per-recipient transaction costs compared to sequential transfers.
Execution
Allowance Pipeline
Before execution, the tool verifies that the airdrop contract has sufficient token allowance via standard ERC-20 allowance checks.
If the allowance is insufficient:
An
approve(spender, totalAmount)transaction is constructedExecuted via commit → reveal → OP_RETURN
Confirmed before proceeding to batch execution
This enforces deterministic token spend authorization at the contract level.
Execution
The compressed calldata is wrapped in the programmable module envelope and inscribed using the standard commit-reveal pattern.
Execution results in:
A single on-chain contract call
Deterministic token state updates across all recipients
Atomic settlement under the programmable module’s indexer consensus model
This reduces gas-equivalent execution overhead compared to issuing thousands of individual transfers.
Fee
Service Fee
33,333 + (20 × number_of_recipients)satsScales linearly with distribution size to reflect calldata growth and execution complexity
Network Fees
Standard commit-reveal + OP_RETURN broadcast costs
Determined by virtual transaction size × selected fee rate
Design
Execution is anchored to Bitcoin via inscription settlement.
Contract logic is executed deterministically by programmable module indexers.
No custodial intermediary participates in token distribution.
All transfers are verifiable via Bitcoin transaction history and programmable module state.
UTXO Management
Inspect, consolidate, and manage UTXOs to optimize wallet state, reduce fragmentation, and maintain execution efficiency across inscriptions, token transfers, and programmable module interactions.
Bitcoin is UTXO-based. Poor UTXO hygiene increases fees, breaks workflows, and creates signing complexity.
This tool provides direct control over wallet state at the transaction layer.
Why UTXO Management Matters
On Bitcoin:
Every input increases virtual size and fee cost
Fragmented UTXOs increase future transaction overhead
Inscription UTXOs must be handled carefully to avoid accidental loss
Commit–reveal flows require clean fee-funding outputs
Efficient UTXO structure reduces:
Future transaction fees
PSBT size and signing complexity
Mempool rejection risk
Workflow friction across programmable module operations
Core Capabilities
1) UTXO Inspection
Displays all spendable outputs associated with the connected wallet, including:
Value (sats)
Script type (P2TR, P2WPKH, P2SH-P2WPKH, P2PKH)
Confirmation status
Inscription association (if applicable)
Allows users to distinguish between:
Inscription-bearing UTXOs
Pure funding UTXOs
Dust outputs
Consolidation candidates
2) Consolidation
Combines multiple smaller UTXOs into a single output via a controlled self-transfer.
Execution mechanics:
Select multiple funding UTXOs
Construct a PSBT sending value back to a wallet-controlled address
Preserve inscription UTXOs by excluding them from selection
Broadcast at user-defined fee rate
Benefits:
Reduces future input count
Lowers cumulative fee burden
Simplifies downstream DeFi operations
Consolidation is especially useful before:
Batch minting
Airdrops
Contract calls
Bulk transfers
3) Fee-Funding Optimization
Allows users to intentionally separate:
Inscription UTXOs (non-spendable for fees)
Clean funding UTXOs (dedicated to fee payment)
This improves reliability of:
Commit–reveal flows
OP_RETURN contract execution
Replace-by-fee (RBF) operations
Maintaining distinct fee UTXOs prevents accidental inscription movement during capital operations.
Execution
Transactions are constructed via PSBT
Coin selection prioritizes minimal input count
Inscription-bearing UTXOs are protected from unintended spending
Change outputs are created only when above dust threshold
Full wallet signing remains user-controlled
No custodial handling. No delegated signing.
All state changes occur directly at the Bitcoin transaction layer.
Architectural Positioning
UTXO Management is a foundational execution utility.
It ensures:
Efficient capital deployment
Lower long-term fee overhead
Cleaner programmable module interactions
Reduced transaction failure risk
Every higher-level tool — deploy, mint, wrap, contract execution, staking — benefits from optimized UTXO structure.
Bitcoin is the settlement layer. UTXOs are the state container.
Managing them properly is capital efficiency at the base layer.
Speed Up Transaction ⏳
Accelerate confirmation of an unconfirmed Bitcoin transaction using Replace-By-Fee (RBF).
When mempool congestion increases or fee conditions change, previously broadcast transactions may stall. This tool reconstructs and rebroadcasts the transaction with a higher effective fee rate, preserving inputs while improving miner inclusion probability.
Execution remains fully non-custodial and user-signed.
How It Works
Supplemental Funding (If Required)
If the original change output cannot cover the elevated fee:
Additional funding UTXOs are selected
Coin selection prioritizes minimal input expansion
Inscription-bearing UTXOs are excluded from fee funding
This preserves asset integrity while enabling confirmation acceleration.
Execution
Transaction rebuilt via PSBT
Signed locally in wallet
Broadcast to mempool as replacement
Confirmation priority increases proportionally to fee rate
Bitcoin miners will prefer the higher-fee transaction and drop the original from the mempool.
No funds are routed through intermediaries. No delegated signing occurs.
Last updated