Go
Go security review
Go is the language Cosmos chains are written in: the Cosmos SDK, CometBFT (the consensus engine), and IBC (how chains send packets to each other). Hackerbane audits the modules and handlers that can mint, slash, or stop the chain.
scope
What we review
We audit the Go that runs the chain: Cosmos SDK keepers, IBC handlers, CometBFT callbacks, genesis and upgrade handlers, and BeginBlocker / EndBlocker paths. Typical issues are a keeper write with no authority check, an IBC receive that credits value before checking the channel, and a BeginBlocker panic that takes every validator down.
Keeper methods that change balances, supply, or stake without an authority or signer check.
Bank and staking invariants the module assumes, such as supply conservation and slash accounting, but does not test.
BeginBlocker and EndBlocker paths that panic, loop, or drain value with no transaction in the mempool.
IBC receive handlers that credit value before checking the source channel and the packet commitment.
Genesis and upgrade handlers that load or migrate state the live keepers would reject.
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 Go review follows the same five-stage engagement as every Hackerbane audit. We start with the modules and the commit, then read keepers, IBC handlers, and CometBFT callbacks against the bank and staking rules the chain is supposed to enforce.
Two senior engineers read the module and the binary in parallel. We walk each state write back to the signer that allowed it, follow each packet from receive to commitment, and run simulation and fuzzing through BeginBlocker, EndBlocker, and genesis. Those paths run with no user transaction.
Scope and threat model
We lock the module, the commit, the networks and channels, the genesis and upgrade path, and the keys the daemon and relayer hold, before the review starts.
Architecture and design review
We read the keeper, IBC handlers, and blocker logic against that model. We look for design bugs a line-by-line pass would miss, including the order BeginBlocker and EndBlocker impose.
Hybrid code and infrastructure review
Two senior engineers read the Go in parallel, backed by static analysis, custom detectors, simulation runs, and fuzzing over the message and packet handlers.
Exploitability and root-cause analysis
High and Critical findings ship with a proof of concept against a test chain and the root cause, so the class of bug gets fixed rather than one instance, whether it lives in the module or the daemon.
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 with your Go toolchain. We add table-driven tests, simulation runs, and fuzz harnesses over the message, packet, and blocker 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, reproduced against a test chain.
A report you can share with partners, validators, investors, and regulators.
Remediation verification and a final report that reflects the fixed state of the module and binary.
The simulation and fuzz harnesses used during the review.
How to prepare
| # | Before review starts |
|---|---|
| 01 | Builds and tests run cleanly from a fresh checkout with your Go toolchain. |
| 02 | The module's keepers, message routes, and authorities are documented. |
| 03 | Bank, staking, and other invariants the chain relies on are written down. |
| 04 | BeginBlocker, EndBlocker, genesis, and upgrade behaviour are documented, including what is allowed to panic. |
| 05 | Scope is defined: which modules, which commit, and which networks. |
Other pages
Questions
- Do you review the module and the chain binary together?
- Yes. A Cosmos review covers the keeper, the genesis and upgrade handlers, and the CometBFT callbacks in the binary. A change in one module can break bank or staking in another, so we read the binary they ship.
- How do you treat IBC in scope?
- As an untrusted boundary. A receive handler has to check the source channel and the commitment before it credits anything. Arrival is not proof.
- Are genesis and upgrades in scope?
- Yes. InitGenesis and upgrade handlers write the state the keepers will live with. We check they reject the same garbage a live message would, and that an export and import still keep bank and staking invariants.
Next step
Request an audit
Share the module or chain binary repo, the networks and IBC channels it talks to, and your timeline. We will propose an audit plan and estimate.