Smart Contract Diff
See what changed, who gained control and what new behavior became possible.
Compare two EVM contracts across verified source, ABI, permissions, token controls, proxy state and runtime bytecode. Every material conclusion is connected to the evidence that supports it.
Compare deployed contract intelligence
Select the network and contract address for each side. Wallet connection is not required.
Resolving contracts and evidence
Checking verification, proxy implementations, interfaces and runtime code.
- Contract identity
- Proxy resolution
- Source and ABI
- Risk delta
Smart Contract Diff Report
—What materially changed?
Risk direction describes the change between the selected contracts. It is not an absolute safety score.
Comparison complete
Review the evidence-backed changes below.
What is being compared?
Proxy shells and resolved implementation logic are presented separately.
Permissions, controls and behavior
Changes are grouped by practical review category instead of being reduced to a raw line count.
Functions, events and errors
Added, removed and changed interface definitions can affect permissions, integrations and user workflows.
Source files and normalized change regions
Formatting noise is reduced so material file and function changes remain easier to review.
Where logic lives and how it changed
Proxy state, compiler storage artifacts and normalized bytecode are assessed as separate evidence layers.
Why these changes may matter
Each conclusion stays bounded by the evidence and identifies the next manual review step.
Facts, indications and unavailable checks
Missing evidence is shown as unavailable and is never converted into reassurance.
Evidence ledger
Coverage limits
Understand the evidence behind a contract change
Open the explanation that matches your review objective.
01What Smart Contract Diff revealsComparative evidence, not an absolute safety verdict+
Smart Contract Diff compares the supported evidence available for two deployed EVM contracts. It identifies differences in verified source files, callable functions, events, errors, proxy state, runtime bytecode and risk-relevant control patterns. The primary question is not whether either contract is universally safe. The question is what changed between Contract A and Contract B, what authority or behavior may have expanded or narrowed, and which evidence should receive manual review.
02Review ownership, roles and privileged functionsFind newly introduced or changed control pathways+
Ownership and access-control changes can alter who is able to mint, pause, blacklist, change fees, rescue assets, replace implementations or call external contracts. A privileged function is not automatically malicious, but its introduction or authorization change is material. The report connects the classification to ABI definitions, verified source patterns or proxy-state evidence and avoids claiming a real-world identity for an administrator unless independently established.
03Understand proxy and implementation comparisonsA forwarding shell is not the same as implementation logic+
Upgradeable systems often expose a proxy address while executing code stored in a separate implementation. Comparing proxy bytecode alone can miss the behavior that users actually interact with. TokenToolHub checks standard implementation, administrator and beacon slots, recognizes common minimal-proxy patterns and keeps the proxy address separate from the resolved logic address. A changed implementation or administrator is highlighted as a distinct evidence category.
04Interpret ABI and source changesSeparate interface compatibility from implementation evidence+
The ABI describes externally visible functions, events and errors. Added or removed definitions can affect integrations even when the underlying source change appears small. Verified source provides a deeper view into function bodies, modifiers and state changes. When either source bundle is unavailable, the report states that limitation directly instead of assuming that an undetected feature is absent.
05Know the storage-analysis boundarySource lines alone cannot prove upgrade storage safety+
Upgradeable storage compatibility requires matching compiler artifacts or reliable storage-layout data. When both sides provide those artifacts, the beta compares slots, offsets, labels and types and surfaces direct conflicts. When the artifacts cannot be reproduced, storage analysis remains unavailable. A professional upgrade review may still require compiler-matched OpenZeppelin validation and manual inspection.
06Use risk direction correctlyChange materiality is not a token recommendation+
The headline describes the direction and materiality of detected changes: reduced exposure, no material change detected, mixed changes, increased privilege surface, significant high-priority changes or inconclusive evidence. It does not guarantee safety, prove exploitability or determine whether a deployment is financially appropriate. Always combine the comparison with current on-chain state, governance context and independent review.
TokenToolHub provides automated public-chain research. A comparison is not a formal security audit, legal opinion or investment recommendation.