Yul
Yul security review
Yul is the low-level language used in Solidity assembly blocks. Hackerbane audits that assembly, because the compiler no longer checks it for you.
scope
What we review
We audit Yul inside Solidity assembly blocks: the math, the memory layout, the calls out, and the memory-safe annotations the compiler treats as fact. Typical issues are wrapping add on a calldata length, dirty high bits on an address, CALL that reports success against an empty account, and a memory-safe annotation that does not match the loads and stores.
Wrapping add, sub, and mul on offsets and lengths taken from calldata.
The memory model: scratch space, the free memory pointer at 0x40, and the zero slot at 0x60.
Dirty high bits on addresses and packed types. The ABI decoder that normally unpacks Solidity arguments is gone, so those bits stay dirty unless you mask them.
CALL that reports success against an empty account, or a token that returns false instead of reverting.
Memory-safe annotations that do not match the loads and stores, so compilation through the intermediate representation (via-IR) can move stack variables into memory it thinks is free.
Advanced Threat Detection
We built our own advanced threat detection stack that is more performant and cheaper than our competitors. We use a state-of-the-art AI harness coupled with world-class senior security engineers with proven experience finding vulnerabilities in well-tested software.
How we review this language
A Yul review runs the same five-stage engagement as every Hackerbane audit. We read each assembly block as code with no compiler help: every add on a pointer, every mstore, every call.
Two senior engineers read the assembly in parallel. We check memory-safe annotations against the actual loads and stores, confirm masks on every narrow type that crosses back into Solidity, and run differential tests against a Solidity reference when one exists.
Scope and threat model
We lock the objects, the commit, the target chains, the fork you deploy against, and any proxy the assembly sits behind, before the review starts.
Architecture and design review
We reconstruct the intended memory and storage layout from the assembly and check it against the proxy and the callers. That finds design flaws a line-by-line read would miss.
Hybrid code and infrastructure review
Two senior engineers read the Yul in parallel, backed by static analysis, custom detectors, and differential tests against a reference implementation of each primitive.
Exploitability and root-cause analysis
High and Critical findings ship with a proof of concept on the EVM and the root cause, so the class of bug gets fixed rather than one instance, including the fork specific assumptions behind a gas trick.
Reporting and remediation
A prioritized report, a live walkthrough, and verification of every in scope fix within the remediation window.
Tools and practices
We work in the repository you already use and build against the compiler you ship. Where a Yul helper has a Solidity equivalent, we run both on the same inputs and treat a mismatch as a finding. Those harnesses go back with the report.
What you get
Prioritized findings your engineers can ship against, each with root cause and a recommended fix.
Verifiable proofs of concept for High and Critical issues, reproduced on the EVM.
A report you can share with partners, exchanges, investors, and regulators.
Remediation verification and a final report that reflects the fixed state of the assembly.
The differential harnesses that compare the Yul to a Solidity reference, including truncated and oversized calldata.
How to prepare
| # | Before review starts |
|---|---|
| 01 | Builds run cleanly from a fresh checkout, against the compiler release you ship. |
| 02 | Assembly blocks marked memory-safe are listed, with the memory they are allowed to touch. |
| 03 | The intended behaviour of every external call is documented, including failure, empty accounts, and returndata. |
| 04 | Storage layout is documented if the assembly sits behind a proxy or writes fixed slots. |
| 05 | Scope is defined: which objects, which commit, and which deployments. |
Other pages
Questions
- Why review Yul separately from the Solidity around it?
- The compiler stops checking at the assembly brace. There is no checked math, no bounds check, and no ABI decoder. You write those checks yourself.
- Do you treat a memory-safe annotation as proof the block is safe?
- No. The annotation is a promise to the compiler. When you compile via IR, the optimizer may move stack variables into memory it believes is free. If the block writes past the 64-byte scratch space or leaves 0x60 dirty, that promise is false, and tests often miss it.
- If CALL returns success, is the transfer done?
- Not by itself. CALL succeeds against an account with no code. A token that returns false instead of reverting also looks like success unless you read the returndata. We check the flag, the code size, and the return word.
Next step
Request an audit
Share the Yul objects or the Solidity that embeds them, the compiler you ship, and your timeline. We will propose an audit plan and estimate.