Elektron Net Security – Elektron Net

A Structurally Bounded Approach to Blockchain Security

Elektron Net introduces a consensus mechanism that changes how trust and security operate in distributed ledger systems. Unlike traditional blockchains that rely on infinite historical records, Elektron Net achieves structurally bounded security through a combination of cryptographic attestations, local verification, and decentralized checkpointing.

The Fundamental Weakness in Bitcoin’s Security Model

Bitcoin’s Vulnerability: The Silent Genesis Attack

In Bitcoin, an attacker can theoretically mine an alternative chain in secrecy for years, starting from the genesis block. Because Bitcoin’s security model relies on the “longest chain” with the most cumulative Proof-of-Work (PoW), the network accepts any chain that eventually accumulates more total work than the main chain.

The Attack Vector:

Attacker: Mines in secret from Block 0 → Block 1 → ... → Block N (over years)
Main Network: Continues its legitimate chain → ... → Block M (current)

When attacker's chain has more total PoW:
    → Bitcoin nodes reorganize to the heavier chain
    → Transaction history since the fork point is rewritten
    → Balances since the fork point are reversed

Why This Works in Bitcoin:

Bitcoin has unbounded historical depth
A node performing a full validation from genesis cannot distinguish a “real” chain from a “replayed” genesis chain on cryptographic grounds alone — only accumulated work decides
The main protection is the enormous cost of accumulating more PoW than the honest network has produced

In practice, this attack is already considered infeasible on Bitcoin today, simply because matching years of global hash power is economically prohibitive — and Bitcoin Core itself softens the theoretical risk with assumevalid and historical checkpoints. But the underlying design still permits unbounded-depth reorganization in principle, and a fully validating node must be able to hold and verify the entire history to participate without any shortcuts.

Elektron Net: Bounding the Time Window

The 137-Day Pruning Window as a Hard Limit

Elektron Net introduces a different security model based on finite historical depth. The pruning window of 197,280 blocks (~137 days) creates a closing time window that makes a long-term secret-mining attack structurally unavailable, not just expensive.

The Core Principle:

Pruning Window: 197,280 blocks ≈ 137 days
Checkpoint Interval: Every 197,280 blocks
MANDATORY_PRUNE_DEPTH: 197,280 (enforced in validation.h)

After 137 days:
    → Block data older than the window is pruned network-wide
    → A cryptographic checkpoint is sealed and stored locally
    → A fork starting before the last checkpoint requires raw block data that
      no longer exists anywhere on the network, so it cannot practically be
      reconstructed or served to other nodes

Important precision: chain selection currently works like Bitcoin — a node adopts whichever valid chain has the most cumulative proof-of-work, based on the header chain (which is never pruned). Today there is no separate consensus rule that inspects a chain’s fork height against the last checkpoint and rejects it outright; what prevents a pre-checkpoint fork from being adopted in practice is that the raw block data required to validate and reorg onto it no longer exists anywhere on the network. This is already a meaningful protection, since producing such a fork would cost an attacker at least as much real proof-of-work as attacking Bitcoin itself — the checkpoint doesn’t make that cheaper.

A dedicated consensus-level enforcement is planned as a hardening layer on top of this: an explicit height check that rejects any competing chain forking before the local node’s last sealed checkpoint outright, rather than relying only on data unavailability to make such a fork impractical. This closes the remaining edge case where a node’s own software would otherwise need to handle a reorg reaching past its retained data — instead of falling back to an error state, the node will simply refuse the fork by rule, the same way a hardcoded checkpoint historically did in early Bitcoin Core, but derived from the node’s own verified state rather than a value shipped by the developers.

Why the Time Window Closes Off the Attack

The Attacker’s Dilemma:

The Clock Is Ticking:

To launch a long-range attack, the attacker must start from Block 0 (or an earlier checkpoint) and build an alternative chain.
The honest network continues mining 60-second blocks without interruption.
The attacker must catch up to and surpass the current chain height before pre-checkpoint history is pruned network-wide.

The Checkpoint Mechanism:

Every 137 days, the network seals a cryptographic checkpoint.
Once a checkpoint is sealed and verified by nodes:
- It is stored locally as a .dat file with a .hash sidecar
- It is cryptographically bound to the on-chain UTXO attestation
- A chain forking before this checkpoint would need raw block data that no longer exists anywhere on the network — this is what makes such a fork practically unreconstructable, not a dedicated consensus rule that checks fork height against the checkpoint

The Practical Constraint:

Attacker's Chain: Starts at Block 0 → Must reach Block N (current height)
Honest Network: Continues from Block N → Block N+1 → Block N+2 (every 60s)

To succeed, an attacker must:
- Generate more blocks than the honest network before the next checkpoint seals
- Match the honest network's block rate over the whole window, or
- Achieve enough total PoW despite a lower block rate
- Do all of this before the pre-checkpoint history is pruned away

The Difference from Bitcoin:

Aspect	Bitcoin	Elektron Net
Attack Duration	Can mine in secret indefinitely (economically discouraged)	Must complete within 137 days (structurally bounded)
Chain Acceptance	Accepts the chain with the most cumulative work	Same rule — most cumulative work wins — but a pre-checkpoint fork can’t practically be served or reorged onto, since the required block data is gone
Time Pressure	Economic only – attacker can in principle wait	Structural – the pre-checkpoint data window closes
Checkpoint Protection	Optional / soft (`assumevalid`, hardcoded checkpoints)	Mandatory checkpoints every 137 days for fast sync, verified against on-chain attestation — not a hard consensus rule against deep reorgs

The Computational Floor: PoW + Attestation

Why Producing a Valid Alternative Chain Requires More Than Hashing

In Bitcoin, producing a valid block header only requires satisfying the nBits difficulty target. In Elektron Net, every block must also contain a valid UTXO attestation, which requires computing the full resulting UTXO state.

Technical Implementation:

// From src/validation.cpp
bool ValidateUTXOCheckpoint(const CBlock& block, CCoinsViewCache& view) {
    // 1. Apply all transactions in the block
    UpdateCoins(block, view, ...);
  
    // 2. Compute UTXO attestation (HASH_SERIALIZED 
    // pre-activation / height < 137,000; 
    // incremental HASH_MUHASH post-activation)
    uint256 computed_hash = ComputeBlockUTXOAttestationHash(block,
    view, consensus_params);
  
    // 3. Extract the attestation from the coinbase
    uint256 attestation = ExtractCoinbaseUTXOAttestation(block);
  
    // 4. Reject if they don't match
    if (computed_hash != attestation) {
        return error("bad-utxo-attestation");
    }
    return true;
}

Update (as of height 137,000): The argument below describes attestation cost before the MuHash activation (HASH_SERIALIZED, full UTXO scan per block). Since height 137,000, attestation is computed incrementally (MuHash3072), at O(1) cost per block instead of a full rescan. The computational bottleneck described here no longer applies to current blocks in this form — it remains relevant for a full cold-start node rebuild and for checkpoint snapshots below height 137,000.

What This Requires, for Anyone Producing Blocks (pre MuHash):

Each Block Requires a Full State Transition:

Process every transaction in the block
Update the UTXO set (add/remove outputs)
Compute the serialized hash of the entire UTXO set (pre MuHash)
This is not a lightweight operation

State Computation Is Inherently Sequential:

UTXO state depends on the previous block’s state
Unlike PoW hashing, which parallelizes trivially, attestation computation is serial by nature
Anyone extending a chain — honest miner or attacker — must maintain a complete UTXO database for that chain

Two Requirements Per Block:

For each block on any chain:
┌─────────────────────────────────────────────────────┐
│ 1. Perform PoW hash (GPU/ASIC)                               │
│ 2. Compute full UTXO attestation (CPU/RAM bound)             │
│ 3. Both must be correct for the block to be valid            │
└─────────────────────────────────────────────────────┘

Why This Doesn’t Favor Just Adding More Hardware:

PoW computation scales well with specialized hardware (ASICs)
Attestation computation is stateful and memory-bound, and doesn’t benefit from ASIC-style parallelization the same way
Extra hash power alone doesn’t shorten the time needed to compute UTXO state — that floor applies equally to the honest network and to any competing chain
This means raw hash-power advantage doesn’t translate one-to-one into a faster alternative chain, since the state computation is a shared bottleneck, not one an attacker can uniquely optimize away

The Race Against the Pruning Window

Illustrative Numbers:

Honest Network:
- Block time: 60 seconds
- Blocks per day: 1,440
- Blocks in 137 days: 197,280

For an attacker's alternative chain to be viable, it would need to:
1. Generate at least as many valid blocks as the honest chain
   → Sustain roughly 1,440 blocks/day
   → Do so with correct PoW at that rate

2. For each block, correctly compute:
   - PoW (ASIC/GPU intensive)
   - UTXO attestation (CPU/RAM intensive, not ASIC-parallelizable)
   - Neither requirement can be skipped

3. Do all of this before the next checkpoint seals, at which point
   the pre-checkpoint data the attacker's chain would need to fork from
   is no longer available on the network

Stoic Awakening: Countering Timestamp Manipulation

The Dynamic Difficulty Response

Stoic Awakening is an emergency recovery mechanism that activates when a block’s timestamp deviates too far from the expected 60-second target. It’s primarily a liveness safeguard (so the network doesn’t stall if hash power drops suddenly) — but it also closes off one route an attacker might otherwise try: slowing down block production on an alternative chain to stay under the radar.

The Mechanism:

// From src/pow.cpp
bool PermittedDifficultyTransition(const CBlockHeader& block, ...) {
    // If time since last block exceeds 120 seconds (2× target)
    if (time_since_last_block > 120) {
        // Next block may be mined at minimum difficulty
        return true;
    }
    return false;
}

Why This Matters for an Attacker:

The Trade-off:

If an attacker tries to stretch time between blocks on a competing chain, this activates Stoic Awakening
This allows any miner to produce blocks at minimum difficulty
The honest network can quickly recover throughput with cheap, low-difficulty blocks

Timestamp Consistency Matters:

Honest nodes are synchronized with real-world time (via NTP)
Timestamps on an alternative chain that don’t track real elapsed time will look anomalous when compared against local clocks

What This Looks Like:

Example of an inconsistent chain:
Block 100 → Timestamp: Day 1, 00:00:00
Block 101 → Timestamp: Day 1, 00:00:03 (unnaturally fast)
Block 102 → Timestamp: Day 1, 00:02:00 (Stoic Awakening triggered)
→ Nodes comparing against real time see the discrepancy
→ Peers following the honest chain won't adopt this chain's timestamps as valid history

Net Effect:

Slowing block production down triggers Stoic Awakening, which helps the honest network recover pace rather than the attacker
Speeding it up unnaturally produces timestamps that don’t track real elapsed time
An attacker trying to mimic the honest network’s rhythm has to actually match its real-time block production — timestamp games don’t provide a shortcut

The Combined Effect

Three Layers Working Together:

Time Constraint (137-day window):

A long-range attack has to finish before the next checkpoint
The checkpoint seals the state, and pre-checkpoint data becomes unavailable network-wide

Computational Floor:

Both PoW and attestation must be correct for every block
Neither can be skipped or meaningfully sped up with more hardware alone

Stoic Awakening:

Discourages timestamp manipulation as a way to stay under the radar while mining slowly

Attack Vectors and Why They Don’t Work:

Attack Vector	Why It Doesn’t Work
Long-term mining in secret	Pre-checkpoint data is pruned after the window closes (137 days)
Fast mining to catch up	Still bound by the same PoW + attestation computational floor as the honest network
Slow mining to avoid detection	Triggers Stoic Awakening, letting the honest network recover pace
Fake timestamps	Detectable against real-world clock time
Skipping attestations	Blocks rejected with `bad-utxo-attestation`
Fabricating attestations	Requires actually computing the full UTXO state — can’t be faked without doing the work

Local Checkpoint Verification

How Nodes Establish Their Own Verified State

Initial Sync:

New Node:
├─ Downloads and validates the full header chain from genesis (headers are never pruned)
├─ Downloads the most recent UTXO snapshot (.dat) and sidecar (.hash) from peers
├─ In the current implementation: accepts the hash from the first peer that responds,
│  verified only for internal consistency (does the downloaded content match that hash),
│  not against the chain — see the confirmed gap noted below
└─ Stores it locally

Continuous Validation:

Node Running:
├─ Receives new block
├─ Verifies the block's UTXO attestation matches its own computed state
├─ Validates PoW is correct
├─ Updates its local UTXO set
├─ If a block fails ANY check → rejects it immediately
└─ Node maintains its own independently verified state going forward

Checkpoint Immutability, Going Forward:

Every 197,280 blocks:
├─ Node writes a local checkpoint (.dat + .hash)
├─ Verifies it against the on-chain attestation
├─ Stores it
├─ This checkpoint becomes the node's reference point for future verification
└─ A fork starting before it would need block data that's gone network-wide —
   there's no separate rule rejecting such a fork by height, the data for it
   simply isn't retrievable from any honest or dishonest peer

One Honest Caveat:

Confirmed gap in the current implementation (fresh bootstrap path): The code has been checked directly, and this is not a theoretical concern. In net_processing.cpp, the first UTXOSNAPSHOT response received for a checkpoint sets the expected UTXO hash unconditionally — there is no cross-check against other peers. In init.cpp, MaybeActivateAutomaticSnapshot only verifies that hash against the checkpoint block’s on-chain coinbase attestation if the block body happens to already be on local disk. For a freshly bootstrapping node — the primary use case this mechanism exists for — the checkpoint block body is by definition not yet downloaded, so this verification step is skipped entirely, logged as “will verify snapshot content against .hash sidecar,” and activation proceeds anyway.

The ActivateSnapshot step does confirm the checkpoint header is genuine and part of the heaviest known chain (real PoW, not fakeable). But that only proves the block’s identity, not its contents. A peer could serve a legitimate header at that height alongside a fabricated but internally self-consistent .dat/.hash pair, and a fresh node has no code path in this version that would catch the mismatch before activating it.

This is a real, fixable gap rather than a fundamental limitation — the natural fix is to fetch and verify just the checkpoint block’s coinbase transaction (not the full historical chain) before trusting the snapshot hash, even during fresh bootstrap. Until that exists, the honest characterization is that new nodes currently trust the first peer to respond to GETUTXOSNAPSHOT, checked only for internal consistency, not against the chain.

A separate, softer note: even with that fix in place, a node’s own previously-sealed checkpoints, once verified, can’t be overridden after the fact. And chain selection itself has no dedicated rule rejecting forks by checkpoint height — it works like Bitcoin, most cumulative work wins — so a pre-checkpoint fork is blocked in practice by data unavailability and PoW economics, not by a special consensus rule.

What’s genuinely true once a node has synced:

For a checkpoint the node sealed itself while running (not downloaded as a bootstrap snapshot), it was verified against the on-chain attestation at the time it was accepted — this part is solid
Every subsequent block has been independently validated using the node’s own computation
Its UTXO set is cryptographically linked to that checkpoint
No peer can talk that node into silently accepting a contradictory history after the fact — it will simply reject conflicting blocks

Concrete Attack Scenarios

Scenario 1: The “Genesis Replay” Attack

Attack Description:

Attacker starts a secret chain from Block 0
Mines for 100 days at 1.5x the honest network’s hashrate
Attempts to present the chain as the “true” history

Why It Doesn’t Work:

Time Window:
- Attack duration: 100 days (within the 137-day window)
- But the next checkpoint arrives in 37 days
- The attacker needs to catch up before that checkpoint seals
The Checkpoint Catch-Up:

Honest Network: On Day 137 → Checkpoint sealed, pre-checkpoint block data pruned
Attacker's Chain: On Day 100 → Still behind (needs more blocks)

Result: The honest chain still has more cumulative work at every point, so
it was never at risk of being displaced by chain-selection rules. Once the
pre-checkpoint data is pruned, the attacker's chain also has nothing left on
the network to fork from even if it somehow caught up later.

Local Verification:
- Nodes select the chain with the most cumulative work, same as Bitcoin
- An attacker who never had more real work than the honest chain is never selected in the first place — this scenario doesn’t require any checkpoint-specific rejection logic
- The attacker’s chain is simply outcompeted and ignored by anyone already synced

Scenario 2: The “Computational Floor” Attack

Attack Description:

Attacker has 10x the honest network’s mining power
Attempts to overtake the chain within 50 days

Why It Doesn’t Work:

The Computational Floor:
- For each block, the attacker must:
  - Compute PoW (10x capacity helps here)
  - Compute the full UTXO attestation (not meaningfully sped up by extra ASICs)
- Attestation computation creates a shared bottleneck that applies to attacker and honest network alike
The Bottleneck in Practice:

Attacker's Capacity:
├─ PoW: 10,000 TH/s (ASIC)
├─ Attestation throughput: roughly comparable to honest nodes, CPU/RAM bound
└─ Realistic block rate: limited by attestation computation, not by PoW headroom

The Result:
- Honest network: ~1,440 blocks/day
- Attacker’s realistic maximum: not much higher, despite the 10x PoW advantage
- Extra hash power alone doesn’t translate into a proportionally faster alternative chain

Scenario 3: The “Stoic Awakening” Scenario

Attack Description:

Attacker mines a secret chain with irregular timestamps
Attempts to avoid detection by adjusting timestamps

Why It Doesn’t Work:

Timestamp Anomaly:

Block 1,000: Timestamp = Day 1, 12:00:00
Block 1,001: Timestamp = Day 1, 12:02:30 (>120s gap)
→ Stoic Awakening triggers
→ Difficulty drops to minimum
→ Any miner can produce blocks at minimum difficulty

The Honest Network’s Position:
- Honest nodes maintain consistent, real-time-tracked timestamps
- A shadow chain’s anomalous timestamps are visible against real clock time
- Nodes following the honest chain won’t adopt the shadow chain
The Outcome:
- The attacker’s chain either slows down (falling behind) or fakes timestamps (becoming detectable)
- The honest network isn’t structurally disadvantaged by this mechanism — if anything it helps it recover pace after any disruption

Summary of the Security Model

Three Layers Working Together:

Time Window (137 days):

A long-range attack can’t reach further back than the last checkpoint
Checkpoints seal state, and pre-checkpoint data leaves the network

Computational Floor (PoW + Attestation):

Both are required for every block
Attestation computation is a shared bottleneck, not one attackers can uniquely optimize away

Stoic Awakening:

Discourages timestamp manipulation as an evasion strategy

The Honest Summary:

No PoW chain can claim immunity from a majority-hashpower attacker on recent blocks — that’s true of Bitcoin and it’s true of Elektron Net. What Elektron Net changes is the depth such an attack can reach: nothing before the last checkpoint can be reorganized, because that history no longer exists anywhere on the network to fork from.

Comparison: Bitcoin vs. Elektron Net Security

Attack Scenario	Bitcoin	Elektron Net
Long-term secret mining	Possible in principle, economically discouraged	Structurally unavailable past the 137-day window
51% hash power attack (recent blocks)	Possible if sustained	Equally possible — the checkpoint mechanism doesn’t change this
Deep history revision	Possible in principle with enough PoW	Same PoW requirement as Bitcoin — not cheaper — and additionally blocked in practice once the required block data is pruned network-wide
Timestamp manipulation	Can be adjusted gradually	Discouraged by Stoic Awakening
State forgery	N/A (no attestation concept)	Requires actually computing valid UTXO state — can’t be faked
Fork acceptance	Follows the chain with the most cumulative work	Same rule; a pre-checkpoint fork is additionally blocked by data unavailability, not a dedicated consensus check

Real-World Implications

For Users

Bounded Exposure:

Once a checkpoint has sealed, a chain reorganization reaching back past it would require both real cumulative PoW exceeding the honest network (same cost as attacking Bitcoin) and block data that, in practice, no longer exists anywhere on the network
This caps how far back your transaction history could realistically ever be revised, though the underlying protection is PoW economics plus data unavailability rather than a dedicated consensus rule

Example:

You receive a payment
The network continues advancing for up to 137 days
The checkpoint seals the state
A chain forking before that checkpoint would need both more real cumulative
PoW than the honest network and block data that's no longer available
→ Your locally verified balance stays consistent with that checkpoint

For Enterprises

Bounded Attack Surface:

No long-term, unbounded-depth reorganization risk
Storage is capped and predictable
Data-retention limits are built into the protocol (relevant for compliance discussions)

Cost Benefits:

No need to monitor for arbitrarily deep chain reorganizations
Lower infrastructure costs (capped storage)
A protocol-level basis for bounded data retention (see the “right to be forgotten” chapter in the whitepaper)

For the Network

Structural Properties:

The 137-day window creates a hard limit on how far back any fork can reach
Attestations create a computational floor shared by honest and dishonest chains alike
Stoic Awakening discourages timestamp manipulation as an evasion tactic

Current Caveat Worth Stating Plainly:

The security properties above describe the protocol design. As with any PoW network, they assume a reasonably decentralized set of miners over time. Elektron Net is early-stage and currently mining is concentrated; the checkpoint and attestation mechanisms don’t substitute for miner decentralization; they work alongside it as the network matures.

The network has also not yet reached its first checkpoint at height 197,280 — the checkpoint and snapshot-bootstrap machinery described on this page hasn’t been exercised on the live chain yet. This is relevant less for the checkpoint mechanism itself, and more for the bootstrap trust question raised earlier in this document: the moment the chain crosses that height, snapshot-based bootstrapping activates for any new node, independent of how many miners are on the network at that point.

Conclusion: A Different Trade-off, Not a Free Lunch

Elektron Net’s pruning and attestation design achieves something genuinely useful:

A consensus system where the depth of any possible chain reorganization is structurally bounded, rather than merely economically discouraged, at the cost of full nodes no longer retaining unbounded history.

The Three Properties:

Time-Bound Depth:

No fork can reach further back than the last checkpoint
Checkpoints seal state as pre-checkpoint data leaves the network

Computational Floor:

Attestation requires real, serial computation from anyone extending the chain
It doesn’t advantage attackers with more PoW hardware alone

Timestamp Discouragement:

Stoic Awakening removes slow-and-quiet mining as a viable evasion strategy

What This Is, Honestly:

A blockchain that structurally rules out mining an alternative history in secret over years — at the same PoW cost as attacking Bitcoin, plus the practical unavailability of old block data
A network whose chain-selection rule is unchanged from Bitcoin’s (most cumulative work), with pre-checkpoint forks blocked in practice by data unavailability rather than a dedicated consensus rule
A design that trades unbounded history for bounded storage, bounded attack depth, and a genuine technical basis for data-retention limits — while still relying, like any PoW chain, on honest majority hash power for recent-block security, and on the live network for state prior to the pruning window

Technical Appendix: The Code That Makes It Possible

The 137-Day Window Enforcement

// src/validation.h
static constexpr int MANDATORY_PRUNE_DEPTH = 197280;  // 137 days at 60s blocks

// src/validation.cpp
void PruneBlockFiles(CChainState& chainstate, const CBlockIndex* pindexLast) {
    // Prune all blocks older than MANDATORY_PRUNE_DEPTH
    const int max_prune_depth = std::max(0, chainstate.m_chain.Height() - MANDATORY_PRUNE_DEPTH);
    // ... enforcement logic
}

The Attestation Validation

// src/validation.cpp
bool ValidateUTXOCheckpoint(const CBlock& block, CCoinsViewCache& view) {
    // Compute UTXO hash after processing block
    uint256 computed_hash = ComputeBlockUTXOAttestationHash(block, view);
  
    // Extract attestation from coinbase
    uint256 attestation_hash = ExtractCoinbaseUTXOAttestation(block);
  
    // Reject if they don't match
    if (computed_hash != attestation_hash) {
        return error("bad-utxo-attestation");
    }
    return true;
}

The Stoic Awakening Trigger

// src/pow.cpp
bool PermittedDifficultyTransition(const CBlockHeader& block, const CBlockIndex* pindexPrev) {
    const int64_t target_spacing = 60; // 60-second blocks
    const int64_t max_spacing = 120;    // 2x target
  
    if (pindexPrev->GetBlockTime() + max_spacing < block.GetBlockTime()) {
        return true; // Minimum difficulty allowed
    }
    return false;
}

The Checkpoint Sealing

// src/validation.cpp
void WriteAutomaticSnapshot(CChainState& chainstate, const CBlockIndex* pindex) {
    // Called every 197,280 blocks
    if (pindex->nHeight % MANDATORY_PRUNE_DEPTH == 0) {
        // Write .dat and .hash sidecar
        WriteSnapshotFile(chainstate, pindex);
        // Verify sidecar matches on-chain attestation
        VerifySnapshotHash(pindex);
        // Seal the checkpoint immutably
        SealCheckpoint(pindex);
    }
}

// Since height 137,000: .hash sidecar derived from the running 
// MuHash accumulator (O(1)), not a full rescan

Implemented: Incremental Attestation Hashing (MuHash)

Since block height 137,000 (activated 2026-07-02), Elektron Net’s per-block UTXO attestation switched from a full-set hash (HASH_SERIALIZED) to an incrementally-updatable commitment (HASH_MUHASH, MuHash3072), which is updated cheaply per transaction rather than recomputed from scratch on every block. Below height 137,000, attestation remains byte-for-byte HASH_SERIALIZED, unchanged.

As of Phase 2, this also applies to the periodic checkpoint snapshot files: post-activation, the .hash sidecar and snapshot metadata are derived directly from the running MuHash accumulator (O(1)) instead of a full rescan. Pre-activation checkpoints, and any checkpoint below height 137,000, are still computed via a full HASH_SERIALIZED pass.

The activation height was set well ahead of mainnet’s first mandatory checkpoint (197,280), so the very first automatic snapshot is written and verified consistently as a MuHash value from the start, rather than straddling the algorithm switch.

Why This Change Was Necessary

Before this upgrade, every block’s UTXO attestation was computed via HASH_SERIALIZED: a full rescan and re-hash of the entire UTXO set, repeated from scratch on every single block. On Bitcoin, with a 10-minute block time, this cost is comfortably absorbed. Elektron Net’s 60-second block time is ten times faster, and the UTXO set, like Bitcoin’s, only grows over the life of the chain. A fixed, ever-growing per-block cost against a fixed, ten-times-shorter block interval is not a one-time inconvenience, it is a scaling curve that eventually crosses the block time itself. Past that point, nodes and miners can no longer finish validating one block before the next is due, and the chain’s effective throughput stalls regardless of hash power available.

The cost was also paid twice on every mined block: once to build the block template, and again to validate it, both full rescans of the same growing UTXO set.

Switching to HASH_MUHASH (MuHash3072) replaces the full rescan with an incremental, constant-time (O(1)) update: each block only folds in its own coin changes into a running accumulator, instead of re-deriving the state of the entire set from nothing. This decouples per-block attestation cost from UTXO set size entirely, removing the long-term scaling risk before it could ever be reached in practice.

Importantly, this is a performance change, not a security tradeoff. MuHash is a cryptographically sound multiplicative hash construction: the resulting commitment is just as strong a guarantee of full-chain header and state consistency as HASH_SERIALIZED was. A node verifying a MuHash attestation still confirms that its UTXO state ties back correctly through the entire header chain, with no weaker assurance than before. The only thing that changes is speed: incremental MuHash updates are roughly 100 to 100,000 times faster per block than a full HASH_SERIALIZED rescan, depending on UTXO set size at the time of comparison.