The question audits weren't designed to answer
A DeFi protocol gets audited. The report comes back clean. Six months later, the code under your position has changed four times — new oracle configuration, a signer rotation on the multisig, an upgrade to the lending logic. Your risk model still says "audited."
This is the gap that most DeFi risk frameworks miss entirely.
An audit answers a specific and important question: was this version of the code correct on the day we reviewed it? Were there reentrancy vulnerabilities? Were the math operations safe from overflow? Were the access controls implemented correctly?
That's valuable. Nobody should skip the audit.
But an audit doesn't answer a different question — one that matters just as much: who can change this code now?
The audit report won't tell you that the multisig behind the upgrade authority has three of five keys held by the same team. It won't tell you that the governance token is 74% concentrated in one wallet that has never delegated. It won't tell you that yesterday's governance vote shifted oracle selection to the same entity that holds the admin key.
These are structural facts about the protocol's control architecture — and they change independently of the code quality the audit verified.
Introducing floor: a measure of structural dependency
Floor is the fewest signatures that could replace the code a DeFi position depends on — the minimum across every link: the program itself, the oracle it reads, the governance that can redirect it.
A protocol with a floor of 3 means at least three signatures would be needed before the smart contract your money sits in could be modified. A floor of 1 means one key can do it alone — regardless of what the audit said.
That number is read from the chain, so anyone can check it. Independence can only lower it. A 3/5 multisig where three keys belong to the same team counts three signatures but behaves like one. A governance token with a majority held by a single wallet doesn't create independent governance. A protocol that uses its own team as the oracle operator doesn't have an independent oracle. The chain can't show who holds a key — only off-chain evidence can — so the signature count is an upper bound: the real floor is never higher, and may be lower.
Floor starts from the control structure the chain proves, then asks what the nominal one hides.
What floor measures — and what it doesn't
Floor is built from three structural components:
1. Upgrade authority. Who can change the smart contract code? On Solana, programs have an upgrade authority — an address that can deploy new code. This might be a single keypair, a multisig, or (in rare cases) revoked entirely. The question is: how many signatures does it take to use this authority — and are those signers independent?
2. Oracle dependencies. Where does the protocol get its price data? If a lending protocol uses Pyth (an independent oracle network), that's a different risk profile than a protocol running its own oracle operated by the founding team. The oracle can change the effective behavior of the contract without changing the code.
3. Governance concentration. Who controls governance decisions — parameter changes, fee adjustments, emergency actions? If one wallet holds enough governance tokens to pass any proposal, governance is nominally decentralized but structurally concentrated.
Floor takes the minimum across these three dimensions. If the upgrade authority requires 3 independent signers, but the oracle is controlled by 1 entity, and governance is concentrated in 1 wallet — the floor is 1. The weakest link determines the structural dependency.
What floor does not measure:
- Code quality. That's what the audit is for.
- Economic risk. Impermanent loss, liquidation cascades, and liquidity risk are separate dimensions.
- Smart contract bug risk. Floor tells you who can change the code, not whether the current code has bugs.
Floor and audits are complementary tools. One measures the quality of the code at a point in time. The other measures the control structure right now.
A real comparison: floor 1 vs. floor 3
To make this concrete, consider two Solana lending protocols (details anonymized, but the pattern is real):
Protocol A. $50M+ in TVL. Audited by a top firm. The audit is clean.
But: the upgrade authority is a single keypair controlled by the founding team. The oracle is a proprietary feed run by the same team. The governance token exists, but one wallet holds 70% and has never delegated. The multisig is technically 3/5, but three keys belong to team members.
Floor = 1. One entity can change everything.
Protocol B. Same TVL range. Same audit firm. Also passed.
The upgrade authority is behind a 4/7 multisig with verified independent signers — including external parties from different organizations. The oracle is Pyth, an independent network. Governance requires a token vote with a 48-hour timelock; no single wallet holds a majority, and passing a proposal takes at least three of the largest holders acting together.
Floor = 3. The weakest link is governance: at least three independent holders would have to coordinate. The multisig needs four signers, and the oracle is run by an independent network rather than by the team.
Both protocols are "audited." Both are "governed." Both have multisigs.
The audit reports look nearly identical. The structural reality is completely different.
If you hold a position in Protocol A, one team can modify the contract under your assets at any time. If you hold a position in Protocol B, three independent parties would need to coordinate — a fundamentally different risk exposure.
Why this matters now
Three developments make structural dependency measurement increasingly urgent:
1. Institutional DeFi adoption. As funds, family offices, and regulated financial entities allocate to DeFi positions, they need risk metrics that fit into existing frameworks. "It's been audited" doesn't satisfy an investment committee or a risk officer. A number — floor = 1 vs. floor = 3 — does. It's a metric you can put in a risk memo and defend.
2. Regulatory pressure. In its September 2026 response to the Commission's MiCA review, the European Banking Authority recommended regulating crypto-asset lending, including access to DeFi lending protocols — and floated certifying those protocols for cyber resilience. DORA (the Digital Operational Resilience Act) already requires EU financial entities to keep a register of their ICT third-party arrangements, but says nothing about how a DeFi protocol — with no contract and no provider — fits into it. Both will need quantifiable inputs, not labels.
3. Silent structural change. Protocol control structures change without announcements. Signers rotate off multisigs. Governance tokens accumulate in fewer wallets. Oracle configurations get updated. The audit stays valid — but the control architecture underneath has shifted. Without continuous measurement, you're making risk decisions based on outdated structural information.
How floor is measured
Measuring floor means reading on-chain data for each structural component — and being explicit about what on-chain data cannot tell you:
Upgrade authority. For each Solana program a position depends on, read the upgrade authority from the chain: a single key, a program-controlled account such as a multisig (with its threshold and signer addresses), or revoked. The chain shows signatures, not people. A key held in MPC or threshold custody looks exactly like an ordinary keypair, and whether a multisig's signers belong to different organizations can only be established from off-chain evidence. Independence is a claim to verify, not something the address reveals.
Oracle dependencies. Map which oracle feeds the protocol reads and who operates them. An independent oracle network (like Pyth or Switchboard) counts as an independent party. A proprietary oracle run by the protocol team does not add independence to the floor calculation.
Governance concentration. From the token distribution and the governance program's configuration: what share is needed to pass a proposal, how many of the largest holders it takes to reach it, what timelocks stand in the way, and whether delegation is meaningfully distributed or concentrated.
The floor is the minimum across all three dimensions — the weakest link — for each position.
What this means for different stakeholders
For fund managers and position holders: Floor gives you a number to put in your risk model. Instead of "audited" or "not audited" (a binary that misses structural risk), you have a metric that quantifies your actual dependency exposure. A position with a floor of 1 is a position where one party can change the rules under your investment. Price that accordingly.
For compliance and risk officers: If your organization holds DeFi positions and operates under DORA, MiCA, or similar frameworks, floor provides a quantifiable input for your ICT dependency register. "Protocol X — floor 2, oracle: Pyth, last structural change: 3 days ago" gives your regulator actionable information that "Protocol X — audited Q2 2026" does not.
For protocol teams: Floor is a measure of structural maturity. A protocol with a floor of 1 has centralized control — which may be appropriate for an early-stage protocol, but becomes a liability as TVL grows and institutional capital enters. Increasing the floor through genuine decentralization of control structures is a measurable, verifiable step.
The floor doesn't replace the audit. It measures what audits don't.
Audits and floor are answers to different questions:
- Audit: Is this code safe?
- Floor: Who can change it?
If you manage DeFi positions — for yourself, for clients, or for a regulated entity — you need both. The audit protects you from bugs. The floor protects you from concentration — the silent, structural kind that doesn't show up in any security report.
The next time you evaluate a DeFi protocol, after checking the audit, ask one more question: how few signatures could change the code under my position — and whose are they?
That number is the floor. And it might be lower than you think.