This protocol appears upgradeable by externally owned wallets with no enforced delay. If one of these wallets is compromised or misused, the implementation can be changed immediately.
An attacker may not need to exploit contract logic. Control of an upgrade authority may be enough to replace the implementation.
0 seconds. Users, governance, and monitoring systems may have no time to respond before the change is live.
The main control-plane risks found in this scan, with plain-English impact and remediation.
Meaning: A normal wallet (controlled by a private key, not a multisig or governance contract) appears able to upgrade the protocol directly.
Fix: Move upgrade authority behind a multisig with multiple signers, and add a timelock so changes have a public waiting period.
Meaning: Upgrades can be executed immediately. There is no enforced waiting period between an upgrade being proposed and it taking effect on-chain.
Fix: Enforce a meaningful timelock delay (e.g. 24–72 hours) on every upgrade path so users and monitoring systems have time to react.
Meaning: 1 upgrade route may avoid the expected governance process.
Fix: Audit each alternative path. Remove direct upgrade permissions and ensure every route enforces the same delay and approval requirements.
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.
All 7 recommended fixes 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.
Upgrade paths that may bypass the expected governance or timelock delay.
Wallet 0xE2e2…16a3 can upgrade with zero delay
This path appears to bypass the expected governance delay. If the wallet is compromised or misused, the implementation can be changed immediately.
Remove direct wallet upgrade authority or place it behind the same multisig and timelock as the standard upgrade route.
Recorded implementation or admin changes detected on-chain.
Per-event detail (block numbers, sender addresses, code addresses) is hidden in Simple view. Switch to Advanced to see all 2 events.
Get a control-plane scan showing who can upgrade your contracts, how fast, and through which paths. Find direct upgrade paths, missing delays, and governance bypasses before they become incident response problems.
Includes authority graph, bypass paths, effective delay, and upgrade history.