Summary
A single Paloma validator can appear multiple times in an EVM Compass valset if it registers duplicate external chain info entries for the same target chain/address. The valset keeper checks address collisions against other validators, but does not reject duplicate entries within the same validator's own chain info. transformSnapshotToCompass then appends every matching external chain info entry with that validator's full power.
If a malformed valset containing duplicate EVM addresses is signed by the current validator set and installed on Compass, the same EVM key can occupy multiple Compass validator slots. Compass signature verification counts power by slot, so one key can be counted repeatedly. That creates a path from one validator's duplicated external-chain metadata to one-key control of later update_valset / bridge execution calls after the malformed valset is installed.
Evidence
x/valset/keeper/keeper.go: SetExternalChainInfoState skips the current validator while checking existing address ownership and does not enforce uniqueness within the submitted chainInfos list.x/valset/keeper/keeper_test.go: existing coverage allows duplicate addresses for one validator on the same chain.x/evm/keeper/keeper.go: transformSnapshotToCompass appends every matching external chain info entry and appends the validator's normalized power for each entry.- Deployed Compass source verifies signatures and adds power by valset array index, with no duplicate-address guard.
Required fixes
- Reject duplicate
(chain_type, chain_reference_id, address) entries within a single validator's external chain info before storing state.
- Keep the global uniqueness check across validators, but make it include duplicates from the current validator as invalid for the same target chain.
- Add a defensive check in
transformSnapshotToCompass that fails or drops the snapshot if duplicate validator addresses would be emitted for the target Compass valset.
- Add migration / diagnostic tooling to detect any existing duplicate external-chain records before the next valset update is emitted.
- Add tests that prove duplicate EVM addresses cannot be stored through
MsgAddExternalChainInfoForValidator and cannot be transformed into a Compass valset.
Severity
High / critical. This is not a normal one-signature takeover against a clean current Compass valset. The risk appears when Paloma produces and installs a malformed Compass valset with duplicated EVM validator addresses, after which one EVM key can be counted multiple times by the deployed Compass contract.
Summary
A single Paloma validator can appear multiple times in an EVM Compass valset if it registers duplicate external chain info entries for the same target chain/address. The valset keeper checks address collisions against other validators, but does not reject duplicate entries within the same validator's own chain info.
transformSnapshotToCompassthen appends every matching external chain info entry with that validator's full power.If a malformed valset containing duplicate EVM addresses is signed by the current validator set and installed on Compass, the same EVM key can occupy multiple Compass validator slots. Compass signature verification counts power by slot, so one key can be counted repeatedly. That creates a path from one validator's duplicated external-chain metadata to one-key control of later
update_valset/ bridge execution calls after the malformed valset is installed.Evidence
x/valset/keeper/keeper.go:SetExternalChainInfoStateskips the current validator while checking existing address ownership and does not enforce uniqueness within the submittedchainInfoslist.x/valset/keeper/keeper_test.go: existing coverage allows duplicate addresses for one validator on the same chain.x/evm/keeper/keeper.go:transformSnapshotToCompassappends every matching external chain info entry and appends the validator's normalized power for each entry.Required fixes
(chain_type, chain_reference_id, address)entries within a single validator's external chain info before storing state.transformSnapshotToCompassthat fails or drops the snapshot if duplicate validator addresses would be emitted for the target Compass valset.MsgAddExternalChainInfoForValidatorand cannot be transformed into a Compass valset.Severity
High / critical. This is not a normal one-signature takeover against a clean current Compass valset. The risk appears when Paloma produces and installs a malformed Compass valset with duplicated EVM validator addresses, after which one EVM key can be counted multiple times by the deployed Compass contract.