A blockchain explorer shows the redemption, so why is $BTC still unable to release
The Ethereum transaction has already been broadcast, included in a block, generated a receipt, and you can even find the redemption event. This only proves that some execution block contains this record. For the current public testnet TBV, that is still not enough to release BTC, because you also need to prove that this block is part of the final history adopted by Ethereum.
Whether the user fully repays the debt and withdraws the Vault, or whether the liquidation flow hands the Vault to the downstream redemption role, will trigger a redemption event. The off-chain SP1 prover constructs the proof in a fixed order: Beacon finality first confirms that the beacon block has been finalized by the consensus layer; Execution finality then connects that finalized beacon block with the execution block containing the redemption transaction; Receipt inclusion last confirms that the target redemption log exists in the transaction receipt of that block. Groth16 compresses and aggregates only the first three layers of proofs into a compact proof, but it does not grant block finality.
This layered change has altered my judgment. I no longer treat “the browser has already seen the transaction” as enough to establish that cross-chain redemption has already been finalized as a fact. Instead, I will check whether both can be proven at the same time—(1) the event is indeed included, and (2) the execution block that bears it has been finalized and acknowledged by the beacon chain. The former answers “what happened,” while the latter answers “whether it became part of Ethereum’s final state.” Without that latter layer, the Bitcoin Payout may be built on an external history that hasn’t stabilized yet.
After completing the finality and inclusion proofs, the claimer then submits the compressed proof to the Bitcoin side’s Claim, Assert, and challenge window. Ethereum finality confirms which final history an external event belongs to; Bitcoin’s challenge period checks whether the proof submitted to the Bitcoin side can hold. These are not the same set of waiting, and they cannot substitute for each other. Only if the proof is not effectively overturned does the Payout proceed to execution.
The boundaries also need to be kept clear: proving a finalized redemption event means this log is already in Ethereum’s final state, but it does not mean that the upstream contract, oracle, or liquidation judgment is necessarily economically correct. If Ethereum consensus experiences a deep-level failure, verification may also stall or error out. @BabylonLabs_io sets the threshold at “an event in final history,” not “an event visible on the browser,” precisely because after Bitcoin is released, it will not be automatically revoked due to later changes on the external chain. $ETH
$BABY
#baby
The Ethereum transaction has already been broadcast, included in a block, generated a receipt, and you can even find the redemption event. This only proves that some execution block contains this record. For the current public testnet TBV, that is still not enough to release BTC, because you also need to prove that this block is part of the final history adopted by Ethereum.
Whether the user fully repays the debt and withdraws the Vault, or whether the liquidation flow hands the Vault to the downstream redemption role, will trigger a redemption event. The off-chain SP1 prover constructs the proof in a fixed order: Beacon finality first confirms that the beacon block has been finalized by the consensus layer; Execution finality then connects that finalized beacon block with the execution block containing the redemption transaction; Receipt inclusion last confirms that the target redemption log exists in the transaction receipt of that block. Groth16 compresses and aggregates only the first three layers of proofs into a compact proof, but it does not grant block finality.
This layered change has altered my judgment. I no longer treat “the browser has already seen the transaction” as enough to establish that cross-chain redemption has already been finalized as a fact. Instead, I will check whether both can be proven at the same time—(1) the event is indeed included, and (2) the execution block that bears it has been finalized and acknowledged by the beacon chain. The former answers “what happened,” while the latter answers “whether it became part of Ethereum’s final state.” Without that latter layer, the Bitcoin Payout may be built on an external history that hasn’t stabilized yet.
After completing the finality and inclusion proofs, the claimer then submits the compressed proof to the Bitcoin side’s Claim, Assert, and challenge window. Ethereum finality confirms which final history an external event belongs to; Bitcoin’s challenge period checks whether the proof submitted to the Bitcoin side can hold. These are not the same set of waiting, and they cannot substitute for each other. Only if the proof is not effectively overturned does the Payout proceed to execution.
The boundaries also need to be kept clear: proving a finalized redemption event means this log is already in Ethereum’s final state, but it does not mean that the upstream contract, oracle, or liquidation judgment is necessarily economically correct. If Ethereum consensus experiences a deep-level failure, verification may also stall or error out. @BabylonLabs_io sets the threshold at “an event in final history,” not “an event visible on the browser,” precisely because after Bitcoin is released, it will not be automatically revoked due to later changes on the external chain. $ETH
$BABY
#baby