Cocoon 0.0.6 Fixes Duplicate-Transaction Defect
Cocoon demo-0.0.6 fixes a critical duplicate-transaction defect in Erigon. A withdrawals re-stamp could leave the canonical block index tied to an outdated hash. During block closing, the node could then unwind valid state changes and seal a block whose body and receipts did not match the applied state transition. The affected transactions remained pending and could be included again later, creating duplicate transaction keys and eventually preventing the transaction snapshot index from being built. This could stall block production.
The fix updates the canonical block and head-header indexes during re-stamping. It also removes unnecessary canonical checks from pre-execution paths. Testing on a live49 setup ran for 2 hours and 15 minutes from a fresh genesis, with a forced stall every 10th round. Across 3,489 trading blocks and 45,403 transaction rows, developers found no duplicate hashes, state unwinds, body-audit errors, incorrect trie roots or error logs. Three hourly integrity checks remained clean, and test suites stayed at baseline.
The release does not fix a separate successor wrong-root defect, the inactive CLOB order-posting issue, or unexplained canonical trace mismatches. For traders and node operators, the update improves execution reliability and reduces the risk of duplicate transactions and block-production interruptions, but unresolved consensus and trading-engine issues still warrant caution.
Neutral
The market impact is neutral because this is a client-level reliability fix rather than a change to token economics, network demand or liquidity. In the short term, node operators running the affected build may benefit from fewer duplicate transactions and a lower risk of block-production stalls. That could reduce operational uncertainty, but the release is unlikely to create broad buying pressure without a major network-wide deployment or visible market disruption.
The validation results are positive: 3,489 blocks and 45,403 transaction rows were checked without duplicate hashes, unwinds or incorrect trie roots. This supports confidence in the fix. However, the unresolved successor wrong-root defect could still create consensus or propagation concerns, while the inactive CLOB limits trading functionality. The unexplained canonical trace mismatch also leaves some technical uncertainty.
Historically, blockchain client bugs that threaten finality or block production can trigger short-term volatility, wider spreads and temporary risk reduction by traders. Conversely, a confirmed fix can support long-term network stability. In this case, the limited deployment scope and remaining defects suggest a contained technical improvement, not a clear bullish or bearish catalyst for the wider cryptocurrency market.