Upgrade multisig signer configuration (M/N)
Jupiter Perpetual Exchange's assessment for RD-F-026 — scored yellow on the v1.7.0 rubric. The evidence below is the curator's reasoning for this score.
Evidence summary #
Squads v4 multisig config AxkJ8oH5aDu4ZRWfsujPtxdb6Vhq4gDehpoReBgrUUSm decoded on-chain: threshold=4, members=7 (4-of-7). Threshold is consistent with peer cohort (Kamino 5/10, Sanctum Router 4/7, Jupiter aggregator v6 4/7). At $691M TVL, 4/7 is a reasonable majority threshold. Member public keys are on-chain but their identities and custody arrangements are not publicly attested. Scored yellow: threshold is adequate; signer identity/custody attestation is missing.
Sources #
- TxSquads v4 multisig config account AxkJ8oH5 on SolscanOn-chain borsh decode of Squads v4 multisig config AxkJ8oH5aDu4ZRWfsujPtxdb6Vhq4gDehpoReBgrUUSm: threshold=4 (u16 LE bytes 72-74), members vec length=7 (u32 LE after member offset per SOLANA_GOVERNANCE.md Step4 layout)retrieved 2026-05-16
- SOLANA_GOVERNANCE.md curated empirical reference tableSOLANA_GOVERNANCE.md curated reference: Kamino KLend 5/10 Squads v4 12h; Sanctum Router 4/7 Squads v4 none; Jupiter v6 4/7 Squads v3 — confirms 4/7 is peer-cohort-normalretrieved 2026-05-16
Methodology #
Read `threshold` and `getOwners()` on the multisig controlling upgrade / sensitive ops. Store as `required` (M) and `total` (N); render as "M/N". For EOA admins record `required=1, total=1` (display "1/1"). Null when admin is immutable or full DAO with no fixed signer set.
See the full factor methodology and distribution across all protocols →