Andromeda – Validator Staking ADO and Vesting ADO — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Andromeda – Validator Staking ADO and Vesting ADO, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 13
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 13 closed, publicly disclosed Andromeda – Validator Staking ADO and Vesting ADO reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Logic error, Integer overflow / underflow, across Cosmos-SDK, Other. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Logic error findings disclosed against Andromeda – Validator Staking ADO and Vesting ADO
- Integer overflow / underflow findings disclosed against Andromeda – Validator Staking ADO and Vesting ADO
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Andromeda – Validator Staking ADO and Vesting ADO: Valid VFS paths with usernames can always fail validation
In AndromedaOS, VFS path validation via get_raw_address() resolves home and lib paths by calling api.addr_validate() on the username-or-address segment. When a registered username is itself a syntactically valid Bech32 address, the resolver treats it as a raw address and never loads the stored account from USERS storage. Consequently valid paths like /home/username1 resolve to the literal username string or fail with a missing storage key, breaking AMP-message delivery and fund claims across the Validator Staking and Vesting ADOs. The issue was escalated to High on loss-of-funds grounds, then ultimately adjudicated as Medium because in most affected contracts the contract admin can rescue funds via migration.
Andromeda – Validator Staking ADO and Vesting ADO: Lockup of vestings or completion time can be bypassed due to missing check for staked tokens
Andromeda's Vesting ADO tracks each vesting in a Batch struct that records total amount and amount_claimed but never tracks how many tokens have been staked to a delegator. Because all batches share a single recipient and one pooled contract balance, claim_batch computes claimable funds only against amount_claimed and the overall native balance, ignoring the staked portion. As a result, a recipient can claim a matured vesting whose entire principal is still staked, and the payout is drawn from the pooled balance — effectively pulling from a different, still-locked vesting deposited by the owner. This lets a user withdraw tokens before their lockup ends, defeating the vesting schedule's anti-dump security guarantee. The Sherlock judge upheld the finding as a unique Medium after rejecting an owner-trust escalation, and the protocol fixed it by removing the stake logic.
Andromeda – Validator Staking ADO and Vesting ADO: if Slash Validator occurs, UNSTAKING_QUEUE's unstake amount will not be accurate
The Andromeda validator-staking ADO maintains a FIFO UNSTAKING_QUEUE of expected unstake payouts, recording the initial_balance of each Cosmos UnbondingDelegationEntry. When a validator gets slashed mid-unbond, Cosmos pays back only the reduced balance (the initial amount minus the slash factor) while the queue still holds the pre-slash figure. On execute_withdraw_fund(), the ADO tries to transfer the stale queued amount even though the contract only received the smaller slashed balance, so the withdrawal either fails on insufficient funds or, by holding the queue at the head, blocks every withdrawal behind it. The fix (PR #551) removed the per-entry amount accounting and instead pays out the contract's entire available balance, and the maintainers repurposed the function as an emergency withdrawal path.
Andromeda – Validator Staking ADO and Vesting ADO: the DEFAULTVALIDATOR cannot be changed
Andromeda's validator-staking ADO documented in its README that an admin could alter the default staking validator, but the contract exposed no setter for the DEFAULTVALIDATOR constant, leaving reinstantiation of the entire ADO as the only path to change it. A Sherlock judge accepted the finding as a valid Medium under the rule that breaking README-stated expected functionality is a Medium defect regardless of low direct impact. The protocol fixed it by adding an owner-only execute_update_default_validator() message. This is a configuration/documented-behavior gap rather than a funds-loss or exploit path.
Andromeda – Validator Staking ADO and Vesting ADO: execute_claim() possible loss of accuracy or even inability to retrieve funds
The Andromeda Vesting ADO's claim_batch() computes each claim's amount by first multiplying the batch total by the configured release_amount (a 1e18-precision Decimal) and dividing by 1e18, then multiplying that already-rounded per-claim value by the number of elapsed claim periods. Because the division precedes the multiplication, the intermediate per-claim figure can round down to zero when the release unit is small relative to the stream duration, so the final amount_to_send becomes zero even while the full batch balance remains unclaimed. In that state the function's early-exit branch leaves last_claimed_release_time unchanged and never transfers funds, permanently locking the user's vested assets. The protocol fixed this by changing get_amount() to return a Decimal to preserve precision and by rejecting batches whose per-unit release amount rounds to zero at creation time.
Andromeda – Validator Staking ADO and Vesting ADO: Permission checks will unnecessarily consume Limited uses
In Andromeda's ADO framework, the is_permissioned() permission check unconditionally decrements a Limited permission's use counter every time it runs. The higher-level context checks is_context_permissioned() and is_context_permissioned_strict() both call is_permissioned() for the AMP origin AND the previous sender, so a single authorized action against two Limited holders consumes two uses; the cw721 mint path compounds this by invoking the checks repeatedly, consuming up to four uses across two addresses. A whitelisted user can deliberately drain a victim's Limited uses by passing the victim's address as the AMP origin or previous sender, and the same over-consumption also happens naturally. The sponsor confirmed this was unintended and the Sherlock lead judge upheld the escalation as Medium/Unique; fixes in andromeda-core PRs 553 and 569 rework the context checks to execute once.
All reports in this group
- Andromeda – Validator Staking ADO and Vesting ADO: when a validator is kicked out of the bonded validator set ,unstake funds will remain in the contractLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: Staked tokens will get stuck after claimLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: is_permissioned() may underflowLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: Changes of the `UnbondingTime` are not accounted forLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: is_permissioned() It doesn't make sense to have permissions by default after Blacklisted expires.Logic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: Calculating tax amount does not include taxes in `WasmMsg::Execute` messagesLogic error$0
- Andromeda – Validator Staking ADO and Vesting ADO: Batch creation will break if vestings are opened to recipientsLogic error$0