Multisig and Timelock Analysis: Which Solana Protocols Can Rug You

The risk that never shows up in the APY

A yield number tells you what a protocol pays. It tells you nothing about who can change the rules while your money is inside.

Every DeFi protocol on Solana runs on a program that someone can upgrade. That someone holds the upgrade authority. If a single key holds it, one signature, or one compromised laptop, can swap the code under your deposit and drain the pool. If a multisig holds it, several people have to agree first. If a timelock sits on top, there is a mandatory delay between the decision and the change, which is the only window you get to pull funds before new code goes live.

Most yield dashboards never mention any of this. We pulled the admin controls for the ten largest Solana DeFi protocols by TVL. The results are worse than the marketing suggests.

Upgrade authority, in plain terms

On Solana, a program is deployed with an upgrade authority. Whoever holds it can push new bytecode to the same address your funds interact with. There is no fork, no migration, no opt-in. The contract you trusted yesterday becomes different code today.

Three configurations exist, from worst to best.

A single signer holds the authority alone. One key, one point of failure. A phished seed phrase or a rogue insider is enough. This is the setup behind a large share of DeFi exit scams, because "rug pull" usually means an admin key with nothing standing in its way.

A multisig spreads the authority across several holders. A threshold has to sign, say 4 of 7, before anything executes. This kills the single-laptop attack and raises the cost of an insider job. It does not slow anything down once the threshold signs.

A timelock adds a mandatory delay after signing. The change is queued in public and does not execute for hours or days. That delay is the depositor's escape hatch. It is the difference between watching an upgrade get scheduled and getting drained in one block.

The point people miss: a multisig protects against a compromised key. A timelock protects against a malicious or coerced quorum. They solve different problems. A protocol that has one and not the other is only half covered.

The data: who holds the keys on Solana's top 10

Here is the current picture for the ten biggest Solana DeFi protocols by TVL. Timelock and multisig status come from official docs, protocol statements, and on-chain multisig addresses where published.

One protocol out of ten has a documented, time-bound delay on upgrades. One. Everything else either signs and ships instantly, or does not publish enough to tell.

The standouts, good and bad

Jupiter Lend is the only one doing it right. It runs a 12 hour timelock after the multisig signs, confirmed by the official account. Twelve hours is not long, but it is a real public window. If a malicious upgrade gets queued, depositors have half a day to exit before it can execute. No other protocol in this list gives you that. Jupiter Lend scores a 75, and the timelock is a large part of why.

Raydium states plainly that it has no timelock. Straight from its own docs: it does not employ a timelock program function for updates. Changes go through internal review and testing, then straight to production with no on-chain delay. This is a billion dollars of TVL with no enforced pause between an admin decision and live code, and no published multisig either. The process may be careful. The guarantee is absent.

DoubleZero is the black hole. $878M staked, zero public audits, no documented multisig, no timelock found anywhere. The protocol went to mainnet in October 2025 and the stake pool is newer still. Nearly nine hundred million dollars sit behind governance that nobody outside the team can inspect. That is not a low score because the code is bad. It is a low score because there is nothing to verify.

xStocks upgrades through a proxy with no delay. A proxy pattern lets the team swap implementation contracts whenever they want, with no timelock and no transparent governance. Independent analysis flagged the same gaps: no timelock on admin functions, no bug bounty, no formal verification. Custody sits under Swiss regulation, but the smart contract layer is wide open. It scores a 53, a D, and the admin setup is the main reason.

Squads is the standard, but the timelock is optional

Most of the serious protocols here use Squads for their multisig. Kamino, Jito, and Jupiter all route program upgrades through it. Squads is the de facto multisig on Solana, and its v4 supports a configurable timelock out of the box.

The problem is that the timelock is opt-in. Squads gives you the tool. Whether a protocol turns it on, and how long the delay runs, is a choice most teams either skip or never document. Kamino runs on Squads and Squads defaults to a 24 hour countdown, but Kamino's specific configuration is not published, so we mark it probable and unconfirmed rather than take credit for it. Sanctum spreads its authority across eleven ecosystem members, a genuinely strong multisig, and still runs no timelock. A wide quorum makes a key compromise harder. It does nothing to slow a quorum that decides to act.

The Drift hack in April 2026 is the reason this matters right now. Roughly $285M gone, and the post-mortem points to an oracle failure combined with a multisig bypass. Having a multisig was not enough. The industry lesson is that above $100M in TVL, a multisig without a timelock leaves depositors with no reaction window when something goes wrong at the top.

How yieldwire scores admin control

Admin control is a first-class input to our Protocol Security Score, not a footnote. We grade it on the actual configuration, not on intent.

A protocol that publishes its multisig address and runs a real timelock scores well on this dimension. One that signs and ships instantly loses points. One that publishes nothing, like DoubleZero, gets treated as if the worst case is true, because from a depositor's seat it might as well be. This admin score combines with audit history, oracle setup, liquidation risk, and TVL depth to produce the full Protocol Security Score you see on every listing in /yields and on each protocol page.

The gap this exposes is a real one. Nine of the ten largest protocols on Solana would give you no enforced warning before a program upgrade. That is not a reason to avoid DeFi. It is a reason to know exactly what you are standing on.

What to check before you deposit

You do not need to read Solana bytecode to size up admin risk. A few questions get you most of the way.

Who holds the upgrade authority? If the docs name a multisig and publish the address, that is a good sign you can verify on-chain. If the answer is one key, or the docs are silent, treat that as the headline risk, not a detail.

Is there a timelock, and how long? A named delay in the docs, like Jupiter Lend's 12 hours, is the strongest signal a protocol offers. No timelock means any approved change is live the moment the quorum signs, and you find out after.

How wide is the multisig? A 2 of 3 among the founding team is weaker than a 4 of 7 across independent ecosystem parties. Sanctum's eleven-member setup is the stronger model even without a delay.

Can you verify any of it? If a protocol publishes nothing about its governance, that absence is the answer. Undocumented is not neutral. It is the worst grade until proven otherwise.

You can filter for this directly. The risk filter lets you screen out protocols below a security grade, and the security rankings show the full breakdown for every protocol we track, admin controls included. Before you chase an APY, check who can change it and how much warning you would get. On nine of the ten biggest protocols on Solana, the answer today is none.

This is analysis, not financial advice. Admin control data reflects public documentation and on-chain records as of July 2026 and can change. Always verify a protocol's current governance setup before depositing.