Bitcoin inscriptions have turned the blockchain into a canvas for digital art, NFT collections, and permanent on-chain data. But creating an inscription requires BTC, a Bitcoin wallet, and manual coordination of commit and reveal transactions. For a project on BOB or any EVM chain, this is a hard problem. An NFT project launching a collection on Bitcoin has no Bitcoin wallet. It has no BTC. And a smart contract cannot hold private keys.

We found a way to make this fully trustless using a Bitcoin script trick and BOB Gateway. No private keys, no bonds, no disputes. Just math.

tl;dr:

  1. Any project on BOB can inscribe art, collections, or data on Bitcoin without holding BTC or managing Bitcoin private keys.
  2. The inscription content is cryptographically guaranteed by taproot. No party can alter it.
  3. BOB Gateway handles the BTC funding via a standard offramp. No protocol changes needed.
  4. The same flow works from Ethereum, Base, or any chain that can submit transactions to BOB.
  5. On-chain verification of the inscription is possible using the existing Bitcoin light client and witness transaction proofs on BOB.

The Problem

Consider an NFT project on BOB that wants to launch an art collection as Bitcoin inscriptions. Or a DAO that wants to inscribe a governance resolution. Or a game that wants to mint in-game items on the most secure blockchain. Today, all of these require someone to hold Bitcoin private keys and manually coordinate transactions.

The standard inscription flow requires two Bitcoin transactions:

  1. A commit transaction that funds a taproot address containing the inscription data.
  2. A reveal transaction that spends that address, exposing the inscription in the witness.

Both transactions require a Bitcoin private key. The commit address is derived from this key and the inscription content. The reveal transaction needs a signature from that key.

This is where it breaks down for any on-chain project. A smart contract cannot hold a Bitcoin private key. If a human holds it, you trust that human. If you use a multisig or MPC, you trust the threshold participants. If you use a bond and dispute mechanism, you rely on economic security. For an art collection with hundreds of pieces, the coordination burden multiplies with every inscription.

We wanted something better: a solution where no one holds a key, and the inscription content is guaranteed by cryptography alone.

The Trick: Eliminate the Key Entirely

Standard inscriptions use OP_CHECKSIG in the tapscript to authorize the reveal transaction. The signature binds the spend to specific outputs and proves the spender controls the key. But what if we do not need a key at all?

The inscription data lives inside the tapscript in an OP_FALSE OP_IF envelope. This code block is never executed. It exists purely to be revealed in the witness when the script-path spend happens. The actual spending condition comes after the envelope.

If we replace <pubkey> OP_CHECKSIG with OP_TRUE, the script succeeds unconditionally. Anyone can spend it. No signature required.

OP_FALSE OP_IF 
  "ord"  
  <content-type>  
  <inscription body>
OP_ENDIF
OP_TRUE

This looks dangerous at first. Anyone can spend the UTXO to any address. But look at what they cannot do: they cannot change the inscription content.

In a taproot script-path spend, BIP 341 requires the full script to be provided in the witness. The script hash is verified against the taproot commitment baked into the P2TR address. If you change even one byte of the inscription, the script hash changes, the taproot address changes, and the spend fails consensus validation.

The inscription content is cryptographically bound to the commit address. It is not protected by a key. It is protected by the same hash commitment that secures all of taproot.

Making the Key Path Unspendable

Taproot addresses have two spending paths: the key path and the script path. The key path lets anyone who knows the internal key's discrete logarithm spend without revealing any script. We need to disable this.

The solution is a NUMS point (Nothing Up My Sleeve): a public key for which no one knows the private key. The standard choice is the x-coordinate 0x50929b74c1a04954b80b2c20e831a0a0e86db4b03a28d332e8a57ff958fd3a68, derived from hashing a well-known string. No one can compute the discrete log of this point, so the key-path spend is computationally impossible.

With a NUMS internal key and OP_TRUE as the spending condition, the commit address is fully deterministic from the inscription content. Given the same content, anyone on earth computes the same address. No keys involved at any step.

The Full Flow

Here is how a project on BOB inscribes on Bitcoin:

1. Propose. Someone submits the inscription content to a contract on BOB. This could be a single artwork, one piece in a collection, or a governance resolution. The contract stores contentHash = keccak256(content).

2. Verify. Anyone can independently compute the deterministic commit P2TR address from the content. For a DAO, members verify before voting. For an NFT mint, the contract can batch-compute addresses for an entire collection. This is a pure function of public inputs.

3. Approve. For a DAO this means a governance vote. For an NFT collection this could be the creator triggering a mint. For a game it could be an automated action.

4. Fund. If the vote passes, the DAO contract creates a BOB Gateway offramp order sending a small amount of wBTC (around 5,000-10,000 sats worth) to the computed commit address. This is a standard Gateway offramp. No protocol changes needed. A solver picks up the order and sends BTC to the commit address on Bitcoin. The commit UTXO now exists.

5. Reveal. Anyone who knows the inscription content (it is public from the DAO proposal) constructs the reveal transaction. The witness contains the inscription script and the control block. There is no signing step. The transaction is broadcast and confirmed. The inscription is permanently on Bitcoin.

6. Verify on-chain. Optionally, anyone can submit a witness SPV proof to the DAO contract on BOB. Using the existing WitnessTx library and Bitcoin light relay, the contract verifies the reveal transaction was confirmed on Bitcoin and that the witness contains the expected inscription content matching the stored contentHash.

Cross-Chain Inscriptions: Ethereum, Base, and Beyond

Since BOB Gateway supports cross-chain transaction submission natively, this flow is not limited to DAOs on BOB. A DAO on Ethereum or Base can trigger the same inscription process. The cross-chain message reaches BOB, the Gateway offramp funds the commit address on Bitcoin, and anyone reveals. The inscription originates from any EVM chain but lands on Bitcoin.

This makes BOB the coordination layer for Bitcoin inscriptions across the entire EVM ecosystem. An NFT project on Base can launch a Bitcoin inscription collection. A governance contract on Ethereum can inscribe a resolution. A game on any L2 can mint items as ordinals. All without touching a Bitcoin wallet.

Security Analysis

Every attack vector is blocked by Bitcoin consensus rules or the NUMS construction:

Alter the inscription content. Impossible. The tapscript hash changes, the taproot address changes, and the script-path spend fails validation against the funded UTXO.

Steal the commit UTXO via key-path. Impossible. The internal key is a NUMS point with no known discrete logarithm.

Proposer withholds a key. There is no key. OP_TRUE needs no key.

Revealer sends the output to the wrong address. The inscription data is in the witness regardless of where the output goes. For art collections and data inscriptions alike, the content is on Bitcoin permanently. The output destination determines who "owns" the inscribed sat, not whether the inscription exists.

No one reveals. The UTXO sits on Bitcoin spendable by anyone, forever. The first person to broadcast a valid reveal gets the dust output. A simple bot can automate this.

On-Chain Verification with the Bitcoin Light Client

BOB already runs a Bitcoin light relay (LightRelay) for Gateway's SPV proof verification. The WitnessTx library extends this to validate transactions including their witness data. This is key: standard SPV proofs cover the transaction but not segwit witness data. WitnessTx validates the witness against the witness merkle root committed in the coinbase transaction (BIP 141).

For inscription verification, the DAO contract on BOB can:

  1. Accept a WitnessTx.WitnessProof for the reveal transaction.
  2. Validate it against the light relay (confirms the tx is in a valid Bitcoin block with sufficient proof of work).
  3. Parse the witness vector to extract the tapscript.
  4. Extract the inscription body from the OP_FALSE OP_IF envelope.
  5. Verify keccak256(extractedBody) == contentHash.

This closes the loop entirely on-chain. The DAO contract knows, with the same certainty as any Bitcoin full node, that the voted content was inscribed on Bitcoin.

Future: Output Control with OP_CAT Covenants

The one thing the current design does not control is the output destination of the inscribed sat. The revealer can send it to any address. For data inscriptions this is irrelevant since the content is in the witness regardless.

If a future use case requires the DAO to also own the inscribed sat, OP_CAT (BIP 347) would enable this. The Schnorr + CAT trick allows a tapscript to constrain the spending transaction's outputs without any trusted party. The inscription script would reconstruct the expected sighash on the stack and verify it against a deterministic signature, locking the output to a specific destination. Same zero-trust properties, just with output control added. This is not possible on Bitcoin mainnet today but provides a clean upgrade path.

Conclusion

Bitcoin inscriptions do not need private keys. By replacing OP_CHECKSIG with OP_TRUE and using a NUMS internal key, we eliminate key management entirely from the inscription process. The taproot commitment guarantees the content. The Gateway handles the funding. The light client verifies the result.

This turns BOB into a coordination layer for Bitcoin inscriptions. Any project on any EVM chain can inscribe art, collections, or data on Bitcoin without holding BTC, managing keys, or trusting any intermediary. The security is not economic. It is cryptographic.

Whether you are launching an art collection, minting game items, or recording governance decisions, the same mechanism works. If you are building on BOB and want to integrate trustless inscriptions, check out the BOB Gateway documentation or reach out to us.

‍