limenka fork specification

0. nomenclature

• spamchain: the incumbent bitcoin chain (BTC)
• fork: this chain
• interval: a block version's target time between blocks, in seconds
• tier: synonym for interval in the context of proportional resource allocation
• VDF: verifiable delay function

1. block intervals

1.1 eight-way block version scheme

three bits in the block version field designate which of eight interval tiers the block belongs to.

version bits[2:0]	interval (seconds)	interval (minutes)
0b000	32	~0.53
0b001	64	~1.07
0b010	128	~2.13
0b011	256	~4.27
0b100	512	~8.53
0b101	1024	~17.07
0b110	2048	~34.13
0b111	4096	~68.27

1.2 interval designation

interval designation is committed in the coinbase transaction, not in the block header. this avoids enlarging the block header and keeps interval selection opaque to header-only validation.

1.3 expected block cadence

the aggregate reward and capacity targets are 10 minutes, identical to spamchain's schedule (see 2.1, 2.2). each interval tier targets its own raw cadence:

• 32s blocks target 1 per 32 seconds
• 4096s blocks target 1 per ~68 minutes
• raw aggregate production is ~37 blocks per 10 minutes; reward- and capacity-weighted production is exactly 1 standard block per 10 minutes

2. reward and block size proportionality

2.1 reward

each interval tier receives a coinbase reward proportional to its interval:

reward(tier) = total_subsidy * (interval / 600) * (1/8)

the 1/8 normalization (one per interval tier) makes total emission track bitcoin's schedule: every tier emits subsidy/4800 per second, eight tiers together emit subsidy/600 per second - exactly one standard reward per 10 minutes. the interval cancels out of the per-time emission, so the tier range (32..4096) does not affect the emission rate; only the tier count does.

total_subsidy follows the same halving schedule as spamchain (50 BTC initial). halving is counted in reward-equivalent aggregate blocks: one aggregate block = 600 seconds of emission, so 210,000 aggregate blocks elapse in 4 years regardless of the raw block rate (37.4 raw blocks per 10 minutes at 32..4096).

a 32-second block receives 32/600/8 = 0.67% of the standard reward. a 4096-second block receives 4096/600/8 ≈ 0.85x the standard reward. proportions between tiers are unchanged, so miner interval selection (5.1) is unaffected.

2.2 block size limit

block size limit is proportional to interval:

max_block_size(tier) = base_size * (interval / 600) * (1/8)

normalized by tier count so aggregate capacity per unit time tracks the base schedule: eight tiers together move base_size/600 per second, one base block's worth per 10 minutes.

a 32-second block has 0.67% of the base block capacity. a 4096-second block has ~0.85x the base block capacity.

2.3 natural mempool stratification

short-interval blocks have small capacity and small rewards. they attract urgent, high-fee transactions (lightning channel opens, closes, HTLC settlements). long-interval blocks have large capacity and large rewards. they absorb bulk transactions and confidential transactions.

the fee market self-organizes across tiers without explicit mechanism. transactions that value speed bid into the short-interval blocks. transactions that value capacity bid into the long-interval blocks.

3. VDF reorg bound

3.1 delay-function VDF

the VDF MUST be a real delay function: a computation that provably requires wall-clock time, cannot be parallelized, and cannot be shortcut by precomputation or by hashpower. a bare sequential hash chain (VDF_n = H(VDF_{n-1} || block_data_n)) executes in microseconds, provides no reorg bound whatsoever, and is not a VDF. it must not be used.

candidate constructions:

• repeated squaring in an RSA group with Wesolowski-style compact proofs
• other verifiable delay functions with an explicit delay parameter

the delay parameter D (target wall-clock seconds per VDF step) is a consensus constant. the VDF output is committed in the coinbase transaction; verification uses the compact proof (logarithmic time), decoupling verify cost from compute cost so small miners can verify every step.

the VDF MUST overlap the PoW search, not serialize after it. the VDF is computed over the block's fixed commitment - previous block hash, transaction merkle root, tier bits - excluding the PoW nonce, so its output does not change during the nonce search. the miner starts the VDF when the candidate block is assembled and searches nonces in parallel; per-block cost is max(PoW_time, D), not PoW_time + D. a serial VDF (computed after the nonce is found) is broken: the attacker with infinite hashrate gains one PoW_time per block over an honest CPU miner, making reorg depth unbounded (3.3).

3.2 asymmetric difficulty

a real VDF is asymmetric: computing one step costs the full delay D; verifying its proof is cheap (logarithmic time). this asymmetry is the feature that bounds reorg depth:

• computing the VDF chain from a fork point to a sidechain head costs L * D wall-clock seconds for anyone, including an attacker
• verifying a step's proof costs microseconds for anyone, including small miners
• the VDF caps block production at 1/D for every miner regardless of hashpower: the fastest any chain can advance is one VDF delay per block

3.3 reorg bound property

a reorg cannot cross a VDF checkpoint. the time cost of recomputing the VDF chain from the fork point to the current head grows linearly with depth, and no amount of hashpower can accelerate it.

an attacker attempting to reorg N blocks deep must spend N * D seconds computing the VDF chain for the sidechain, during which time the honest chain advances. the attacker's sidechain rate is 1/D blocks per second: with the VDF overlapping the PoW search (3.1), even infinite hashpower cannot produce a block faster than one VDF delay.

the honest chain's rate is 1/max(PoW_h, D), where PoW_h is the honest miners' PoW solve time on the fastest tier. the VDF caps every chain at 1/D, so the attacker can never exceed the honest chain's floor - the adversary cannot spend its way through the VDF.

the attacker gains ground only while PoW_h > D: honest blocks then take PoW_h seconds while the attacker's take D. the DAA counteracts this by decaying the difficulty of under-mined tiers (4.4), driving PoW_h back below D. the reorgable depth is therefore bounded by the DAA decay lag - the window during which PoW_h > D after an attack begins - not by hashpower. a low-hashpower honest chain is protected against a massively more powerful adversary as long as the fastest tier's difficulty stays within one CPU's reach.

D is set by simulation (section 11) with the constraint D = T_min (32 seconds) and the DAA target PoW_h <= D on the fastest tier. the reorgable depth during the decay lag must be measured and bounded; shallow reorgs at the tip are possible and are handled by the tie-break and finality rules (3.5).

D cannot be set below T_min. a shorter VDF delay (e.g., 16s with 32s blocks) does not create headroom - it recreates the unbounded-gain regime: the attacker's sidechain runs at 1/D while the honest chain runs at 1/T_min, so the attacker gains one block per T_min * D / (T_min - D) seconds indefinitely. the VDF delay IS the block time floor; there is no slack between them.

3.4 verification for small miners

with compact proofs, verification of each VDF step is logarithmic-time and cheap; small miners verify every step. sampling (e.g., every 50th step) remains a fallback for constrained devices but is not required for confidence in the reorg bound.

3.5 tie-break and settlement finality

at exact parity (sidechain and honest chain at equal work), a tie-break rule must select a winner. the rule:

1. first-seen wins: the honest chain is always seen first because the attacker must withhold a private sidechain to attack, and withholding forfeits first-seen at every height. an attacker who publishes immediately is a miner, not an attacker.
2. spamchain anchor ordering as the deterministic secondary: at equal work, prefer the chain whose most recent anchor (8.1) appears first on spamchain. the honest chain anchors as it mines; a withheld sidechain cannot anchor without revealing itself. faking the order requires out-hashing spamchain (8.2).

settlement finality is defined by the anchor: a fork block whose anchor is buried under X confirmations on spamchain is final, because reorging it requires reorging spamchain itself. the value of X is set by simulation.

4. difficulty adjustment

4.1 PID controller per interval tier

each of the eight interval tiers maintains an independent difficulty target, adjusted by a proportional-integral-derivative (PID) controller.

the PID controller operates on the error signal:

e(t) = target_interval - actual_interval

where target_interval is the tier's nominal interval and actual_interval is the measured time since the last block of this tier.

4.2 PID terms

proportional (P): corrects difficulty in proportion to the current error. this is what bitcoin's DAA already does - if blocks are arriving too fast, difficulty increases.

integral (I): accumulates error over time, creating a gradient correction. if blocks have been arriving too fast for a sustained period, the I term adds correction to eliminate the accumulated offset. this allows difficulty to move freely in response to sustained hashrate changes.

derivative (D): responds to the rate of change of the error. a fixed-point low-pass filter is applied to prevent noise amplification. this enables the fastest response to sudden hashrate changes - the D term detects the gradient of hashrate change before the P or I terms register the displacement.

4.3 difficulty formula

D_new = D_old * (1 + Kp * e + Ki * ∫e dt + Kd * de/dt)

constants Kp, Ki, Kd are tuned for the interval tier and the desired response characteristics.

4.4 anti-stall property

if hashrate drops suddenly, the longest-interval tiers become harder while the shortest-interval tiers become easier. miners shift to the tiers that are mineable. the chain never stalls because:

1. the short-interval difficulty is always reachable by some miner
2. the integral term continuously adjusts difficulty downward for tiers that become unreachable
3. the derivative term detects the hashrate drop immediately and begins correction before blocks are missed

4.5 hit-and-run difficulty inflation and the anchored-tier rule

the cheap attack on this scheme is hit-and-run difficulty inflation on a short tier:

1. attacker floods the 32s tier with hashpower. the attacker is PoW-instant and VDF-bound: they solve the PoW in microseconds and wait out the 32s VDF, producing exactly 1 block/32s. combined with the honest CPU's 1 block/32s, the tier transiently produces at 1/16s.
2. the DAA sees above-target production and raises difficulty. this does NOT slow the attacker (PoW-instant) - it slowly prices out the honest CPU, whose solve time grows past the VDF window.
3. the attacker leaves. the elevated difficulty lingers, and the lane stays degraded for the full decay period. one hour of flooding buys hours of degradation.

difficulty is therefore the attacker's weapon, not their cost - the naive "raise difficulty to price them out" response (previous version of this section) is exactly backwards.

the anchored-tier rule: on tiers where the target cadence is at or near the VDF floor (T_target <= 2*D, i.e. 32s and 64s), the VDF is the rate limiter, not PoW difficulty. nobody can produce a block faster than the VDF regardless of hashrate, so PoW difficulty on these tiers is only a race filter. the DAA fixes difficulty at the one-CPU floor on anchored tiers and never adjusts it. consequences:

• the attacker cannot raise a difficulty the DAA does not move - price-out is structurally impossible
• post-exit recovery is instant: there is nothing to decay, the floor is always in place
• near-simultaneous solves at the floor do not cause orphan churn, because the VDF serializes the race: a miner cannot pre-build the next block until the winner's commitment is known (3.1)
• sustained flooding is the most expensive griefing available: holding the 32s lane locks hashpower into a 0.67%-reward tier while forgoing ~127x per block on the 4096s tier

on 128s and up (T_target > 2*D), the VDF floor is at least 4x below the cadence, PoW difficulty genuinely rate-limits, and the PID adjusts normally.

4.6 stall window

"stall resistance" is measured by the stall window: the wall-clock time from attack exit (or hashrate collapse) to the first honest block at target cadence. on anchored tiers (4.5) the one-CPU floor is permanent by construction - it is not a recovery property, it is the steady state. on adjustable tiers (128s+) the floor is reached only after the integral/derivative terms decay difficulty, and the stall window measures that decay.

the stall window is the key liveness metric and MUST be swept in simulation (section 11): attacker share x attack duration x tier mix, measuring time-to-first-honest-block after exit. the testnet success criterion is a bounded, small stall window under the full-hashpower attack scenario (9.1).

4.7 censorship bound

a majority-hashpower attacker who mines every tier publicly controls inclusion on every tier - a universal property of permissionless chains that cannot be designed away. the fork's guarantee is bounded and honest:

1. denial is impossible: the anti-stall property (4.4) guarantees the chain advances even at one CPU.
2. erasure is impossible: the spamchain anchor (8.1) records the fork's block history on a chain the censor does not control.
3. selective censorship is delay-bounded: any tier the censor leaves decays in difficulty until honest miners solve it, and the fee market (2.3) migrates censored transactions into uncontested tiers. the censorship window - time from censorship to inclusion in an honest block - is bounded by the honest block fraction and the DAA decay rate.
4. sustained censorship is uneconomic: censoring all tiers forever requires out-mining every tier forever at a loss, which is indistinguishable from just being the chain.

the testnet must measure the censorship window under full-hashpower attack (9.1), not assert it.

5. miner interval selection

5.1 rational strategy

miners select which interval tier to mine based on:

expected_profit(tier) = reward(tier) * P(solve) / difficulty(tier)

when all tiers are at equilibrium difficulty, expected profit per hash is equal across all tiers. when a tier lags (blocks arriving slower than target), its difficulty drops, increasing expected_profit(tier). miners shift to that tier.

the rational strategy is essentially random selection weighted by the current reward/difficulty ratios. no coordination is required.

exception: anchored tiers (4.5). the 32s and 64s tiers have difficulty fixed at the one-CPU floor, so the equalization mechanism does not apply to them: expected profit per hash on an anchored tier is independent of the hashrate racing it, because difficulty cannot rise to absorb the competition. the reward per block is fixed and small (0.67% of standard at 32s), so:

• the expected profit per hash on an anchored tier is lower than on an equilibrium-tier at any hashrate, and it falls as more hashpower races it (the block reward is split over more hashes without a compensating difficulty rise)
• a large miner therefore has no incentive to race anchored tiers: the same hashrate earns more per hash on any adjustable tier
• anchored tiers self-select for small, latency-sensitive miners (and the one-CPU floor makes them always winnable), which is the intended role of the fast lanes: they carry lightning traffic, not bulk hashrate

this is not an arbitrage hole. it is the design: the fast lanes are deliberately unprofitable at scale so that bulk hashpower settles on the long tiers, where it belongs.

5.2 arbitrage against variance

short-interval tiers have higher variance in block arrival times. the difficulty adjustment smooths this variance by making the tier more attractive when it lags and less attractive when it leads. miners arbitraging between tiers naturally dampen oscillation.

6. transaction types

6.1 legacy and segwit

standard bitcoin legacy (P2PKH, P2SH) and segwit (P2WPKH, P2WSH) transaction types are supported. witness versions 0 through 2 operate as on spamchain.

6.2 P2SPKH - pay to schnorr public key hash

witness version: 3

output script: OP_0 <32-byte-witness-program> (as with segwit versioning)

the witness program is:

witness_program = SHA256d(schnorr_pubkey)

where SHA256d is SHA-256 applied twice, identical to bitcoin's HASH256 construction.

spend witness:

witness = <64-byte-schnorr-signature> <32-byte-schnorr-pubkey>

the pubkey is revealed only at spend time. the signature is a standard schnorr signature (64 bytes, no DER encoding). verification computes SHA256d(pubkey) == witness_program and validates the schnorr signature against the transaction.

quantum resistance: with 32-second blocks possible, the exposure window for a quantum attack on the SHA256d layer is approximately 60 seconds (one confirmation plus propagation). this is acceptable. the pubkey is only briefly exposed during spend.

6.3 P2BPCT - pay to bulletproof confidential transaction

witness version: 4

output script: OP_0 <32-byte-witness-program>

the witness program commits to a bulletproof range proof and a confidential amount.

properties:

• amounts are hidden: only the sender and receiver know the transfer amount
• origin addresses are obfuscated
• the sum of inputs and outputs remains auditable (bulletproofs are additively homomorphic)
• coinbase outputs MUST NOT use P2BPCT, as coinbase amounts must be publicly verifiable for monetary audit

block placement: P2BPCT transactions are only mined in intervals >= 512s. rationale:

1. short blocks are the latency lane for lightning/ARK channel opens and closes - the fork's headline feature. a CT-eligible short block creates a crowding attack surface: a pool with majority short-block hashrate can fill its own blocks with its own CTs at self-paid fees, delaying time-sensitive settlement traffic. keeping CTs out of short blocks removes that griefing vector.
2. CTs are bulk transactions - they want capacity per byte, which short blocks cannot offer (26.7KB at 32s vs 3.5MB at 4096s). the floor aligns the class with the blocks that serve it; legitimate CT users lose nothing, and the long-interval blocks give CTs their natural preference for bulk settlement.
3. validation time is NOT the constraint (measured: ~50ms for a full CT block at 32s, ratio ~0.16% of interval at every tier). stated here to preempt the wrong justification - the floor is policy against time-sensitive-traffic crowding, not a computational limit.

6.4 OP_RETURN

standard OP_RETURN with a maximum payload size to be determined. used for data anchoring.

7. replay protection

7.1 replay vector

an inherited UTXO is spendable on both chains — same outpoint, same key, same sighash rules. a fork transaction spending an inherited UTXO is valid on the parent chain. a parent transaction spending the same UTXO is valid on the fork. bidirectional replay, no exception. "visible but unspendable" inherited UTXOs is not implementable — if you hold the key, the parent chain still honors it.

7.2 forkid sighash

every transaction signature on the fork commits to a fork identifier (FORK_ID) in the sighash preimage. a transaction whose signatures do not commit to FORK_ID is consensus-invalid on the fork.

on the parent chain, forkid-committing transactions are invalid because the fork's sighash commits to FORK_ID in the preimage. the parent node computes the preimage without FORK_ID; the signature fails to verify normally. invalidity is cryptographic (preimage mismatch), not an explicit rejection rule.

result: fork transactions cannot replay to the parent chain; parent transactions cannot replay to the fork; inherited UTXOs become safely spendable on the fork with no parent side effect.

7.3 sighash preimage

the fork id is 0x424636f6 ("BF6o"). it is committed to the sighash preimage per signature type:

• P2SPKH (witness v3): uses SigVersion::TAPROOT sighash (BIP341). FORK_ID is appended as an additional preimage field before the final hash.
• legacy (P2PKH, P2SH): FORK_ID is hashed into the preimage.
• segwit v0 (P2WPKH, P2WSH): FORK_ID is hashed into the BIP143 preimage.
• taproot spends (inherited UTXOs): FORK_ID is committed into the taproot sighash preimage.

7.4 mempool inheritance

inherited parent-chain mempool transactions are all invalid on the fork — they do not commit to FORK_ID. a cold-start fork node's mempool is empty and fills only from fork-native broadcasts. imported parent mempool dumps are rejected. this is correct behaviour: inherited coins are spendable on the fork, but only with fork-native transactions.

8. coinbase layout

8.1 coinbase input scriptSig

the coinbase transaction's single input has a scriptSig with the following layout:

[BIP34_block_height_push] [interval_byte] [extra_nonce...]

• BIP34_block_height_push: the block height, encoded as a CScriptNum push (standard BIP34)
• interval_byte: 1 byte, interval tier encoded in bits[2:0], bits[7:3] zero
• extra_nonce: arbitrary bytes for miner nonce extension

the interval byte is consensus-validated: it must match the interval tier encoded in the block version's low 3 bits.

8.2 VDF output

the VDF output and proof are placed in a dedicated coinbase output:

OP_RETURN <"BF"> <y> <π>

where:

• "BF" is the two-byte marker 0x42 0x46 identifying this as a fork VDF commitment
• y is the full VDF output value, serialized as a bytestring. size is construction-dependent: 256 bytes for RSA-2048, 128 bytes for class-group ~1024-bit
• π is the Wesolowski-style compact proof: one group element. size is construction-dependent: 256 bytes for RSA-2048, 128 bytes for class-group ~1024-bit

ℓ (the challenge prime) is not stored in the coinbase. it is derived by the verifier via ℓ = HashToPrime(x, y) where x is the VDF input and y is the output committed in this output. the VDF input x is derived from the block's prev_hash and version_tier_bits (see §3.1).

total coinbase payload: 2 + OutputSize() + ProofSize(). 514 bytes for RSA-2048, 258 bytes for class-group.

standardness: the fork's policy sets the OPRETURN relay limit at 550 bytes. consensus never capped OPRETURN at 83 bytes — that was standardness policy, and the fork defines its own policy.

validation: nodes verify the VDF proof against the fixed commitment prev_hash || version_tier_bits. verification is ~10-20ms. invalid VDF proof blocks are rejected in CheckBlock.

rationale for dedicated output: the VDF proof is placed in its own coinbase output rather than the coinbase witness. using the witness couples the VDF to BIP-141 commitment machinery, which is itself committed in the block header — creating circularity in the reorg-bound-critical path. a first-class coinbase output keeps the VDF verification independent of the witness commitment.

9. taproot ban

9.1 taproot outputs prohibited

witness version 1 (taproot) outputs are invalid on the fork. nodes reject blocks containing taproot outputs.

9.2 spend path restriction

taproot UTXOs from spamchain (pre-fork) may be spent into legacy, segwit, P2SPKH, or P2BPCT outputs. they cannot be spent into new taproot outputs. this ensures the UTXO set gradually purges taproot.

9.3 rationale

taproot's script tree (MAST) allows arbitrary commitment structures that cannot be audited without the spender's cooperation. this is an information asymmetry that prevents sovereign verification of the chain's total liabilities. script trees are a bilateralism (wood) without sovereignty (earth) problem.

additionally, taproot enables arbitrary witness program embedding, which is the mechanism used for ordinals, inscriptions, BRC-20, and other spam token schemes. banning taproot eliminates these at the consensus layer.

lightning and ark function without taproot. P2SPKH and legacy script types support all necessary channel constructions.

10. fork mechanics

10.1 testnet phase

the fork launches as a testnet. the invitation to attack is open. spamchain mining pools are encouraged to attempt stall, reorg, and censorship attacks.

stall and capture are distinct attacks: stall means preventing honest block production; capture means controlling the chain's transaction flow with majority hashpower. the testnet criteria test survival of the honest chain under full-hashpower attack (stall resistance) and must additionally test reorg resistance: an adversary with massive hashpower attempting deep reorgs beyond the VDF bound must fail within the bound. with the fork's native hashpower far below the adversary's, the VDF delay is the only thing standing between a shallow reorg and a deep one - this is the property the testnet must prove, not assert.

10.2 shared mempool and UTXO set

at fork point, the UTXO set and mempool are shared with spamchain. any UTXO valid on spamchain at the fork height is valid on the fork. any transaction valid on spamchain's mempool is valid on the fork's mempool (subject to the taproot output ban).

10.3 custodian and lightning node transition

lightning channels and ark rounds that are valid on spamchain are also valid on the fork at the moment of the fork. channel opens and closes can be executed on the fork with 32-second block times, providing a material settlement speed improvement.

custodians and lightning service providers can transition without coordinating with each other - they simply submit transactions to both chains and whichever chain clears first wins.

10.4 coinbase as value differentiator

at fork point, the UTXO set is identical on both chains. the only economic difference between the chains is the new coinbase rewards mined on each. the fork's new coinbases are the differentiator that gives the fork its own economic identity.

over time, coinbase outputs accumulate in the UTXO set. these outputs are native to the fork and do not exist on spamchain. they are the foundation of the fork's independent monetary base. every subsequent transaction that spends a fork coinbase output creates value that is unambiguously tied to the fork.

this is how the fork transitions from parasitic to sovereign: the initial shared UTXO set (borrowed economic gravity) is gradually diluted by new coinbase outputs (native economic gravity). once a majority of active UTXO value originates from fork coinbases, the fork's monetary base is self-sustaining and no longer dependent on spamchain's UTXO distribution.

10.5 UTXO divergence

over time, the UTXO sets diverge as:

• taproot outputs are only spent (not created) on the fork
• P2SPKH and P2BPCT outputs are only created on the fork
• fork coinbase outputs exist only on the fork
• spamchain coinbase outputs exist only on spamchain
• transaction ordering differs between chains

the chains become non-fungible once the UTXO sets have diverged sufficiently and fork coinbases represent a meaningful fraction of active UTXO value.

11. success criterion

the testnet is considered proven if it operates under the following conditions:

1. a CPU miner can produce blocks
2. the chain withstands the full hashpower of a spamchain mining pool applied for 5 minutes
3. the stall window after attack exit is bounded and small (defined in 4.6, target from simulation)
4. all eight interval tiers produce blocks at their target cadence under variable hashpower
5. deep reorgs beyond the VDF bound fail under full-hashpower attack; reorgable depth is bounded and shallow per section 3.3
6. the censorship window under full-hashpower attack is bounded and small (4.7)

12. unresolved parameters

the following constants require specification through simulation or empirical testing:

parameter	description
Kp, Ki, Kd	PID constants per interval tier
D low-pass filter cutoff	derivative term smoothing
base block size	base block capacity for proportional scaling
VDF delay parameter	wall-clock seconds per VDF step; D = Tmin (32s); must not be set below Tmin (3.3); overlap with PoW search required (3.1)
VDF construction	RSA repeated squaring with Wesolowski proofs vs alternatives; to be validated by simulation
DAA PoW target	DAA must keep PoW_h <= D on the fastest tier so parity holds (3.3)
stall window target	max acceptable wall-clock between attack exit and first honest block (4.6)
reorg depth bound	maximum reorgable depth during the DAA decay lag, measured by simulation (3.3)
tie-break rule	first-seen, then spamchain anchor ordering (3.5)
anchor finality depth	X spamchain confirmations for settlement finality (3.5)
censorship window target	max acceptable time from censorship to inclusion in an honest block (4.7)
OP_RETURN max payload	maximum OP_RETURN size
P2BPCT min interval	minimum interval tier for confidential transactions; set by validation budget (6.3); nominal 512s for capacity granularity, not validation binding
fork activation height	spamchain block height for fork activation