Skip to content

Latest commit

 

History

History
56 lines (30 loc) · 3.71 KB

057.md

File metadata and controls

56 lines (30 loc) · 3.71 KB

Scruffy Gingerbread Cormorant

Medium

Vigilante may fail to send cosmos request to babylon network due to frequent account sequence mismatch errors

Summary

The Vigilante BTC staking event watcher frequently encounters account sequence mismatch errors when submitting transactions to the Babylon node, due to multiple concurrent goroutines sending Cosmos SDK messages using the same account without proper sequence number synchronization.

Root Cause

In vigilante/btcstaking-tracker/stakingeventwatcher/stakingeventwatcher.go, the StakingEventWatcher spawns multiple concurrent goroutines that process different BTC events (unbonding, delegation activation, etc.) and report these events to the Babylon node through Cosmos SDK messages. The issue is that all these goroutines use the same Babylon client and account to send transactions, but there's no synchronization mechanism to coordinate the sequence numbers across these concurrent operations.

For example:

  1. In the checkSpend method, when a spent output is detected, a goroutine is spawned which calls handleSpend, and when an unbonding transaction is detected, it calls reportUnbondingToBabylon which sends a transaction.

  2. In the activateBtcDelegation method, a goroutine is spawned to activate a delegation by sending a transaction.

Such transactions may get rejected by cosmos if the cosmos tx sequence is not correct with error Incorrect account sequence.

In many cases, e.g. at https://github.com/sherlock-audit/2024-12-babylon/blob/main/vigilante/btcstaking-tracker/stakingeventwatcher/stakingeventwatcher.go#L782, Vigilante will stop the processing after attempting 5 retries causing delays or failures in critical transitions, in this case failing to make a delegation ACTIVE.

Internal Pre-conditions

NA

External Pre-conditions

NA

Attack Path

NA

Impact

This issue causes many transactions to fail with "account sequence mismatch" errors, as seen in the logs below. While the code includes retry mechanisms, it is possible to keep on failing multiple times. After 5 retries, some of the operation fails completely, potentially leading to issues like failed delegation activation.

PoC

The logs from Vigilante demonstrate the sequence mismatch issue which can be observed after trying to stake/ unstake multiple times.

2025-02-27T08:34:06.543434Z     debug   retrying        {"attempt": 3, "max_attempts": 5, "error": "rpc error: code = Unknown desc = rpc error: code = Unknown desc = account sequence mismatch, expected 426, got 425: incorrect account sequence [cosmos/[email protected]/x/auth/ante/sigverify.go:290] with gas used: '21876': unknown request"}
2025-02-27T08:34:14.361824Z     debug   retrying        {"attempt": 4, "max_attempts": 5, "error": "rpc error: code = Unknown desc = rpc error: code = Unknown desc = account sequence mismatch, expected 427, got 426: incorrect account sequence [cosmos/[email protected]/x/auth/ante/sigverify.go:290] with gas used: '21876': unknown request"}
2025-02-27T08:35:12.697227Z     debug   retrying        {"attempt": 5, "max_attempts": 5, "error": "rpc error: code = Unknown desc = rpc error: code = Unknown desc = account sequence mismatch, expected 435, got 434: incorrect account sequence [cosmos/[email protected]/x/auth/ante/sigverify.go:290] with gas used: '21876': unknown request"}

The logs show multiple retries with incrementing sequence numbers, indicating that other processes are successfully submitting transactions in between the retries, causing the sequence to move ahead. After 5 retries, certain operations can completely fail. This is an intermittent issue and in many cases ends up working after 2-3 retries, but can still hit 5 retry limit in a few cases.

Mitigation

No response