TYPE 0x0402 · RECURSION FAMILY

RECURSE_MODIFIED

Covenant with controlled mutations. Output must match input conditions except for specified numeric parameter changes. Each mutation applies an additive delta to a targeted parameter at a specific (rung, block, param) position. No Tapscript equivalent.

Recursion Invertible

Ladder Diagram

Fields

Field	Data Type	Size	Side	Description
max_depth	NUMERIC	1-4 B	Conditions	Recursion termination guard. Consensus only checks `max_depth > 0` (positivity); not compared against a counter.
block_idx	NUMERIC	1-4 B	Conditions	Target block index within rung 0 (legacy) or per-mutation target (new format). Per `feedback_recurse_covenants`, `param_idx` counts post-fold condition fields (after PUBKEYs are stripped into the Merkle leaf).
param_idx	NUMERIC	1-4 B	Conditions	Target parameter index within the block (post-fold counting). The targeted field must be NUMERIC; non-NUMERIC targets fail.
delta	NUMERIC	1-4 B	Conditions	Additive delta applied to the target parameter. Two's-complement signed; positive or negative.

Legacy format: 4 or 5 NUMERICs — max_depth, block_idx, param_idx, delta; single mutation targeting rung_idx = 0. The 5-NUMERIC case is also recognised (the extra trailing NUMERIC is ignored).
New format: max_depth, num_mutations, then 4 NUMERICs per mutation (rung_idx, block_idx, param_idx, delta) for a total of 2 + 4×N. ParseMutationSpecs rejects num_mutations < 1 or > 64.

Wire Format Breakdown

0x0402 0 4 NUMERIC · max_depth NUMERIC · block_idx NUMERIC · param_idx NUMERIC · delta Conditions (legacy) = 24 bytes

0x0402 0 0 Witness = 4 bytes

Total 28 bytes (legacy, single mutation)

Evaluation Logic

1.Collect all conditions NUMERIC fields and dispatch to ParseMutationSpecs. Returns false → ERROR (covers: fewer than 4 NUMERICs, undecodable values, num_mutations outside [1, 64], or insufficient trailing NUMERICs for the declared mutation count).

2.If max_depth ≤ 0 → UNSATISFIED

3.Dispatch VerifyMutatedLeaves(ctx, mutations). Requires both ctx.input_conditions and ctx.spending_output; missing → ERROR

4.For each mutation: bounds-check rung_idx against verified_leaves.total_rungs (or input_conditions.rungs in fallback). Out of range → UNSATISFIED. Cross-rung mutations require the spender to have supplied the target rung in revealed_mutation_targets; the evaluator verifies ComputeTxMLSCLeaf(target.rung) matches what the conditions_root committed to (audit 8b F1).

5.Apply each mutation: locate the param_idx-th condition field (post-fold; PUBKEYs already stripped). Must be NUMERIC. Mutate value ← value + delta. Mutating a non-NUMERIC slot → UNSATISFIED; missing slot → UNSATISFIED

6.Recompute the expected MLSC root: BuildCPRung + ComputeTxMLSCLeaf for the mutated rung, then ComputeExpectedRoot to splice into the verified-leaves tree (leaf-centric path) or ComputeConditionsRootMLSC over the mutated full conditions (fallback path).

7.Extract the spending output's MLSC root via GetMLSCRoot. Non-MLSC output → UNSATISFIED. Compare against the expected root; equal → SATISFIED; differs → UNSATISFIED

Worked Example

Decrementing a counter: rung 0, block 1, param 0, delta = -1

Input has param[0][1][0] = 5. Expected output param = 5 + (-1) = 4.

max_depth = 10 > 0 → proceed

Target: rung=0, block=1, param=0, delta=-1

Output param[0][1][0] = 4 == 5 + (-1) → SATISFIED

Output tries delta = -2 instead of -1:

Output param[0][1][0] = 3 ≠ 5 + (-1) = 4 → UNSATISFIED

JSON Wire Format

{
  "type": "RECURSE_MODIFIED",
  "fields": [
    { "type": "NUMERIC", "value": 10 },
    { "type": "NUMERIC", "value": 1 },
    { "type": "NUMERIC", "value": 0 },
    { "type": "NUMERIC", "value": -1 }
  ]
}

Legacy format shown: max_depth=10, target rung 0 (implicit) block 1 param 0, delta=-1 (decrement by 1 each spend).

Use Cases

Decrementing Counters

A covenant parameter decreases by 1 each spend. When it reaches 0, another block (e.g., a conditional check) can trigger a different execution path. Useful for countdown-gated releases.

Progressive Timelock Relaxation

Each spend reduces a CSV timelock parameter by a fixed amount, progressively shortening the required wait between spends. Creates a decaying cooldown curve over the covenant chain.

Evolving Covenant Parameters

Any numeric parameter in the covenant can be systematically evolved. Threshold values, ratios, or counts can increase or decrease with each spend according to a deterministic schedule.

← RECURSE_SAME RECURSE_UNTIL →