Proof Infrastructure Watch / Network & Protocol

The official ARCADE project has released version 0.10.0, introducing a coordinated improvement with Merkle Service that allows transaction-proof construction to begin immediately when all expected subtree proofs have arrived.

ARCADE previously applied a fixed 30-second grace period before reading the STUMPs—subtree-based components used to construct compound Merkle proofs—for each processed block. The delay allowed time for proof components to arrive, but it remained in place even when the system already possessed enough information to know that the set was complete.

Merkle Service supplies an expectedSubtreeIndices set with its block-processed message. ARCADE v0.10.0 compares that expected set with the STUMPs it has received. When every expected component is present, its BUMP builder can proceed without waiting through the fixed grace period. If the expected set is incomplete or cannot establish completeness, the existing delay and watchdog safeguards remain in place.

The accompanying Merkle Service v0.5.0 release makes emission of the expected-STUMP set explicitly configurable through a default-enabled operational switch. The mechanism had already been active in earlier Merkle Service releases; the new control provides an emergency way to disable it without changing its normal behavior.

The ARCADE development notes estimate that the change can remove approximately 30 seconds from the steady-state mined-proof path and help recovery queues clear more quickly. This is a project-reported operational measurement rather than an independent performance benchmark.

ARCADE v0.10.0 also adds an architectural overview and swimlane diagram, alongside updated development configuration and dependencies.

View the ARCADE v0.10.0 release

View the Merkle Service v0.5.0 release

Review the ARCADE proof-completeness change

BSV TIMES read:
This update does not shorten block production or change when a transaction is mined. It removes an avoidable waiting period from proof construction when the infrastructure can already verify that every required component has arrived. That distinction matters: scalable transaction systems need not only high processing capacity, but also timely and dependable proof delivery so applications can independently verify transaction inclusion without unnecessary operational delay.

Posted on July 17, 2026