A protocol that launched with a floor of 3 can silently drift to 1
You evaluated a Solana lending protocol six months ago. The upgrade authority was behind a 4/7 multisig with independent signers. The oracle was Pyth. Governance was distributed across multiple token holders with a 48-hour timelock — passing a proposal took at least three of the largest holders acting together. Floor = 3.
Today, two of the original multisig signers have rotated off and been replaced by team-affiliated addresses. One wallet has been accumulating governance tokens through OTC purchases and now holds 62%. The oracle configuration was updated through a governance vote to add a proprietary backup feed that can override Pyth in "emergency mode."
Floor = 1. And nothing alerted you.
No announcement was made. No disclosure was filed. No security report was updated. The audit from six months ago is still technically valid — it verified the code, not the control structure. The protocol's landing page still says "governed by the community" and "secured by multisig."
This is what floor decay looks like. It happens slowly, through individually unremarkable governance actions, and the cumulative effect is a structural change that nobody tracks.
The three mechanisms of floor decay
Floor doesn't drop because someone attacks the protocol. It drops because of ordinary operational decisions that incrementally concentrate control.
1. Signer rotation on multisigs
Multisig signers rotate for legitimate reasons: a team member leaves, an advisor steps down, a hardware wallet needs to be replaced. Each rotation is a normal operational event.
But each rotation is also an opportunity for the multisig's independence to erode. If the departing signer was an external, independent party and the replacement is a team member, the effective independence of the multisig decreases — even if the threshold (e.g., 3/5) stays the same.
Over 12 months of normal turnover, a multisig that started with 3 independent external signers out of 5 can end up with 1 independent signer out of 5. The multisig still exists. The threshold hasn't changed. But the floor dropped from 3 to 1.
On Solana, multisig signer changes are on-chain transactions. They're observable. They're just not monitored by most risk frameworks.
2. Governance token concentration
Governance tokens move. They get sold by early holders. They get accumulated by whales. They get concentrated through OTC deals that don't hit the order book.
The DeFi risk assessment community tracks TVL, trading volume, and token price. Almost nobody tracks governance token concentration over time.
But governance concentration directly affects the floor. If a protocol's governance mechanism requires a token vote, and one wallet accumulates enough tokens to pass any proposal unilaterally, governance stops being an independent check on the upgrade authority.
This is especially common in protocols where governance tokens have limited utility beyond voting. Low participation rates mean a smaller absolute holding is needed for effective control. A wallet that holds 30% of the supply might be enough to pass proposals if voter turnout is consistently below 25%.
The shift is gradual. No single accumulation event looks alarming. But the structural result is that governance concentration removes one of the independent parties from the floor calculation.
3. Oracle configuration changes
Oracle dependencies are often treated as static — the protocol uses Pyth, or Chainlink, or its own feed, and that's that. But oracle configurations change through governance.
A protocol might start with Pyth as its sole oracle. Then a governance proposal adds a "backup oracle" operated by the team, "for emergency situations." Another proposal adjusts the conditions under which the backup activates. A third changes the priority order so the proprietary feed is checked first.
Each proposal is individually reasonable — redundancy is good, faster response times are good. But the cumulative effect is that the protocol's price data — which determines liquidations, interest rates, and every other financial parameter — is now controlled by the team rather than an independent network.
The oracle dependency shifted from independent to team-controlled, and the floor dropped accordingly. Each governance vote was documented. The structural implication was not.
Why periodic assessment fails
Most DeFi risk assessment follows a periodic model: evaluate the protocol once (during due diligence), check back quarterly or when there's a major version update.
This model works for traditional financial vendors because they have contracts, SLAs, and notification requirements. Your cloud provider doesn't change its service architecture without telling you.
DeFi protocols have none of this. Code changes, signer rotations, oracle reconfigurations, and governance concentration shifts all happen through on-chain actions that are publicly visible but not actively notified to position holders.
In our Q3 2026 census of Solana mainnet, the median of the 100 busiest programs had last been redeployed 13 days earlier — a busy program's code is replaced roughly every two to three weeks. That's not a quarterly review cadence — it's a continuous monitoring problem.
And code changes are just the most visible structural event. Signer rotations and governance concentration shifts happen on their own timelines, often without any code change at all.
A floor that was measured during initial due diligence is a snapshot. Six months later, it might be the same. Or it might have dropped to 1. Without continuous monitoring, you're making risk decisions on structural information that may no longer be accurate.
The case for continuous floor monitoring
Continuous monitoring means tracking the three structural components — upgrade authority, oracle dependencies, and governance concentration — on an ongoing basis and alerting when the floor changes.
This isn't monitoring for hacks or exploits. It's monitoring for the slow, quiet structural changes that individually look normal but cumulatively shift who controls the protocol.
What continuous monitoring catches that periodic assessment misses:
- A multisig signer rotation that removes the last independent external signer.
- Governance token accumulation that crosses the threshold for unilateral proposal passage.
- Oracle configuration changes that shift from independent to team-controlled feeds.
- Timelock reductions that shorten the window for position holders to react to changes.
- Emergency powers invocations that bypass normal governance — and whether they were reversed afterward.
Each of these is a floor-relevant event. Each happens at its own pace. None of them wait for your quarterly review.
What changes when you monitor floor continuously
For position holders, continuous floor monitoring changes the risk management conversation from "is this protocol safe?" (a binary at a point in time) to "has the structural risk of this protocol changed since I entered the position?" (an ongoing metric).
This enables a different set of decisions:
- Position sizing tied to floor. A position with a floor of 3 might justify a larger allocation than a position with a floor of 1. If the floor drops, the position size can be adjusted.
- Alert-based rebalancing. Instead of reviewing all DeFi positions on a calendar schedule, review only when a floor-relevant structural change occurs.
- Historical floor tracking. Understanding how a protocol's floor has changed over time tells you something about the team's trajectory — are they progressively decentralizing control, or is control quietly concentrating?
For compliance officers at regulated entities, continuous monitoring provides the documentation that DORA and similar frameworks require: not just a snapshot of the ICT dependency at onboarding, but an ongoing record of how that dependency has changed.
Floor decay is the risk nobody prices
The DeFi risk landscape is well-covered for certain dimensions: smart contract vulnerabilities (audits), economic risks (simulation and modeling), liquidity risk (TVL and volume tracking), and oracle manipulation (MEV research).
Structural dependency — who controls the code — is an undermonitored dimension. And within structural dependency, the dynamic aspect — how control structures change over time — is almost entirely untracked.
Floor decay is the risk that happens between assessments. It's the risk that's invisible in any individual governance action but compounds into a fundamentally different control structure. It's the risk that turns a diversified dependency into a single point of failure, one signer rotation at a time.
The audit protects you from bugs in the code. The floor protects you from concentration in the control structure. But a floor measured once protects you from nothing — it's the floor measured now that matters.