Locations
Summary
The key inventory marks a depositable key as “In priority queue” only when it belongs to queue 0. Production IDVTC operators use priority 1, so their preferentially queued keys are displayed without the priority badge.
Root cause
useMaxPriorityKeyIndex unconditionally counts batches from allBatches[0], and KeysTable treats that count as the complete preferentially queued prefix.
- The deployed CSM configuration assigns IDVTC operators queue priority 1 and a 40-key priority allowance.
- The graph recognizes priority 1 as a preferential queue, but the per-key inventory never includes its batches when calculating the badge boundary.
Impact
An IDVTC manager can make a destructive key decision from an inventory that incorrectly presents a preferentially queued key as having no priority designation. The manager may consequently remove that key, incur the bond-funded removal charge, and lose its effective queue placement if the stale batch is cleaned before the key is re-added.
This is low severity because the transaction still requires the operator manager’s wallet authorization, affects only that operator, and can generally be recovered by re-adding and re-queuing the key. The aggregate queue graph also provides partial—but not per-key—containment.
Scenario
- An IDVTC operator has an undeposited key represented by a batch in priority queue 1.
- Queue 0 contains no batch for that operator, so
priorityKeys resolves to zero and the calculated maximum priority-key index precedes every undeposited key.
KeysTable renders the key’s depositable status without the “In priority queue” badge.- Relying on that inventory, the manager selects the key for removal; the signing stage confirms only the number of keys.
- The wallet broadcasts the real removal transaction, which deletes the key and charges the configured removal fee despite the undisclosed preferential placement.
Drafted from LidoLens finding VKI-VIEW-01
Locations
csm-widget/shared/hooks/use-max-priority-key-index.ts:11-15csm-widget/features/view-keys/view-keys-section/keys-table.tsx:58-61Summary
The key inventory marks a depositable key as “In priority queue” only when it belongs to queue 0. Production IDVTC operators use priority 1, so their preferentially queued keys are displayed without the priority badge.
Root cause
useMaxPriorityKeyIndexunconditionally counts batches fromallBatches[0], andKeysTabletreats that count as the complete preferentially queued prefix.Impact
An IDVTC manager can make a destructive key decision from an inventory that incorrectly presents a preferentially queued key as having no priority designation. The manager may consequently remove that key, incur the bond-funded removal charge, and lose its effective queue placement if the stale batch is cleaned before the key is re-added.
This is low severity because the transaction still requires the operator manager’s wallet authorization, affects only that operator, and can generally be recovered by re-adding and re-queuing the key. The aggregate queue graph also provides partial—but not per-key—containment.
Scenario
priorityKeysresolves to zero and the calculated maximum priority-key index precedes every undeposited key.KeysTablerenders the key’s depositable status without the “In priority queue” badge.Drafted from LidoLens finding VKI-VIEW-01