Static Bytecode Analysis

Scanner

Screen ERC-20 contract bytecode for opcode-level risk: self-destruct, delegatecall, owner-mintable supply, blacklists, fee traps, and proxy indirection.

Read this first. This is a heuristic screen, not an audit. Bytecode analysis detects the presence of risky opcodes and selectors — it cannot prove how they're guarded or whether they're reachable. A clean result is not a guarantee, and a flag is not proof of malice. Verify against source and get a professional audit before trusting funds.
Opcode View

Disassembler

Full EVM opcode listing with program counters, PUSH immediates, and jump destinations resolved. Uses bytecode from your last scan automatically, or paste fresh below.

PC
Byte
Instruction
Structure Recovery

Control Flow

Recovers basic blocks and the jumps between them. A basic block is a straight run of instructions with one entry and one exit — execution enters at the top and runs to the bottom without branching. Blocks connect through jumps, forming the contract's control-flow graph.

Fact — derived mechanically from the bytes Inferred — heuristic, may be wrong
How to read this — and what it does not mean. Block boundaries, instruction listings, and statically-resolved edges (where a jump target is a constant pushed immediately before the jump) are facts — they follow directly from the bytecode. Where a jump target is computed on the stack, the edge is shown as unresolved: this means the graph is partial. A missing edge is not proof that no path exists. Function names attached to blocks come from a 4-byte signature dictionary and are inferred — selectors can collide, so a name is a probable match, not a guarantee of behaviour. Finally: any block flagged as containing a risky opcode indicates only that the instruction is present in the code. It does not establish that the code path is reachable, unguarded, ever executed, or that any misuse, exploit, or breach has occurred or could occur. Presence is not exploitation, and is not intent.
Plain-language glossary — what these words mean

A contract is a list of tiny instructions the blockchain runs one after another. Here's what the ones you'll see actually do, in everyday terms. Hover any instruction in the listings below for the same definition inline — every opcode has one.

Reading the structure
Block
A straight run of instructions with no branching — like one paragraph the code reads top to bottom before deciding where to go next. Grouping into blocks just makes the flow readable.
JUMPDEST
A legal landing spot — a labeled door the code is allowed to JUMP to. Does nothing by itself; it just marks where a block can begin.
Moving around & ending
JUMP
"Go to a different spot in the code and continue from there" — the equivalent of "now go to step 14."
JUMPI
A conditional jump: "if this is true, go there; otherwise keep going." This is how if statements are built.
STOP
"Done — halt here, nothing to hand back." A clean, quiet ending.
RETURN
"Finished successfully — here's the answer." Ends normally and hands back a result.
REVERT
"Stop, something's wrong — undo everything." Cancels the whole operation, e.g. you tried to send more tokens than you have.
INVALID
An instruction that means nothing — hitting it stops the code with an error. Often a deliberate dead-end or the end of real code.
Doing math & checks
ADD / SUB / MUL / DIV
Plain arithmetic — add, subtract, multiply, divide. Used constantly for things like updating balances. Harmless on their own.
EQ / LT / GT
Comparisons — "are these equal?", "is this less than / greater than that?" The yes/no answers that drive every decision.
ISZERO
"Is this zero?" Often used to test a condition or flip a yes/no.
KECCAK256
Runs data through a one-way scrambler to get a unique fingerprint (hash). Used for IDs, storage slots, and signatures.
Scratch values (the "stack")
PUSH
Puts a fixed value written right into the code onto the scratch pile — a number, an address, or a jump target.
POP
Throws away the top scratch value the code no longer needs. Routine bookkeeping.
DUP / SWAP
Duplicate a recent scratch value, or swap two of them around. Pure plumbing for juggling values.
Saving & reading state
SLOAD
Reads from permanent storage — the contract's saved state, like a balance or the owner's address.
SSTORE
Writes to permanent storage — how the contract actually changes its saved state (e.g. updating who owns what).
MLOAD / MSTORE
Read and write temporary memory that's wiped when the call ends — a scratchpad, not saved state.
LOG (events)
Writes a note to the logs that wallets and apps can watch for — this is how a Transfer gets "announced."
Who's involved
CALLER
"Who is asking?" — the address that triggered this code. Used for permission checks like "is the caller the owner?"
ORIGIN
The original wallet that started the whole transaction. Using it for permission checks is usually a red flag.
CALLVALUE
How much native coin (e.g. ETH) was sent along with the call.
BALANCE
Looks up how much native coin an address holds.
Talking to other contracts — watch these
CALL
Calls another contract, optionally sending coin along. The normal way contracts talk to each other.
STATICCALL
Calls another contract in read-only mode — it can't change anything. A safe lookup.
DELEGATECALL
Runs another contract's code as if it were this one's own, with full access to this contract's storage. Powers upgradeable proxies — and is the most common backdoor vector.
CALLCODE
An old, deprecated cousin of DELEGATECALL. Rarely legitimate — treat with suspicion.
CREATE2
Deploys a new contract at a predictable address. Occasionally used for "metamorphic" tricks where the code at an address can later change.
SELFDESTRUCT
Erases this contract and sweeps its balance elsewhere. In a token this is highly unusual and dangerous.

Every other instruction has a hover definition too — point at any opcode in the listings to read it.

Preferences

Settings

Appearance choices are remembered for this session.

Theme
Switch between light and dark.
Typeface
Display + body font pairing.