TYPE 0x0A01 · QABIO FAMILY
QABI_PRIME
Priming state transition for a QABIO-enabled UTXO. Reveals the next auth-chain preimage at a chosen depth, bumps committed_depth, and mutates the QABI_SPEND rung’s committed_root and committed_expiry to commit the UTXO into a specific upcoming batch. A participant-only operation: only the holder of the auth_seed can produce a valid preimage, so no coordinator signature is required at priming time. The new conditions tree is enforced via a covenant check against the output’s scriptPubKey.
Ladder Diagram
Fields
| Field | Data Type | Size | Side | Description |
|---|---|---|---|---|
| new_committed_root | HASH256 | 32 B | Witness | Batch root the participant is committing to. Substituted for committed_root inside the QABI_SPEND rung of the output conditions tree. Typically the Merkle root of the coordinator’s upcoming QABIBlock. |
| prime_depth | NUMERIC | 1–4 B | Witness | Depth in the auth chain at which the preimage is revealed. Must strictly exceed the current committed_depth (monotonic progression) and be bounded by QABI_AUTH_CHAIN_DEFAULT_LENGTH · 10. |
| new_committed_expiry | NUMERIC | 1–4 B | Witness | Max block height at which the subsequent QABI_SPEND may fire. Substituted for committed_expiry in the output tree. |
| prime_preimage | PREIMAGE | 32 B | Witness | Preimage such that SHA256 iterated prime_depth times yields the committed auth_tip from the QABI_SPEND rung. Only the auth_seed holder can produce this. |
QABI_PRIME has no conditions-context fields. All four fields are witness-only. The evaluator reads the “current state” (auth_tip, committed_root/depth/expiry, owner_id) from the QABI_SPEND rung of the input conditions tree — there is no duplication.
F26: the conditions field count is exactly zero. Any spurious conditions field on a QABI_PRIME block is rejected at fund time by createrungtx and at consensus by the wire-format deserialiser, closing a low-bandwidth attacker-data-embedding channel.
Evaluation Logic
1.Witness must have exactly 4 fields: HASH256, NUMERIC, NUMERIC, PREIMAGE (correctly typed, correct sizes). Otherwise → ERROR
2.Range guards:
prime_depth ≤ 0, new_committed_expiry < 0, new_committed_expiry > 0xFFFFFFFF (the WriteNumericField path silently truncates higher bits), or prime_depth ≥ QABI_AUTH_CHAIN_DEFAULT_LENGTH · 10 → ERROR3.Require
ctx.input_conditions, ctx.spending_output, and (mainline path) ctx.verified_leaves — missing → ERROR (the verified_leaves array is the source of truth for committed leaves; absence forces fail-closed). For unit tests without an MLSC proof, the evaluator falls back to the single-rung input_conditions layout.4.Reconstruct the full input-conditions tree by placing the revealed rung at
mlsc_proof.rung_index and overlaying every revealed_mutation_targets entry at its declared idx. Audit 8b F1: verify each target.rung hashes (via BuildCPRung + ComputeTxMLSCLeaf) to verified_leaves.leaves[target.idx]; mismatch → UNSATISFIED (closes a fake-rung equivocation pattern).5.Locate exactly one QABI_SPEND block across all rungs of the reconstructed tree. Zero → UNSATISFIED; more than one → ERROR (ambiguous).
6.QABI_SPEND must have exactly 5 conditions fields (2 HASH256, 2 NUMERIC, 1 PUBKEY_COMMIT) — otherwise → ERROR. Read
auth_tip (HASH256 idx 0) and committed_depth (NUMERIC idx 0); negative or undecodable → ERROR7.Check
prime_depth > committed_depth (monotonic progression). Otherwise → UNSATISFIED8.Verify
SHA256^prime_depth(prime_preimage) == auth_tip. Otherwise → UNSATISFIED9.Covenant: in a copy of the reconstructed tree, mutate the QABI_SPEND block's
committed_root (HASH256 idx 1), committed_depth (NUMERIC idx 0), and committed_expiry (NUMERIC idx 1) to the witness values. Recompute the MLSC root via ComputeConditionsRootMLSC using the per-rung pubkey vector. Extract the spending output's MLSC root via GetMLSCRoot — non-MLSC output → UNSATISFIED. Roots match → SATISFIED; differ → UNSATISFIEDReturn Values
| Condition | Result |
|---|---|
| Witness field count != 4 or wrong types/sizes | ERROR |
| prime_depth <= 0 or above safety bound | ERROR |
| No QABI_SPEND block found in input conditions | UNSATISFIED |
| Multiple QABI_SPEND blocks (ambiguous) | ERROR |
| prime_depth <= committed_depth | UNSATISFIED |
| SHA256^prime_depth(preimage) != auth_tip | UNSATISFIED |
| Output conditions_root != mutated-tree recomputed root | UNSATISFIED |
| All checks pass | SATISFIED |
Worked Example
Alice primes her QABIO UTXO for a 100-party batch coordinated by a FALCON-512 signer
Alice’s UTXO conditions tree:
[SIG_escape, QABI_PRIME, QABI_SPEND(auth_tip=H^50(seed), committed_root=0, depth=0, expiry=0, owner_id=SHA256(alice_pk))]Coordinator announces batch root
R = 0xaa..aa, expiry block 1000Alice builds a priming tx: input 0 = her UTXO, output 0 = new MLSC UTXO with
QABI_SPEND(auth_tip, R, depth=10, expiry=1000, owner_id)Alice signs the QABI_PRIME rung via
signrungtx with witness {new_committed_root=R, prime_depth=10, new_committed_expiry=1000, prime_preimage=H^40(seed)}Evaluator checks:
SHA256^10(H^40(seed)) == H^50(seed) == auth_tip → check 4 passesEvaluator rebuilds the conditions tree with mutated QABI_SPEND, recomputes MLSC root, matches the output UTXO’s root → SATISFIED
Alice broadcasts the priming tx. Her UTXO is now committed to batch
R until block 1000. The coordinator can finalise the batch via QABI_SPEND at any block ≤ 1000.Use Cases
Opt-in N-party batch commitment
Alice opts her UTXO into a specific upcoming coordinator batch by signing with her own private preimage. No cooperation with other participants is required at priming time — each participant primes independently. The covenant check ensures the primed UTXO is bound to the batch root until expiry.
Withdrawable escrow
Before priming, a UTXO can be spent via any other path in its conditions tree (e.g. a SIG escape rung). After priming, the QABI_SPEND path becomes valid for the coordinator. If the coordinator never fires, the SIG escape rung still works because QABI_PRIME only mutates the QABI_SPEND rung, not the escape rungs.
Auth-chain staging
A wallet can prime the same UTXO multiple times at progressively deeper auth-chain depths, each time committing to a different batch root. The monotonic depth rule prevents replay attacks and enforces forward-only state progression.