Upgrades go through no upgrade authority detected with a no upgrades possible reaction window.
The setup has reasonable protection, but the delay is short or the controller setup has limited safeguards. Consider improvements before treating this as fully safe.
no upgrades possible.
The main control-plane risks found in this scan, with plain-English impact and remediation.
Meaning: The protocol logic can be replaced after deployment. This is common, but it makes the safety of the upgrade process critical.
Fix: Document the upgrade process publicly and monitor implementation changes in real time.
A concrete sequence of how this risk could play out. This is illustrative, not a prediction.
This is not a detected exploit. It illustrates the control failure this configuration may allow.
5 of 7 recommended fixes still apply to this protocol.
Architectural changes that close the most direct risk paths.
Process and monitoring practices that reduce ongoing risk.
The on-chain data behind the findings above. Switch to Advanced to see raw addresses, blocks, and method-level detail.
Who can change the protocol and through which path.
Recorded implementation or admin changes detected on-chain.
See exactly who controls upgrades, how long users have to react, and whether any path can bypass governance, for any protocol you operate or depend on.
Includes authority graph, bypass paths, effective delay, and upgrade history.