TYPE 0x0406 · RECURSION FAMILY

RECURSE_DECAY

Decaying covenant. Like RECURSE_MODIFIED but with negated deltas — targeted parameters decrease on each spend. Creates diminishing restriction curves where covenant parameters weaken over successive spends. No Tapscript equivalent.

Recursion Invertible

Ladder Diagram

Fields

Field	Data Type	Size	Side	Description
max_depth	NUMERIC	1-4 B	Conditions	Maximum recursion depth (> 0). Bounds the chain of decaying spends.
block_idx	NUMERIC	1-4 B	Conditions	Target block index within rung 0 (legacy) or per-mutation target (new format).
param_idx	NUMERIC	1-4 B	Conditions	Target parameter index within the block.
delta	NUMERIC	1-4 B	Conditions	Decay amount. Negated before applying: effective change is `-delta` per spend.

Field layout matches RECURSE_MODIFIED exactly. Both legacy (4 NUMERICs, rung 0 implicit) and new (2 + 4N NUMERICs) formats are supported. The only difference is that delta is negated before application.

Wire Format Breakdown

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

0x0406 0 0 Witness = 4 bytes

Total 28 bytes (legacy, single mutation)

Evaluation Logic

1.Collect all conditions NUMERIC fields and dispatch to ParseMutationSpecs (identical to RECURSE_MODIFIED). Returns false → ERROR

2.If max_depth ≤ 0 → UNSATISFIED

3.Negate every mutation's delta in-place (m.delta = -m.delta). The on-chain encoding still reads as a positive "decay amount", but the actual mutation applied is subtractive.

4.Dispatch VerifyMutatedLeaves(ctx, mutations) — same path as RECURSE_MODIFIED. For each mutation: bounds-check rung_idx, locate the param_idx-th post-fold NUMERIC field in blocks[block_idx] (NUMERIC type required), apply value ← value + (-delta).

5.Recompute the expected MLSC root from the mutated rung (leaf-centric or fallback) and compare against the spending output's MLSC root. Equal → SATISFIED; any mismatch (incl. non-MLSC output, missing slot, non-NUMERIC target) → UNSATISFIED

Worked Example

Decaying timelock: target param is CSV value=100, delta=10

Each spend reduces the timelock by 10 blocks.

Spend 1: CSV=100, effective_delta=-10, output CSV must be 90 → SATISFIED

Spend 2: CSV=90, output CSV must be 80 → SATISFIED

Spend 10: CSV=10, output CSV must be 0 → SATISFIED

Output tries to keep CSV unchanged:

Input CSV=100, output CSV=100 ≠ 100 - 10 = 90 → UNSATISFIED

JSON Wire Format

{
  "type": "RECURSE_DECAY",
  "fields": [
    { "type": "NUMERIC", "value": 20 },
    { "type": "NUMERIC", "value": 2 },
    { "type": "NUMERIC", "value": 0 },
    { "type": "NUMERIC", "value": 10 }
  ]
}

Legacy format: max_depth=20, target rung 0 (implicit) block 2 param 0, delta=10 (decreases by 10 per spend). After 20 spends the depth limit is reached.

Use Cases

Diminishing Restrictions

Security restrictions that progressively relax over time. A new wallet might require a 144-block CSV delay that decreases by 6 blocks per spend, gradually increasing spending flexibility as trust is established.

Progressive Unlocking

A multisig threshold that decays from 3-of-5 toward 1-of-5 over successive spends. Early spends require strong quorum; later spends allow single-signer control as the covenant matures.

Decay Curves for Time-Value

A RELATIVE_VALUE ratio parameter that decays each spend, allowing progressively larger fee extraction. Initial spends preserve 99% of value; after N decay steps, preservation drops to 90%, creating a controlled value release schedule.

← RECURSE_SPLIT ANCHOR →