IBC Packet Commitment Timeout Mismatch Across Variable Block-Time Chains

[JamesEjembi]

Problem Statement / Feature Objective

The IBC (Inter-Blockchain Communication) packet commitment timeout is calculated using the source chain's block time assumption. When sending packets to a chain with variable block times (e.g., 2-30s range), the timeout can expire prematurely on fast blocks or be excessively long on slow blocks, causing packet loss or settlement delays.

Technical Invariants & Bounds

• Timeout calculation: source_height + (timeout_delta / source_block_time).
• Block time variance tracking: rolling window of 100 blocks.
• Timeout delta: configurable 10-300s.
• Packet lifetime: max 1000 blocks on destination chain.
• Mismatch penalty: >5% timeouts due to misestimation triggers recalibration.

Codebase Navigation Guide

• src/cross-chain/ibc/packet-timeout.rs — timeout calculation.
• src/cross-chain/ibc/block-time-estimator.rs — block time estimation.
• src/cross-chain/ibc/packet-relayer.rs — packet relay logic.
• src/cross-chain/consensus/header-sync.rs — header synchronization.

Implementation Blueprint

1. In block-time-estimator.rs, maintain an exponential moving average (EMA) of block times with alpha = 0.3 over 100 blocks; also track the 95th percentile.
2. In packet-timeout.rs, compute timeout as source_height + ceil(timeout_delta / p95_block_time_ms) instead of using a fixed value.
3. Add a safety margin: multiply the estimated block count by 1.5 for the first 10 packets to a new chain until sufficient block time samples are collected.
4. In packet-relayer.rs, emit a PacketTimeoutMisestimation event when a packet times out but the destination chain is still at or below the estimated timeout height.
5. Unit test: simulate variable block times (2s average with spikes to 30s), verify packet timeout accuracy >95%.

[Cyber-Mitch]

Hi, I'd like to apply for this issue.

I'm a smart contract and cross-chain security engineer, and while my deepest experience is on EVM/Solana/Sui/Stellar rather than IBC specifically, this issue is fundamentally a timing-estimation and safety-margin problem — the same category of correctness question I deal with across chains (getting a statistical estimate wrong in either direction either loses packets or wastes latency), so I'm comfortable with the actual substance here.

How I'd approach it:

EMA + p95 tracking — maintain both as specified (alpha=0.3 EMA, 95th percentile over a rolling 100-block window); I'd use p95 rather than the mean for the timeout calculation specifically because the problem statement is about tail risk (occasional 30s blocks), and a mean-based estimate would still get burned by exactly the spikes this issue exists to handle.
Timeout formula — source_height + ceil(timeout_delta / p95_block_time_ms), with the ceiling division verified not to under-round at the boundary (an off-by-one here directly reintroduces the premature-expiry bug the issue is fixing).
Cold-start safety margin — the 1.5x multiplier for the first 10 packets to a new chain needs a clear transition point: I'd make the "sufficient samples" threshold explicit and tested, so there's no ambiguous window where the multiplier silently stops applying before real data has actually stabilized the estimate.
Misestimation event — emitted specifically when a packet times out while the destination chain is still within the estimated height, since that's the precise signal that the estimate (not the network) was at fault; I'd make sure this doesn't fire on legitimate timeouts caused by real destination-chain delay.
Recalibration trigger — wiring the >5%-misestimation-rate threshold to actually reset or re-widen the estimator's confidence, not just log the event passively.

Test: simulate a 2s-average block time with periodic spikes to 30s (I'd model this as a real distribution, not just alternating fixed values, so the p95 tracking is genuinely exercised), asserting >95% timeout accuracy as specified, plus a dedicated cold-start test verifying the 1.5x margin actually prevents premature timeout during the first 10 packets before sufficient samples exist.

I'll complete the task within a day of assignment and open a draft PR early once the EMA/p95 estimator and core timeout formula are working, before finalizing the cold-start margin and misestimation event.

[grantfox-oss]

🦊 GrantFox — @Cyber-Mitch has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #138)
2. Your PR will be reviewed by the VeriNode-Labs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@Cyber-Mitch's PR #170 was approved and merged by @JamesEjembi.

🏆 @Cyber-Mitch: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (551 total points). Track your full progress on GrantFox.

👏 Great work, @Cyber-Mitch! Keep contributing to VeriNode-Labs.