Understand the risk.Verify the evidence.

Checks for recognized ownership mechanisms that may grant administrative authority over a contract.

An owner may have permissions that affect how a protocol operates.

Identify the owner and review how administrative permissions are managed.

Ownership alone does not indicate malicious behavior. Not finding a recognized owner does not prove that no administrative control exists.

Checks whether available contract evidence exposes recognized mechanisms for pausing operations.

Pause controls can protect users during emergencies but may also interrupt normal operations.

Review who can activate a pause and under what conditions.

A missing pause signal does not guarantee that operations cannot be restricted by other mechanisms.

Checks for recognized mechanisms that may restrict certain addresses from interacting with a contract.

Address restrictions can support security or compliance policies but may also affect user access.

Review who can manage restrictions and which operations may be affected.

Detecting a capability does not mean that any address is currently blocked.

Checks for recognized mechanisms that may limit access to approved addresses.

Allowlist controls can determine who is permitted to use specific contract functions.

Identify who manages access permissions and whether restrictions are documented.

An allowlist mechanism does not necessarily restrict every operation or every user.

Identifies supported patterns of functions or permissions that may provide elevated contract control.

Privileged operations can introduce operational dependencies and governance risks.

Review the permissions, their controllers, and safeguards such as multisignature authorization or timelocks.

The detector does not establish the complete permission structure or guarantee that every privileged operation has been identified.

Indicates when supported sources provide evidence that deployed contract code has been verified.

Verification improves transparency and enables deeper examination of the deployed code.

Review the verified source and distinguish contract verification from an independent security audit.

Verified source code does not guarantee that a contract is safe.

Identifies supported proxy patterns in which a contract delegates execution to another implementation.

The implementation may contain the logic that matters most for risk analysis.

Inspect the implementation and determine whether the specific proxy architecture supports upgrades.

Not every proxy is upgradeable. An EIP-1167 minimal proxy, by itself, does not establish upgrade authority.

Indicates whether Cerynq could identify the implementation address associated with a supported proxy.

Resolving the implementation helps associate the proxy with its underlying contract logic.

Inspect the resolved address and the available verification evidence.

Successful resolution does not prove that the implementation is secure.

Describes the available sources and traceability of information used in an analysis.

Provenance helps users understand where findings originated and evaluate evidence quality.

Inspect the reported sources, verification status, and any missing information.

Traceable evidence does not guarantee that every risk has been identified or that every conclusion is complete.