ink!
ink! security review
ink! is the contract language for Polkadot and Substrate. Hackerbane audits the messages (the functions you call), the storage, and the admin paths that can change the contract or move funds.
scope
What we review
We audit ink! against the pallet your chain runs. pallet-contracts limits compute as weight. pallet-revive limits it as gas. Typical issues are a message that skips a caller check, storage that collides after an upgrade, a cross-contract call that re-enters before storage is written, and an admin that can set a new code hash.
Constructors that leave admin or storage unset, and messages that skip a caller check on a privileged write.
Storage keys and mappings that overlap, or that a code-hash upgrade reads as the wrong type.
Cross-contract calls that re-enter before storage is written, or that hit a callee the caller can replace.
Payable messages that mis-count transferred value, including the zero-value case.
Weight or gas limits, and storage deposits, that only hold in a unit test.
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
An ink! review follows the same five-stage engagement as every Hackerbane audit. First we name the pallet and version, then we read the constructor, every message, the storage struct, and every call into another contract.
Two senior engineers read the contract in parallel. cargo and clippy run across the crate. We write detectors for the caller and re-entry rules this contract needs, and we drive tests through payable and set_code_hash paths that only show up on the pallet.
Scope and threat model
We lock the contracts, the commit, the chain, the contracts pallet version, and who can call or upgrade, before the review starts.
Architecture and design review
We read the constructor, the message set, and the cross-contract graph against that model to find flaws a line-by-line pass would miss.
Hybrid code and infrastructure review
Two senior engineers read the ink! in parallel, backed by clippy, custom detectors, and end-to-end tests over the payable and upgrade paths.
Exploitability and root-cause analysis
High and Critical findings ship with a proof of concept on the target runtime 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 crate you already build. Your ink! tests stay. We add e2e cases over the cross-contract and upgrade paths, then hand those artifacts 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 on the target pallet.
A report you can share with partners, exchanges, investors, and regulators.
Remediation verification and a final report that reflects the fixed state of the contract.
The ink! e2e tests written during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | The crate builds and cargo test runs cleanly from a fresh checkout. |
| 02 | The chain or parachain is named, along with pallet-contracts or pallet-revive and its version. |
| 03 | Admin accounts, the code-hash owner, and cross-contract dependencies are documented. |
| 04 | Core constructor, message, and payable flows have tests, and known limits are written down. |
| 05 | Scope is defined: which contracts, which commit, and which deployment. |
Other pages
Questions
- Do you review the pallet along with the ink! code?
- We review the contract against the pallet it will run on. pallet-contracts and pallet-revive set different rules for weight or gas, storage deposits, and how upgrades work. The plan names the pallet and version. Those rules are in scope.
- How do you treat cross-contract calls?
- As untrusted. The other contract can call back before your storage is written, and the address can be one the caller chose. We check call order, transferred value, and whether that address is fixed.
- Who can change the code hash?
- Whoever can call set_code_hash replaces the contract. We read that message first: which caller is allowed, whether anyone else can reach it, and what a bad upgrade would change.
Next step
Request an audit
Share the ink! crate (the Rust package), the chain or parachain, and whether it runs pallet-contracts or pallet-revive. We will propose an audit plan and estimate.