Confirmation Target

Overview

In fee estimation, a user might request inclusion within the next few blocks. The wallet analyzes recent fee markets and recommends a fee rate or priority level. A shorter target usually requires a higher fee, although sudden congestion can make the estimate inaccurate.

In merchant operations, a target may describe expected time to the required number of confirmations or finality. Monitoring can compare actual outcomes with the target and alert when transactions fall behind.

The target should be separated from the requirement. A merchant may require three confirmations but hope to reach them within fifteen minutes. Missing the time target does not necessarily invalidate the transaction; it may simply remain pending longer.

Targets should be based on historical distributions rather than nominal block time alone. Networks with variable intervals or missed slots can produce wide latency ranges. Applications should update estimates as conditions change and clearly label them as expected rather than promised completion times.

Fee-bumping and transaction-replacement tools can help when the original estimate no longer meets the target. However, replacements need careful tracking so applications recognize the final transaction hash and do not treat both versions as separate payments. For account-based networks, a replacement usually uses the same nonce. Operational systems should link all attempts to one intent and measure whether the final confirmed result met the original target.

Targets should be reviewed when network conditions or fee markets change structurally. A target based on historical low congestion may become unrealistic. Product interfaces should update customer expectations rather than repeatedly showing an estimate the system rarely meets.