multisig signer overlap is one of the fastest ways a protocol can look decentralized from the outside while remaining concentrated in practice. A project may show separate multisigs for treasury, upgrades, emergency pause, bridge controls, or incentive emissions. If the same small group sits behind all of them, the operational separation is weaker than it appears.
Radar treats signer overlap as protocol-ops risk, not as a cosmetic governance note. Users, allocators, and ecosystem researchers need to know whether “different” controls are actually independent or whether one social circle can still push the entire system through multiple paths.
Map the control surface first
Start by listing every multisig or privileged signer set that matters: treasury, upgrade executor, emergency pause, parameter manager, bridge control, and any market-specific or vault-specific operators. Many protocols publish only the most visible signer set, which makes the rest of the control surface easy to miss.
The checklist only becomes useful when each privilege is mapped to a real address and a real threshold. Without that, researchers end up comparing brand names rather than control paths.
Look for the same humans behind different labels
The next step is overlap detection. Compare signer addresses, public profiles, foundation roles, investor affiliations, and service-provider relationships. Two multisigs may have different names while still relying on the same founders, the same core team members, or the same outsourced signer operator.
That matters because independence is what gives role separation value. If treasury and emergency pause are controlled by the same small cluster, the protocol may still have one real point of coordination risk even if the documentation implies otherwise.
Check whether overlap is concentrated around the highest-power actions
Not every overlap deserves the same score. Shared signers on a low-impact marketing wallet are not the same as shared signers on the upgrade executor and emergency pause. The key question is whether the overlapping group can both change code and control user access, or both move funds and alter protocol parameters.
When the highest-power actions share the same people, the protocol has a deeper concentration problem than a superficial multisig count suggests. Radar readers should weight that more heavily than the total number of signers shown on the website.
Review outside dependencies, not just wallet addresses
Signer overlap also hides in offchain operations. A protocol can distribute keys across nominally different signers but still rely on one custody provider, one internal operations team, or one emergency coordination process. If the same organization provisions the devices, manages recoveries, and coordinates sign-offs, the practical diversity may still be thin.
That does not make the protocol unusable. It changes how researchers should frame the risk. The more coordination dependence sits outside the chain, the less comfort you should take from a high signer count alone.
Watch rotation, churn, and disclosed succession plans
Healthy protocols usually show some history around signer rotation, threshold changes, incident response, or governance hardening. A static multisig with no public sign of review can become riskier over time, especially as personnel change or the protocol grows faster than its control model.
Look for evidence that the team has thought about signer replacement, compromised keys, and emergency continuity. A system with modest overlap but visible maintenance can be healthier than a larger multisig that never changes and never explains itself.
Turn the checklist into a risk label
The practical output does not need to be complicated. Label the protocol's signer structure as low, medium, or high overlap risk. Note whether the overlap touches upgrades, pauses, treasury, or bridge functions. Then decide whether that concentration fits the protocol's maturity, TVL, and user expectations.
Radar is not trying to eliminate every protocol with any overlap. The goal is to stop mistaking interface-level decentralization for control-level decentralization.
