Protocol Report · Ethereum
DemoThis is a sample report generated from public on-chain data, not a live audit. Run a fresh scan on any address to see current governance state.

Angle

High Risk
Why this score
  • Implementation can be replaced (upgradeable proxy)
  • Multisig controls upgrades
  • No enforced delay found on discovered upgrade paths
  • No governance bypass paths detected
Control-Plane Score
35/100
Higher = cleaner
Control plane only · code-layer risk is out of scope

Significant Upgrade Risk

High Risk

Upgrades take effect in 0 seconds, less than typical safe DeFi standards.

What this means

Even though this protocol has some governance protection, gaps exist that could let upgrades reach users faster than expected, including in worst-case scenarios.

Reaction window

0 seconds on the standard path. Bypass paths may be faster.

Proxy Pattern
Upgradeable Proxy
The implementation logic can be replaced
Who Can Upgrade
Multisig wallet
Multiple signers must approve before any upgrade
Reaction Window
0 seconds
No enforced delay before upgrade execution
Governance Bypass Paths
None detected
All upgrade paths appear to use the standard process

Key Findings

The main control-plane risks found in this scan, with plain-English impact and remediation.

Critical Risk

No effective upgrade delay

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.

Structural Risk

Upgradeable proxy detected

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.

Possible Failure Scenario

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.

  1. 1A controller decides to upgrade the protocol, for any reason, malicious or not.
  2. 2The upgrade transaction is submitted on-chain.
  3. 3Because there is no enforced delay, the new implementation activates on the same block.
  4. 4Users transacting in that block experience the changed behavior with no warning.
  5. 5There is no public proposal-to-execution window for the community to review.

Recommended Fixes

4 of 7 recommended fixes still apply to this protocol.

Immediate fixes

Architectural changes that close the most direct risk paths.

  1. 1Remove direct wallet upgrade permissions.Already in place
  2. 2Move upgrade authority to a multisig with a meaningful threshold, such as 3-of-5 or higher.Already in place
  3. 3Add a timelock, such as 24–72 hours, to every upgrade path.
  4. 4Verify that no alternate upgrade path bypasses governance or the timelock.Already in place

Operational fixes

Process and monitoring practices that reduce ongoing risk.

  1. 1Monitor implementation changes in real time and alert users on any upgrade.
  2. 2Maintain a public changelog for every upgrade.
  3. 3Document the intended governance and emergency upgrade process.

Evidence

The on-chain data behind the findings above. Switch to Advanced to see raw addresses, blocks, and method-level detail.

Control Map

Who can change the protocol and through which path.

How to read this map
owns = controls another contract or permission
upgrades = can change the implementation
acl of = has an access-control relationship
admin ofownsTRANSPARENT PROXYTRANSPARENT PROXYcontractProxyAdminProxyAdminproxy adminSafe 4/6Safe 4/6gnosis safe
admin of: proxy admin relationshipowns: ownership control

Governance Bypass Paths

Upgrade paths that may bypass the expected governance or timelock delay.

No bypass paths detected. All upgrade routes appear to follow the standard governance process.

Multisig setup

Several wallets must agree before any change can happen.

Signers required
4 of 6 owners
Add-on modules
None
Transaction guard
None

6 signer addresses hidden. Switch to Advanced to see them.

Upgrade Activity

Recorded implementation or admin changes detected on-chain.

Total upgrades recorded
4
Most recent block
#19,432,470
Latest code change
0xe59D…919b → 0xc3ef…5c5c
Trigger source
Not recorded

Per-event detail (block numbers, sender addresses, code addresses) is hidden in Simple view. Switch to Advanced to see all 4 events.

Need this checked for your protocol?

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.

Scan My ProtocolTalk to Themis →