Including the findings that are still open. The scope is pinned to commit hashes, so anyone can compile the same source the auditors read rather than take our word for what it said.
Six smart contracts audited by SolidProof across two rounds. HCOWClaim, deployed later, is not one of them. Team KYC completed with SolidProof at Tier Gold.
Read both reports in fullAn audit is only as meaningful as the code it covered. A link to a branch is not that, because a branch moves. These are the exact revisions that were reviewed.
| Repository | Audited commit |
|---|---|
| hcow-protocol | 8ff1a66b577f89ba4c01ddd7c162d12abada8825 |
| hcow-contracts | 17688d1c123d845c710561a2cef3beb9a98be69b |
Solidity 0.8.34, optimizer on at 200 runs, evmVersion paris, OpenZeppelin 5.0.2. Non-upgradeable: no proxy, no upgrade path, and no administrator able to change deployed logic. The same three settings appear in every build file in both repositories, because they are part of the source verification input and a mismatch fails verification silently.
| Measure | Result |
|---|---|
| Test assertions | 694 across six suites |
| Mutation tests | 49 of 49 caught |
| Static analysis, Slither | 105 results triaged, no High severity |
| Property-based fuzzing | Foundry invariants, plus a Medusa campaign of roughly 600,000 calls with zero failures |
Mutation testing is the least common of these and the most revealing. Each protective check in the contracts is deleted in turn and the suite is run again, on the principle that a suite which still passes with a guard removed was never testing that guard. Two assertions in our own repository were found to be passing for the wrong reason that way, and were rewritten.
The record layer establishes that a result was not altered after it was anchored. It does not establish that the set of anchored records is complete, and it says nothing at all about how a player played.
We hold no gaming licence and no laboratory certification, and we do not claim either.
An audit is a review of code at a point in time. It is not a guarantee.
CoinGecko's 2026 State of Crypto Security Report found that roughly 60% of the platforms exploited between January 2025 and July 2026 had already completed an independent security audit, and that only about 11% of those incidents involved a flaw inside conventional audit scope. An audit badge tells a reader that a review happened. It does not tell them what was reviewed, what was found, or what is still open. Publishing the reports rather than a badge is the part of that we can control.
| Contract | Address (BNB Chain mainnet) |
|---|---|
| HCOWToken | 0x794b4a94782302b9fA2636CE12D1FE5AD7026f2D |
| HCOWVesting | 0xc65710D96192893Eff4Dde05499FC4dCdF9364A5 |
| HCOWClaim | 0x63a873386D141E08407Bd041171dD6a433f1DA7f |
HCOWToken and HCOWVesting were compiled from source files identical to the audited commit, and all three are source-verified on BscScan. The vesting contract was sealed on 28 September 2026 holding the full 200,000,000 HCOW. TGE is 30 September 2026, 12:00 UTC.
HCOWClaim distributes the Community / Airdrop allocation. It was written after the audit and has not been externally audited. Its source is published in hcow-contracts and verified on BscScan.
The contracts below were deployed from the audited commit, with all six privileged roles held by separate addresses. These are testnet contracts and the tokens they use have no value. Profit Share and Staking are planned for mainnet after TGE. HCOW has not been listed on any exchange.
| Contract | Address (BNB Chain testnet) |
|---|---|
| HCOWLedger | 0xF62d0322dDf5f2913ed1751d0104d9f0D3B3EC19 |
| HCOWProfitShare | 0x795177074654B0Bb4b2B5A4405B6069e79D01f73 |
| HCOWStaking | 0x01C2d87eD3047eB02BD968c1eb8e6B5055bb6345 |
Roles are separated because a single wallet holding all of them makes every economic control in the system meaningless. The deployment script refuses to run on mainnet if any two of them are the same address, and that separation is verified on chain rather than asserted: the ledger refuses an anchor from a non-anchorer, the profit share refuses a settlement from a non-settler, and the staking registry refuses a registration from a non-owner.
HCOW has a fixed supply of 200,000,000 with no mint function, no minter role and no owner. The vesting contract commits four values in its constructor before any schedule is loaded: the number of beneficiaries, the total scheduled, the total that unlocks at TGE, and a hash chaining every row of the allocation table field by field. Those four are immutable.
Sealing checks the loaded table against all four and refuses if it does not reproduce them exactly. After the seal, nobody has any power over the contract — ownership cannot be transferred, the table cannot be edited, the TGE time cannot be moved, and there is no sweep function. Funding and sealing happen in one atomic transaction, so a failing seal unwinds the transfer and nothing moves.
On mainnet the sequence completed on 28 September 2026: 200,000,000 loaded across nine schedules, sealed, and the TGE unlock verified on chain at exactly 27,000,000, which is the figure our published allocation states. Seal transaction: 0x0b7d7b5c183c70a1f7ed345dc896f71ce1be8064fb1067a81345b0308644abb1