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.

bZx

Looks Healthy
Why this score
  • Implementation can be replaced (upgradeable proxy)
  • On-chain governance controls upgrades
  • Timelock enforces at least 5.7 days delay
  • No governance bypass paths detected
Control-Plane Score
88/100
Higher = cleaner
Control plane only · code-layer risk is out of scope

Low Upgrade Risk

Low Risk

Upgrades require on-chain governance and wait 5.7 days before taking effect.

What this means

The control setup looks healthy. Users and monitoring systems have meaningful time to react before any upgrade goes live.

Reaction window

5.7 days. Users have time to monitor and respond.

Proxy Pattern
Upgradeable Proxy
The implementation logic can be replaced
Who Can Upgrade
On-chain governance
Token holders vote on every upgrade
Reaction Window
5.6 days
Users have time to react before upgrades take effect
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.

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.

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.
  3. 3Add a timelock, such as 24–72 hours, to every upgrade path.Already in place
  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 ofschedulesownsUUPS PROXYUUPS PROXYcontractOwner (from event)Owner (from event)timelockGovernor (OZ_GOVERNOR)Governor (OZ_GOVERNOR)governor
admin of: proxy admin relationshipschedules: timelock schedulingowns: 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.

Other control points found

1 additional permission or admin role detected across the contracts. They aren't part of the main upgrade chain but still allow some level of control. Switch to Advanced to inspect each one.

Upgrade Activity

Recorded implementation or admin changes detected on-chain.

No upgrades have been recorded for bZx since it was deployed.

Want a control-plane scan for your protocol?

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.

Scan My ProtocolTalk to Themis →