Breakpoint London: five questions to ask before backing a Solana program

If you are at Breakpoint in London to find a Solana protocol to back, partner with or integrate, ask who can change its code and its tokens, and how fast. Most of the answer is on chain, so you can check what the team tells you before you sign anything.

Breakpoint 2026 is at Olympia, London, from 15 to 17 November, with more than 8,000 attendees expected [1][2]. These five questions fit in a hallway conversation. Each comes with what a good answer looks like and how to check it yourself.

1. Who can upgrade the program?

Most Solana programs can be upgraded. Whoever holds the upgrade authority can replace the code, and with it every rule the program enforces.

A good answer names the authority and says what it is: a multisig, not one person's key. If the team says the program is immutable, the chain should agree. A team that publishes a verified build can also show that the deployed code matches its public source.

Check it:

solana program show "$PROGRAM_ID" --url mainnet-beta
solana-verify get-program-hash -u https://api.mainnet-beta.solana.com "$PROGRAM_ID"

Authority: none means immutable; anything else is an address that can upgrade [3]. Solana Explorer shows verified-build status under the program's verified-build tab [4]. Our open-source scanner tells you whether that address is a single key or a Squads v4 multisig vault [5]:

cargo install --locked solana-authority-scan
export SOLANA_MAINNET_RPC_URL=https://api.mainnet-beta.solana.com
solana-authority-scan --cluster mainnet "$PROGRAM_ID"

2. Is there a time lock?

A time lock is the gap between a change being approved and it taking effect. In Squads, it defers execution of every approved transaction for the set period: an hour, a day, a week or a custom value [6]. That gap is when users, partners and monitors can see a change coming and react.

A good answer gives a non-zero delay for upgrades and admin changes, and says who watches the queue during it. "We can move fast in an emergency" is a reason to ask how the emergency path is limited, not a reason for no delay at all.

Check it: the scanner reports the multisig's time lock in seconds, and flags a time lock of zero [5].

Why it matters: in the Drift incident of 1 April 2026, BlockSec reports that the protocol's Security Council "operated under a 2-of-5 threshold configuration with zero timelock" [7]. Chainalysis wrote that zero timelock removed "the delay window that could have allowed detection and intervention" [8].

3. How many signers, and who are they?

A threshold is only as strong as the independence of the people behind it. Five keys held on one person's devices is one key.

A good answer gives the threshold and the number of members, and describes the signers by role (not necessarily by name): who they are, that each key is on its own hardware device, and how they check what they sign. Ask whether anyone can change the members or the threshold without a vote.

Check it: the scanner shows the threshold, the voting members and the config authority. It flags a threshold below two, a threshold below half of the voting members, and a config authority that can change members, threshold and time lock without a vote [5]. The chain cannot show who holds each key, how keys are stored, or whether one person holds several [5]. That part you have to ask about.

Why it matters: BlockSec found that two Drift signers were induced to pre-sign malicious transactions, and that durable nonces kept those approvals valid for about a week and a half before they were submitted [7]. Cyfrin reported that the signers used hardware wallets but "couldn't verify what they were signing", and recommends keeping signing devices separate from working machines [9]. Ask signers how they decode a proposal before approving it, and whether they ever sign transactions that use a durable nonce.

4. What is the incident plan?

Every protocol will have a bad day. What matters is whether the team has decided in advance who acts and how.

A good answer covers:

• a published security contact and disclosure policy;
• who can pause the program or parts of it, and under what threshold;
• what is monitored: admin actions, upgrades, large withdrawals;
• how fast the signers can meet, and when they last practised.

Chainalysis's lessons from Drift include monitoring admin-triggered withdrawals and high-value activity in real time, and automated controls such as pausing or circuit breakers when thresholds are exceeded [8]. BlockSec recommends on-chain monitoring of governance activity [7].

Check it: many programs embed a security.txt with contacts and a policy. Read it with cargo install query-security-txt, then run query-security-txt on the program [10]. The rest is a document the team should be able to show you.

5. What other authorities exist?

The upgrade key is not the only key. Ask for a list of every authority over the protocol, and compare it with the chain.

Token authorities. A mint authority means supply is not fixed. A freeze authority can freeze token accounts; if it is set to none, freezing is permanently disabled [11]. Token-2022 mints can carry more, including a permanent delegate that "can burn or transfer any amount of tokens", a pause authority that can stop transfers, mints and burns, and authorities for transfer fees, metadata and interest rates [12]. For stablecoins some of these are expected. Ask who holds them and under what rules.

spl-token display "$MINT_ADDRESS" --url mainnet-beta

Program configuration. Many programs keep their own admin key in an account: who can list collateral, change parameters or replace the admin. In the Drift incident, BlockSec reports the attacker used an UpdateAdmin instruction to move control of the protocol [7]. These keys are specific to each program, so ask the team for the list and how each is held.

A good answer is a written inventory: every authority, what it can do, who holds it, threshold and time lock. If the team does not have one, that is the finding.

A one-page summary

None of this replaces a code audit, and a clean answer on all five does not mean a program is safe. It tells you whether the people who can change it have thought about how.

What we do: our admin-plane Snapshot answers these questions for a protocol, with a written report a person has checked. It is not an audit. See https://centrob.co/#solana.