Ladder Script | Ghost Labs

// 00

What Is Ladder Script

Ladder Script introduces transaction version 4 (RUNG_TX) to Bitcoin. Instead of writing opcode sequences on an untyped stack, you declare spending conditions as named, typed function blocks organized into rungs. The result is a transaction format where every byte has a declared type, every condition is a named block with validated fields, and evaluation is deterministic with bounded execution time.

Zero-spam conditions. Bitcoin Script allows arbitrary data pushes — 32 bytes of anything can be a key, a hash, or a JPEG shard. Ladder Script makes this structurally impossible. With MLSC (0xC2), conditions are never stored in the output or UTXO set — only a 32-byte Merkle root. Fake conditions produce unspendable outputs, and since unspendable outputs are never spent, the fake data is never revealed on-chain. The spam kills itself. Raw public keys are witness-only; conditions use PUBKEY_COMMIT (SHA-256 of the key). Every witness field must cryptographically verify against its condition counterpart.

Post-quantum ready. FALCON-512, FALCON-1024, Dilithium3, and SPHINCS+ are native. The SCHEME field routes any SIG block to classical or post-quantum verification without changing the wire format. PUBKEY_COMMIT lets you lock funds to a 32-byte hash of a 1,793-byte PQ key today — reveal the full key only at spend time. COSIGN lets a single PQ-secured UTXO guard unlimited classical UTXOs.

Programmable money. Covenants, recursive conditions, rate limiters, state machines, sequenced approvals, fee-band gating, adaptor signatures, and protocol anchoring — all as composable typed blocks within the same wire format. No new opcodes, no Script gymnastics. The PLC family alone brings decades of proven industrial automation patterns to Bitcoin transaction logic. The possibilities are endless.

// 01

How It Works

Ladder Script organizes spending conditions as blocks within rungs. All blocks in a rung must pass (AND logic). The first rung that passes wins (OR logic). This comes from industrial PLC ladder diagrams — the same model used to wire safety-critical factory control systems.

Example: Hot/Cold Vault

R000

⎡

SIG

hot_key

⎤

⎡

CSV

144 blocks

⎤

(

UNLOCK

)

R001

⎡

MULTISIG

2-of-3 cold

⎤

(

UNLOCK

)

Rungs = OR, Blocks = AND

This vault has two spending paths. Rung 0 requires both a hot key signature AND a 144-block CSV timelock. Rung 1 is a cold recovery path with 2-of-3 multisig.

The evaluator tries rungs top to bottom. The first rung where every block passes wins — OR across rungs. Power flows left to right through each rung, just like current through a relay circuit.

The amber glow shows which rung is energized (satisfied). Blocks that pass light up. Blocks that fail break the circuit.

createrungtx output

{
  "version": 4,
  "outputs": [
    {
      "amount_sats": 100000,
      "conditions": [
        {                                     // Rung 0: hot spend
          "blocks": [
            { "type": "SIG", "pubkey": "02a1b2...hot" },
            { "type": "CSV", "blocks": 144 }
          ]
        },
        {                                     // Rung 1: cold recovery
          "blocks": [
            { "type": "MULTISIG", "threshold": 2, "pubkeys": ["02c3...", "03d4...", "02e5..."] }
          ]
        }
      ],
      "coil": { "type": "UNLOCK" }
    }
  ]
}

// 02

Every Byte Is Typed

Typed Fields, No Free-Form Data

In Bitcoin Script, a 32-byte push could be a public key, a hash, a preimage, or arbitrary data. Ladder Script restricts conditions to typed fields: PUBKEY_COMMIT, HASH256, HASH160, NUMERIC, SCHEME, and SPEND_INDEX — all fixed-size hashes or bounded integers with enforced size constraints. SCHEME routes signatures to classical (Schnorr, ECDSA) or post-quantum (FALCON-512, FALCON-1024, Dilithium3, SPHINCS+) verification.

PUBKEY, SIGNATURE, and PREIMAGE are witness-only — they cannot appear in locking conditions. Raw public keys are provided at spend time and must SHA-256 hash-match the corresponding PUBKEY_COMMIT. With MLSC (0xC2), conditions never enter the UTXO set at all — only a 32-byte Merkle root. Fake conditions produce unspendable outputs whose data is never revealed on-chain.

Static analysis requires only parsing, not execution simulation. Every field in a Ladder Script witness can be identified, validated, and displayed without running any code.

Data Types

PUBKEY       // 1-2,048 bytes  (witness only)
PUBKEY_COMMIT // 32 bytes       (SHA-256 of key, conditions only)
HASH256      // 32 bytes       (SHA-256 digest)
HASH160      // 20 bytes       (RIPEMD160(SHA256))
PREIMAGE     // 1-252 bytes    (witness only)
SIGNATURE    // 1-50,000 bytes (witness only)
SPEND_INDEX  // 4 bytes        (uint32 LE)
NUMERIC      // 1-4 bytes      (uint32 LE)
SCHEME       // 1 byte         (sig scheme: 01=Schnorr, 02=ECDSA,
             //                  10=FALCON-512, 11=FALCON-1024,
             //                  12=Dilithium3, 13=SPHINCS+)

// 03

PUBKEY_COMMIT: Hash Now, Reveal Later

32 Bytes In, Full Key Out

In Bitcoin Script, raw public keys sit in the UTXO set — 33 bytes for classical, up to 1,793 bytes for post-quantum. Ladder Script never stores raw keys in conditions. Instead, every public key is stored as a PUBKEY_COMMIT: the SHA-256 hash of the full key, always exactly 32 bytes.

At spend time, the witness provides the full public key (PUBKEY field). The evaluator computes SHA256(witness_pubkey) and verifies it matches the committed hash. Only then does signature verification proceed against the revealed key.

This gives you three things for free:

PUBKEY_COMMIT Flow

// At UTXO creation (conditions)
PUBKEY_COMMIT = SHA256(full_pubkey)
// Always 32 bytes, any key size

// At spend time (witness)
PUBKEY = full_pubkey  // 33B classical
                       // 897B FALCON-512
                       // 1,793B FALCON-1024
                       // 1,952B Dilithium3
                       // 64B SPHINCS+

// Evaluator checks:
1. SHA256(witness.PUBKEY) == conditions.PUBKEY_COMMIT
2. Verify(witness.SIGNATURE, witness.PUBKEY, sighash)

Why This Matters

Post-quantum readiness — Lock funds to a 32-byte hash of a 1,793-byte FALCON-1024 or 1,952-byte Dilithium3 key today. The UTXO set stays small. The large key only appears in the witness (which gets the segwit discount) at spend time.

Spam resistance — PUBKEY_COMMIT is a fixed 32-byte hash. Witness keys must SHA-256 match their condition commitment or the evaluator rejects the spend. With MLSC, conditions never reach the UTXO set — only a 32-byte Merkle root. Fake data in unspendable outputs is never revealed on-chain.

Uniform UTXO size — Whether your key is 33 bytes (Schnorr) or 1,952 bytes (Dilithium3), the UTXO entry is always 32 bytes. UTXO set bloat from large keys is eliminated entirely.

// 04

Evaluation & Relay Logic

Verification dispatches through three levels. The ladder tries rungs top to bottom (OR). Each rung checks all its blocks (AND). Each block runs its own type-specific logic.

Hash-Locked Atomic Swap with Timelock Fallback

R000

⎡

HASH_PREIMAGE

sha256(secret)

⎤

⎡

SIG

counterparty

⎤

(

UNLOCK

)

R001

⎡

SIG

my_key

⎤

⎡

CLTV

height 900000

⎤

(

UNLOCK

)

Evaluation Order

EvalLadder iterates rungs (OR). EvalRung iterates blocks within a rung (AND). EvalBlock dispatches to the type-specific evaluator (SIG_verify, CSV_check, HASH_compare, etc.). First rung where all blocks return SATISFIED wins. If no rung passes, the transaction is invalid.

Relay Coils & Cross-Rung Logic

In real PLC systems, relay coils carry state between rungs — one rung energizes a coil, and a contact on another rung reads it. Ladder Script uses the same pattern. Each rung terminates in a coil that determines its effect:

Coil Types

UNLOCK    // Standard — energizes = spend authorized
RELAY     // Sets a named relay flag (no direct unlock)
LATCH     // Latching relay — once set, stays set
UNLATCH   // Resets a latched relay
SIGNAL    // Output signal for covenant state

// Relay contacts (block references)
REF: relay_name  // NO contact: pass if relay is de-energized
REF: !relay_name // NC contact: pass if relay is energized

Cross-Rung Composition

A RELAY coil doesn't unlock the UTXO directly. Instead, it sets a flag that other rungs can read via relay contacts. This enables multi-rung AND composition that goes beyond simple per-rung AND logic.

Example: Rung 0 checks a signature and sets relay auth. Rung 1 checks a timelock and reads relay auth — it only passes if both the timelock AND the signature from Rung 0 are satisfied. The UNLOCK coil on Rung 1 is what actually authorizes the spend.

Relays are evaluated in rung order, top to bottom. A relay reference can only read coils from earlier rungs, preventing circular dependencies.

Example: Relay-Gated Approval

R000

⎡

SIG

approver

⎤

(

RELAY:auth

)

R001

⎡

REF

auth

⎤

⎡

CSV

144 blocks

⎤

⎡

SIG

spender

⎤

(

UNLOCK

)

// 05

Block Type Families

53 block types organized into nine numbered families. New block types are added within families, not as opcodes. See the Block Reference for deep-dive documentation on each type.

Signature

0x0001-0x00FF

Identity verification with native post-quantum support via SCHEME field routing to FALCON-512/1024, Dilithium3, or SPHINCS+.

SIG MULTISIG ADAPTOR_SIG MUSIG_THRESHOLD KEY_REF_SIG

Timelock

0x0100-0x01FF

Temporal constraints using both relative (BIP-68) and absolute timelocks in blocks or seconds.

CSV CSV_TIME CLTV CLTV_TIME

Hash

0x0200-0x02FF

Knowledge proofs via preimage reveal. SHA-256, RIPEMD160, and BIP-340 tagged hashes.

HASH_PREIMAGE HASH160_PREIMAGE TAGGED_HASH

Covenant

0x0300-0x03FF

Output constraints. Template verification (BIP-119), timelocked vaults, and amount range enforcement.

CTV VAULT_LOCK AMOUNT_LOCK

Recursion

0x0400-0x04FF

Self-referential conditions for perpetual covenants, state machines, countdowns, UTXO tree splitting, and progressive relaxation.

RECURSE_SAME RECURSE_MODIFIED RECURSE_UNTIL RECURSE_COUNT RECURSE_SPLIT RECURSE_DECAY

Anchor

0x0500-0x05FF

Typed L2 metadata. Tag UTXOs with protocol roles for channels, pools, reserves, sealed commitments, and oracle attestations.

ANCHOR ANCHOR_CHANNEL ANCHOR_POOL ANCHOR_RESERVE ANCHOR_SEAL ANCHOR_ORACLE

PLC

0x0600-0x06FF

Programmable Logic Controllers. Industrial automation patterns for stateful, rate-governed, and sequenced transaction logic.

HYSTERESIS_FEE HYSTERESIS_VALUE TIMER_CONTINUOUS TIMER_OFF_DELAY LATCH_SET LATCH_RESET COUNTER_DOWN COUNTER_PRESET COUNTER_UP COMPARE SEQUENCER ONE_SHOT RATE_LIMIT COSIGN

Compound

0x0700-0x07FF

Multi-block patterns collapsed into single blocks. Eliminates per-block headers and field counts for merged conditions.

TIMELOCKED_SIG HTLC HASH_SIG PTLC CLTV_SIG TIMELOCKED_MULTISIG

Governance

0x0800-0x08FF

Transaction-level constraints with no Tapscript equivalent. Enforce weight limits, I/O counts, value ratios, spending windows, and set membership proofs.

EPOCH_GATE WEIGHT_LIMIT INPUT_COUNT OUTPUT_COUNT RELATIVE_VALUE ACCUMULATOR

// 06

Wire Format

Version 4 Transactions

Ladder Script supports two output formats. Inline (0xC1) stores full serialized conditions in the output. MLSC (0xC2) stores only a 32-byte Merkle root — conditions are revealed at spend time in the witness.

The conditions provide the lock (pubkeys, hashes, parameters). The witness provides the key (signatures, preimages). At verification time, they merge field-by-field for evaluation. All 53 block evaluators are identical for both output formats.

Compact rungs use an n_blocks == 0 sentinel to store data inline without block overhead. COMPACT_SIG stores a 32-byte pubkey commitment and 1-byte scheme directly on the rung, resolving to a standard SIG block at evaluation time. Primarily used for change outputs.

Sighash uses a tagged hash "LadderSighash" that commits to the conditions hash (or Merkle root for MLSC outputs), binding each signature to the exact conditions it satisfies.

Wire Layout

// Inline output (0xC1)
0xC1 || SerializedRungConditions

// MLSC output (0xC2) — Merkle root only
0xC2 || conditions_root (32 bytes)

// Witness (unlocking)
[n_rungs: varint]
  [n_blocks: varint]
    [block_type: uint16 LE]
    [inverted: uint8]
    [n_fields: varint]
      [data_type: uint8]
      [data_len: varint]
      [data: bytes]
[coil_type: uint8]
[attestation: uint8]
[scheme: uint8]

// 06.1

Merkelized Ladder Script Conditions

MLSC (0xC2) replaces full inline conditions with a single 32-byte Merkle root. The complete conditions are never stored on-chain at creation — only the root appears in the output and UTXO set. At spend time, the spender reveals only the exercised rung plus a Merkle proof in the witness. Unused spending paths stay permanently hidden.

How It Works

Each rung is hashed into a leaf using TaggedHash("LadderLeaf", ...), then combined into a binary Merkle tree using TaggedHash("LadderInternal", ...) for interior nodes. This follows BIP-341 (Taproot) convention for domain separation, preventing second preimage attacks between tree layers.

MAST Privacy

Only the satisfied rung is revealed. A 2-rung script reveals 1 rung + 1 proof hash (32 bytes). A 16-rung script reveals 1 rung + 4 proof hashes (128 bytes). Unused paths remain opaque — observers cannot determine the number, type, or structure of alternative spending conditions.

Data Embedding Resistance

Fake conditions (arbitrary data disguised as keys) produce unspendable outputs. Since unspendable outputs are never spent, the fake conditions are never revealed on-chain. The blockchain sees only 32 bytes of opaque Merkle root — identical to Bitcoin P2WSH and P2TR. The spam kills itself.

MLSC Merkle Tree

// 2-rung multisig + recovery vault

         conditions_root
            /          \
       H(R0,R1)     H(COIL,EMPTY)
       /      \       /        \
   rung_0  rung_1  coil_leaf  EMPTY

// Output: 42 bytes (fixed)
value(8) + 0xC2(1) + root(32)

// UTXO entry: 40 bytes (fixed)
// regardless of script complexity

// Spending: reveal rung 0 only
// Proof: rung_leaf[1] (32 bytes)
// Rung 1 structure stays hidden

Weight Savings

// UTXO set (per output)
Single-sig:    52 B → 40 B (-23%)
2-of-3 Multisig: 112 B → 40 B (-64%)
4-path Covenant: 320 B → 40 B (-88%)
15-of-15:      530 B → 40 B (-92%)

// Full lifecycle weight (create + spend)
Single-sig:    359 WU → 319 WU (-11%)
2-of-3 Multisig: 732 WU → 528 WU (-28%)
4-path Covenant: 1427 WU → 383 WU (-73%)

// 07

Use Cases

Ladder Script enables transaction patterns that are impossible or impractical with Bitcoin Script.

HYSTERESIS_FEE

Fee-band gated spending. A UTXO that can only be spent when the transaction fee rate falls within a specified range, preventing overpayment during fee spikes.

PLC Family

AMOUNT_LOCK

Output amount range enforcement. Ensure the spending transaction creates outputs within a minimum and maximum satoshi range, enabling deposit/withdrawal bounds.

Covenant Family

Post-Quantum Migration

PUBKEY_COMMIT reduces PQ keys (897–1,952 bytes) to 32-byte UTXO commitments. COSIGN lets a single PQ anchor guard unlimited classical UTXOs. Four PQ schemes: FALCON-512, FALCON-1024, Dilithium3, SPHINCS+.

Signature Family

Recursive Covenants

RECURSE_SAME for perpetual re-encumbrance. RECURSE_COUNT for countdowns. RECURSE_DECAY for progressive parameter relaxation. All with provable termination.

Recursion Family

Rate-Limited Vaults

RATE_LIMIT + VAULT_LOCK for time-gated withdrawal limits. ONE_SHOT for single-use emergency keys. SEQUENCER for multi-step approval flows.

PLC + Covenant

Adaptor Signatures

ADAPTOR_SIG block type enables atomic swaps and payment channel protocols with a single block, replacing complex Script constructions.

Signature Family

Aggregate Threshold Signatures

MUSIG_THRESHOLD enables M-of-N multisig via MuSig2/FROST where the on-chain footprint is identical to single-sig (~131 bytes). A 3-of-5 treasury is indistinguishable from a solo wallet on-chain.

Signature Family

Protocol Anchoring

Six typed anchor blocks for Lightning channels, mining pools, reserve sets, sealed commitments, and oracle attestations. Replace ad-hoc OP_RETURN tagging.

Anchor Family

Structural Spam Resistance

MLSC outputs store only a 32-byte Merkle root — no conditions in the UTXO set. Fake conditions produce unspendable outputs whose data is never revealed. Typed fields with enforced size constraints eliminate free-form data pushes.

Core Design

Compound Wire Savings

HTLC collapses hash + timelock + signature into one block, eliminating redundant headers. TIMELOCKED_SIG, HASH_SIG, CLTV_SIG each merge two blocks into one. PTLC collapses adaptor sig + CSV for payment channels. TIMELOCKED_MULTISIG collapses M-of-N + CSV for penalty branches and vault recovery.

Compound Family

Transaction Governance

EPOCH_GATE restricts spending to periodic windows. WEIGHT_LIMIT caps transaction size. INPUT_COUNT and OUTPUT_COUNT bound I/O fanout. RELATIVE_VALUE prevents fee siphoning. ACCUMULATOR proves Merkle set membership.

Governance Family

Timer-Controlled Access

TIMER_CONTINUOUS requires N consecutive blocks of activity before authorization. TIMER_OFF_DELAY holds spending rights for a grace period after a trigger expires. Together they implement watchdog patterns and supervised custody.

PLC Family

Approval Accumulators

COUNTER_PRESET accumulates approvals from independent parties. Each approval increments via RECURSE_MODIFIED. Once the preset count is reached, funds release. Unlike MULTISIG, approvals can arrive in separate transactions.

PLC Family

Value-Band Spending

HYSTERESIS_VALUE constrains output values to a band [low, high]. Prevents both dust outputs and excessive single-spend withdrawals. Useful for corporate disbursement policies and regulated fund flows.

PLC Family

Calendar-Dated Unlocks

CLTV_TIME locks funds until a specific Unix timestamp rather than a block height. Ideal for grant agreements, employment vesting, and financial contracts with real-world calendar deadlines.

Timelock Family

Tagged Hash Attestation

TAGGED_HASH enables BIP-340 domain-separated hash verification. Oracles, price feeds, and external data sources commit using tagged hashes, ensuring domain isolation and preventing cross-protocol replay.

Hash Family

Time-Bounded Recursion

RECURSE_UNTIL terminates recursive covenants at a specific block height, providing a hard lifetime bound. Unlike RECURSE_COUNT which counts spends, RECURSE_UNTIL anchors termination to consensus time.

Recursion Family

// 08

Try the Builder

The Ladder Script Builder is a visual tool for constructing ladder transactions. Drag blocks onto rungs, configure typed fields, and see the resulting wire format in real time.

ladder-engine — 2-of-3 Multisig Vault

Ladder Diagram

RUNG 0 — AUTH

SIG

MULTISIG

( )

CLTV

SIG

( )

HYSTERESIS_FEE

( )

Wire Format (JSON)

{

"version": 4,

"rungs": [

{ "blocks": [

{ "type": "SIG", "code": "0x0001" },

{ "type": "MULTISIG", "m": 2, "n": 3 }

] },

{ "blocks": [

{ "type": "CLTV", "height": 52560 },

{ "type": "SIG", "code": "0x0001" }

] },

{ "blocks": [

{ "type": "HYSTERESIS_FEE",

"low": 5, "high": 50 }

] }

"wire_bytes": 142

}

Launch Builder

// 09

Examples

Pre-built programs from the Ladder Script Builder. Click any example to load it in the engine.

2-OF-3 MULTISIG VAULT

Corporate treasury with 2-of-3 multisig spending and a time-locked recovery path using a single backup key after 1 year.

What Is Ladder Script

How It Works

Rungs = OR, Blocks = AND

Every Byte Is Typed

Typed Fields, No Free-Form Data

PUBKEY_COMMIT: Hash Now, Reveal Later

32 Bytes In, Full Key Out

Evaluation & Relay Logic

Relay Coils & Cross-Rung Logic

Cross-Rung Composition

Block Type Families

Wire Format

Version 4 Transactions

Merkelized Ladder Script Conditions

How It Works

MAST Privacy

Data Embedding Resistance

Use Cases

Try the Builder

Examples

Documentation