Audit name:
[L1] Bullbit | Bullchain-Bridge | Aug2026
Date:
Sep 28, 2026
Table of Content
Introduction
We express our gratitude to the Bullbit team for the collaborative engagement that enabled the execution of this Blockchain Protocol Security Assessment.
Bullbit is a high-performance trading protocol that connects Cosmos settlement with EVM liquidity through a validator-attested bridge.
Document | |
|---|---|
| Name | Blockchain Protocol Review and Security Analysis Report for Bullbit |
| Audited By | Tanuj Soni, Hamza Sajid |
| Approved By | Ivan Bondar |
| Website | https://bullbit.ai/→ |
| Changelog | 18/09/2026 - Preliminary Report |
| 28/09/2026 - Final Report | |
| Platform | Cosmos SDK / CometBFT |
| Language | Golang |
| Tags | Bridge, Cosmos, Vote Extensions |
| Methodology | https://docs.hacken.io/methodologies/blockchain-protocols→ |
Document
- Name
- Blockchain Protocol Review and Security Analysis Report for Bullbit
- Audited By
- Tanuj Soni, Hamza Sajid
- Approved By
- Ivan Bondar
- Website
- https://bullbit.ai/→
- Changelog
- 18/09/2026 - Preliminary Report
- 28/09/2026 - Final Report
- Platform
- Cosmos SDK / CometBFT
- Language
- Golang
- Tags
- Bridge, Cosmos, Vote Extensions
Review Scope | |
|---|---|
| Repository | https://github.com/bullbit/Bullchain-Bridge→ |
| Commit | 634bdbd→ |
| Final Commit | 80fd921→ |
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{FindingsVulnSeverityStatusTable}
Documentation quality
The repository includes a scope note, a runnable README, protobuf comments, and an architecture series.
Some operator-facing descriptions are inconsistent with the implementation.
Narrative protocol documentation is limited in this snapshot.
Upgrade, deployment, and operator-trust procedures need clearer operational documentation.
Code quality
The codebase is strongly typed and split across bridge, asset, admin, the deposit worker, and the settlement seam.
Mint, unlock, and refund live in the modules and consensus path; source-chain observation lives in the worker.
A few helpers are shared across query and message execution.
Settlement writes are generally careful. Application messages rely on handler validation rather than ValidateBasic.
Architecture quality
The design is an external-verification token bridge with a propose–attest–settle workflow.
Admission, verification, quorum, and execution are separated.
Chain and asset parameters are set through governance.
Destination-chain contracts are outside this assessment.
Test coverage
go testreports 79.4% statement coverage on the bridge keeper, 71.8% on the deposit worker, 57.5% on the asset keeper, and 43.0% on the admin keeper.Generated protobuf packages report near-zero coverage. Application and command packages did not build under coverage in this snapshot.
Keeper and worker tests cover deposit and withdrawal lifecycle, settlement rollback, and vote-extension codecs.
Gaps include multi-node consensus tests and real-node integration tests.
System Overview
Bullchain is a Cosmos appchain that credits and releases value against an EVM source chain. The source chain holds a vault and per-receiver CREATE2 forwarders. Users deposit into the vault to receive credit on L1, or withdraw from L1 for payout on the source chain.
The on-chain system is implemented by three modules. x/bridge admits deposits and withdrawals, records vote-extension decisions, and settles mint, lock-release, refund, and finalize. x/asset stores asset metadata and mint or burn behaviour. x/admin stores authority and permission grants used by bridge messages.
A permissioned submitter admits a source-chain transaction reference and an L1 receiver. Each validator runs a deposit worker that verifies the referenced transfer through the receiver-derived forwarder into the configured vault. The local decision is attached to the vote extension. Settlement requires two-thirds of voting power on identical decision bytes. PreBlock validates the signed extended commit, recomputes the decision, and mints USDC or unlocks BUBI to the stored receiver.
Withdrawals escrow bank atoms on L1. A permissioned relayer finalizes a mint-burn withdrawal by burning, or a lock-release withdrawal by retaining inventory, or rejects and refunds the sender. Expired pending withdrawals refund in BeginBlock. Validators then sign an EVM release digest. The destination vault consumes those signatures.
Each validator runs the chain binary with CometBFT, the bridge, asset, and admin modules, SDK bank, gov, and staking, the off-consensus deposit worker, and an optional in-process EVM signer. Governance writes chain and asset configuration.
Risks
Source-chain observation. Deposit security depends on validators independently verifying the configured vault transfer. External verification is an operational trust assumption, not an on-chain proof.
Confirmation policy. Finality is a per-chain parameter. Operators must choose a confirmation depth that matches the source chain’s reorg risk before funds are treated as settled.
Destination execution. L1 finalize burns or locks value. Payout on the source chain depends on the destination vault threshold and collected validator signatures. That completion path is outside this module.
Lock-release inventory. Lock-release credits wait for module liquidity. Retry is the on-chain path. Inventory and insolvency handling must be operated as a residual liquidity assumption.
Signer key handling. Release signatures use a validator-local key. Its generation, storage, permissioning, and destruction require a defined operational procedure.
Protocol upgrades. A protocol upgrade may interrupt in-flight settlement. Migration must be completed before activation if backward compatibility is not preserved.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2026-1918 | A single shared RPC endpoint can authorize an unbacked deposit | fixed | High | |
| F-2026-1917 | A process-global asset cache can cause application-hash divergence | fixed | High | |
| F-2026-1918 | Bridge signer key-file permissions are not enforced | fixed | Low | |
| F-2026-1918 | A proposer can omit a bridge settlement for its block | fixed | Low | |
| F-2026-1918 | Deposit verification is blocked by the first pending record | fixed | Low | |
| F-2026-1942 | Admin disable flags do not halt in-flight deposits or withdrawals | fixed | Low | |
| F-2026-1941 | Deposit RPC client honors process HTTP proxy environment variables | fixed | Low | |
| F-2026-1934 | Source-chain RPC URL validation accepts plaintext HTTP and secret-bearing URLs | mitigated | Low | |
| F-2026-1919 | Missing upstream Cosmos patches | fixed | Low | |
| F-2026-1918 | Expired pending deposits may keep bridge configuration locked | fixed | Low |
Appendix 1. Severity Definitions
Severity | Description |
|---|---|
Critical | Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required. |
High | High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category. |
Medium | Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively. |
Low | Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system. |
Severity
- Critical
Description
- Vulnerabilities that can lead to a complete breakdown of the blockchain network's security, privacy, integrity, or availability fall under this category. They can disrupt the consensus mechanism, enabling a malicious entity to take control of the majority of nodes or facilitate 51% attacks. In addition, issues that could lead to widespread crashing of nodes, leading to a complete breakdown or significant halt of the network, are also considered critical along with issues that can lead to a massive theft of assets. Immediate attention and mitigation are required.
Severity
- High
Description
- High severity vulnerabilities are those that do not immediately risk the complete security or integrity of the network but can cause substantial harm. These are issues that could cause the crashing of several nodes, leading to temporary disruption of the network, or could manipulate the consensus mechanism to a certain extent, but not enough to execute a 51% attack. Partial breaches of privacy, unauthorized but limited access to sensitive information, and affecting the reliable execution of smart contracts also fall under this category.
Severity
- Medium
Description
- Medium severity vulnerabilities could negatively affect the blockchain protocol but are usually not capable of causing catastrophic damage. These could include vulnerabilities that allow minor breaches of user privacy, can slow down transaction processing, or can lead to relatively small financial losses. It may be possible to exploit these vulnerabilities under specific circumstances, or they may require a high level of access to exploit effectively.
Severity
- Low
Description
- Low severity vulnerabilities are minor flaws in the blockchain protocol that might not have a direct impact on security but could cause minor inefficiencies in transaction processing or slight delays in block propagation. They might include vulnerabilities that allow attackers to cause nuisance-level disruptions or are only exploitable under extremely rare and specific conditions. These vulnerabilities should be corrected but do not represent an immediate threat to the system.
Appendix 2. Scope
The scope of the project includes the following components from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/bullbit/Bullchain-Bridge→ |
| Commit | 634bdbdb536072fdaf78f4b28f2c8ebce1dfc176 |
Scope Details
- Commit
- 634bdbdb536072fdaf78f4b28f2c8ebce1dfc176
Components in Scope
Bridge
Deposit admission, verification, vote-extension quorum, and PreBlock settlement
Withdrawal escrow, finalize, reject, expiry, and release-signature persistence
Asset and admin
Asset registry used for mint, burn, and lock-release behaviour
Authority and permission grants used by bridge messages
Worker and consensus seam
Off-consensus deposit worker and source-chain receipt verification
Vote-extension codec, settlement instruction, and in-process release signer
Application wiring
Module registration for bridge, asset, admin, and SDK bank, gov, and staking
Ante chain, genesis and export, proposal handlers, and the settlement PreBlock path
Assets in Scope
Appendix 3. Additional Valuables
Frameworks and Methodologies
This security assessment was conducted in alignment with recognised penetration testing standards, methodologies and guidelines, including the NIST SP 800-115 – Technical Guide to Information Security Testing and Assessment →, and the Penetration Testing Execution Standard (PTES) →, These assets provide a structured foundation for planning, executing, and documenting technical evaluations such as vulnerability assessments, exploitation activities, and security code reviews. Hacken’s internal penetration testing methodology extends these principles to Web2 and Web3 environments to ensure consistency, repeatability, and verifiable outcomes.