FunC
FunC security review
FunC is the contract language for TON. Hackerbane audits FunC contracts that hold Toncoin or jettons, including how messages and storage are handled.
scope
What we review
We audit FunC contracts on TON: recv_internal, recv_external, bounce handlers, cell packing in storage, and outbound sends. Typical issues are accept_message before the signature check, a bounce treated as a normal transfer, and load_data / save_data packing fields in a different order.
recv_internal that acts on an opcode or a sender before checking either.
recv_external that calls accept_message before the signature, seqno, or valid_until check, so a junk message drains gas.
Bounced messages parsed as ordinary internals, replaying jettons or leaving total_supply too high.
Cell packing: load_data and save_data field order, and cells that overflow 1023 bits or four refs.
Storage fees and outbound send modes that leave the contract short of Toncoin, or that send more than intended.
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 FunC review follows the same five-stage engagement as every Hackerbane audit. The difference is the TON Virtual Machine (TVM): async messages, recv_internal and recv_external, bounced messages, and FunC storage you pack into cells yourself.
Two senior engineers read the contracts in parallel. We draw the message chain, assume any hop can fail, and drive recv_internal, recv_external, and the bounce path in the sandbox.
Scope and threat model
We lock the contracts, the commit, the addresses, and who may send each opcode, including mint and burn authority, before the review starts.
Architecture and design review
We review the minter and wallet design against TON async messages and bounces. Authorization that looks safe on an atomic chain can be wrong here if the second hop fails after the first has already run.
Hybrid code and infrastructure review
Two senior engineers read the FunC in parallel, backed by sandbox tests that drive each inbound message and its matching bounce.
Exploitability and root-cause analysis
High and Critical findings ship with a reproducer through the message path and the root cause, so the class of bug gets fixed, not only the instance.
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 FunC you ship and the TON toolchain around it. We build the contracts, exercise the message handlers in the sandbox, and hand those tests back with the report.
What you get
Prioritized findings your engineers can ship against, each with root cause and a recommended fix.
Reproducers for High and Critical issues, driven through recv_internal, recv_external, and bounce paths.
A report you can share with partners, exchanges, and integrators on TON.
Remediation verification and a final report that reflects the fixed contracts.
The sandbox tests used during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | The contracts build cleanly from a fresh checkout with a pinned FunC and TVM toolchain. |
| 02 | The message opcodes and who is allowed to send each one are documented, including recv_external if you use it. |
| 03 | Bounce handling and what it is meant to undo are written down. |
| 04 | Storage layout is documented: the order of fields in load_data and save_data. |
| 05 | Scope is defined: which contracts, which commit, and which TON addresses. |
Other pages
Questions
- Do you review recv_external as well as recv_internal?
- Yes. recv_external is an entry point with no sender and no value. We check that accept_message runs only after the cheap checks, so a junk external cannot drain the contract's gas.
- Why is the bounce path so important on TON?
- A bounce returns the coins after a hop fails. Skip the handler and a jetton transfer can burn tokens, or a mint can leave total_supply too high. We treat the bounce as attacker input.
- Do you check cell packing and storage fees?
- Yes. FunC packs storage by hand. A swapped field in save_data breaks the next load. We also check that the contract keeps enough Toncoin for storage fees and for the next outbound message.
Next step
Request an audit
Share the FunC sources, the TON addresses in scope, and your timeline. We will propose an audit plan and estimate.