HCOW Info
HCOW is a GameFi ecosystem built around one idea: games should be provably fair, and the value they create should flow back to the people who play and hold.
Team and KYC Verification
The team has securely submitted their personal information to SolidProof.io for verification.
In the event of any fraudulent activities, this information will be promptly reported to the relevant authorities to ensure accountability and compliance.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Re-audit Scope
This statement replaces the one issued on 28 August 2026 and covers the profit sharing contract as it stands at the pinned commit. The contract grew from one thousand one hundred and eleven lines to one thousand five hundred and thirty, with six hundred and ninety one lines changed. It was reviewed as new code function by function and then holistically. All fourteen findings from the first round were re-verified and three new observations are recorded, none of them a route to loss.
Contract Analysis
Participants bond HCOW into a shared pool held as shares. Each settlement period, the settler submits gross revenue, direct costs, operating costs and a deduction rate in parts per million, and the contract computes the waterfall itself: fifty percent to participants, twenty five to the game company, twenty five to the team. The deduction consumes bonded principal by transferring it to an unspendable address, which lowers the pool without touching a single user record, so every participant shrinks by the same proportion in one operation. USDT distribution uses an accumulator, so a settlement costs the same gas for one participant or ten thousand.
Five structural changes account for most of the new code. The participant floor is now a deployment argument bounded above at five percent of supply rather than a constant a thousand times smaller. Whatever the floor holds back is carried into the next period's participant pot rather than routed to the two fixed recipients. The deduction gate now tests what the epoch's own revenue credits, with any carried balance excluded. A stalled period can be closed by anyone after a ceiling, with a longer fuse before the first settlement. And all three outgoing transfers were moved to the very end of the settlement function so that no state write follows an external call.
Ownership Privileges
No administrative action can alter a settled period. There is no function that edits one. The owner can:
- Rotate the settler, in one step, deliberately, because that is the lever that removes a compromised settler key and a two step handover there would be slower than the attack it exists to stop
- Change the two fixed recipient addresses, in one step
- Nominate a successor owner, who must accept, and withdraw that nomination
Neither setter can name the settler as a recipient or a recipient as the settler, and since the first round neither can name the contract itself, which would have made every settlement self-transfer into a balance the accumulator does not account for with no way to recover it. The settler can only settle, cannot choose the split, cannot state an amount of principal to destroy, and must fund the distribution out of its own balance, so a published figure that was never funded cannot be settled.
Security Features
- The split, the operating cost cap, the per-settlement deduction rate cap, the per-window decay ceiling and the minimum interval between settlements are all enforced on chain and none is passed in
- An epoch that pays participants nothing cannot consume their principal, and the gate now measures the epoch's own contribution rather than a total that could include carried money. We confirmed that one unit of eligible stake against a ten million token arrival can no longer unlock a two percent burn, which the first round measured as happening
- Whatever the floor withholds is carried and reaches participants in a later period, and the two fixed recipients now receive exactly their own quarter in every branch. We re-derived the accounting identity algebraically and it balances exactly, with no path by which the carry can underflow
- A period left open past thirty days can be advanced by anyone, moving no money and stating no revenue figure, with a ninety day fuse before the first settlement so a stranger cannot burn epochs during a healthy launch
- A settlement bringing money in with no shares at all is refused, so the carry can never become unreachable
- Share burning on exit rounds up, which is the direction that favours the pool, so the pool price cannot drift down on every exit
- Seventeen machine-searched invariant properties now run with genuine coverage floors that fail when a campaign explores nothing, replacing a guard that asserted an unsigned value was at or above zero
Findings Summary
Both medium-severity findings are fixed and were verified by re-running the first round's proofs of concept against the new contract. The participant floor is now a real figure and is no longer disarmable, and there is now a ceiling on how long a period may stay open. Of the twelve remaining, seven are fixed, four are partially fixed with reasoning we accept, and one is open outside both repositories in the deposit interface.
We also independently reproduced the corrected decay bound the response discloses. The mechanism is that the decay window is anchored by the first deduction inside it rather than by the clock, so a settler chooses where the boundary falls and two windows can be packed back to back. Running both published schedules on chain and reading the destruction off the pool rather than computing it, we measure 5.8711 percent over any thirty days and 6.8219 percent over any thirty seven. The response's corrected figures of 5.87 and 6.82 percent are right, and both are materially above the 4.92 and 5.87 percent that had been published and withdrawn. These are ceilings the code enforces, not forecasts, and the figures to quote are these rather than the three percent per window figure.
The self-inflicted defect the response discloses in this contract is closed. A carry of nearly three hundred thousand USDT plus a settlement funded with one wei previously burned participant principal, because the gate tested the credited total and the credited total includes carried money. We reproduced the scenario against the new contract: the deduction is refused, no principal is consumed, and the carry is still released in the same epoch at a zero rate. The stated cost of that fix, that an epoch paying a large real distribution out of a carry cannot also take a deduction if its own revenue is small, is a delay rather than a loss and is the right trade.
Three new observations, all informational or optimisation. Three documentation blocks sit above the wrong declarations, so the published documentation for those functions describes parameters and return values they do not have and the function the text was written for is undocumented. Two entries in the security document still name the participant floor by a constant that no longer exists and quote the old value. And a redundant local interface remains where the equivalent one was removed from the vesting contract on the first round's advice, so the two files now differ on a point they used to share. None affects behaviour; they are recorded because this project has repeatedly and correctly treated a comment describing something that is not there as a defect in its own right, and all three ship with the verified source.
Note - This Audit report consists of a security analysis of the HCOWProfitShare smart contract. Gross revenue and the cost lines are produced off chain and no contract can audit them; what this contract makes true is that the published waterfall cannot be edited after the fact and that the money moved as stated. The honest claim is not that the revenue is proven. The separate control of the settler and the two recipient addresses is a deployment requirement that the contract can only partly enforce. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
medium Issues | 2 findings
Resolved
#1 medium Issue
Participant distribution floor is set low enough to be immaterial, and is bypassable outright
The floor intended to stop a negligible eligible pool from capturing the whole participant distribution is set at one thousand shares, which is one thousand tokens out of a two hundred million supply. A sole participant holding exactly that amount already takes the entire distribution with no manipulation of any kind, which testing confirmed. The floor is additionally bypassable down to a single unit, because it arms only while the previous settlement's share snapshot was itself below the threshold: parking a position above the threshold across one settlement and then withdrawing leaves the guard inert for the settlements that follow. The practical effect of the bypass is only to reduce the stake required from one thousand tokens to one unit, since the payout is identical either way, so this is a weak parameter rather than a route to value. Value diverted this way comes from the two fixed recipient addresses and not from any participant, because a deposit made in the same period is credited nothing regardless. The source comment claiming the floor cannot be triggered against a real pool is inaccurate, and it ships with the verified source.
Resolved
#2 medium Issue
No ceiling on how long a settlement period may stay open
The minimum interval between settlements is enforced, which correctly rate-limits a compromised settler. There is no corresponding maximum. A settler that simply stops calling the settlement function leaves the current period open indefinitely, and deposits made during that period stay excluded from distribution for as long as it remains open. Those depositors can still withdraw after the cooldown, so nothing is locked, but they earn nothing in the meantime and there is no mechanism by which anyone else can advance the period. When the settler eventually does settle, that single settlement can carry a full deduction, so a long stall is followed by a charge against deposits that waited through it without earning. This is a liveness dependency on a single key that the contract does not bound anywhere.
low Issues | 6 findings
Resolved
#1 low Issue
Rule 6 threshold is a weak proxy, so a dust position can enable a deduction that would otherwise be refused
When no shares are eligible the contract forces the deduction amount to zero, on the reasoning that there is nobody to charge it against. A single unit of eligible stake removes that condition, and because the holder of that unit is then the only eligible party it receives the whole participant distribution, which clears the flat one USDT minimum by a wide margin. The deduction then proceeds against the whole bonded pool, including deposits made during the open period that are excluded from the distribution by design. Measured directly: with no such position present a settlement at the maximum rate destroyed nothing, and with one unit present the identical settlement destroyed two percent of a one million token deposit while crediting it nothing. Peer review correctly narrowed this from our initial assessment on two grounds. The holder of the dust cannot cause the burn, because only the settler can settle and only the settler chooses the rate, so this is not an attack that anyone can mount unilaterally. And that a new deposit absorbs the next deduction while earning nothing is a documented and accepted design property, recorded separately in this file. What remains is narrower but still real: the eligible pool being genuinely empty is the one case the contract singles out for protection, and a position too small to be a meaningful participant is enough to remove that protection, because the gate tests an absolute USDT figure rather than a proportion of the pool.
Pending
#2 low Issue
Ownership transfer completes in a single step
transferOwnership writes the new owner immediately with no confirmation from the incoming address. A mistyped or unreachable address ends control of the contract permanently, and with it the ability to rotate the settler or change the two fixed recipients. The same pattern applies to setSettler and setRecipients, both of which take effect in the transaction that calls them. The project documents this as a deliberate choice on the grounds that every round of added code produced a new finding, which is a fair argument, but the consequence should be recorded because it is not recoverable.
Resolved
#3 low Issue
Published lifetime deduction can drift above the actual burn
The deduction bookmark is rounded up so that the sum of every account's reported lifetime deduction cannot fall below the burn that actually happened. That direction is deliberate and correct. The related property that checks this allows one wei of slack per account, and independent testing confirmed that reverting the rounding to floor does not cause any suite in either repository to fail. The published figure can therefore drift from the real burn without anything noticing, which matters because the project treats the reconciliation as a guarantee.
Resolved
#4 low Issue
Floor penalises an honest small pool by routing part of its distribution to the fixed recipients
While the floor is armed it scales the participant distribution down by the ratio of the eligible pool to the floor, and routes the remainder to the game company and the team. That is the intended mechanism, but it applies to an entirely honest small pool as readily as to a manipulated one. Testing measured a sole honest participant holding nine hundred and ninety nine tokens receiving five hundred less than the full distribution, with the difference going to the two fixed recipients. During a genuine launch window, when the pool is small for ordinary reasons, early participants are therefore charged for the guard's existence. The amounts are small at the current floor setting but the direction is worth correcting, since raising the floor as recommended elsewhere in this report would increase them proportionally.
Resolved
#5 low Issue
Policy properties in the machine-searched suite observe nothing on a meaningful share of runs
Four of the six policy properties in the machine-searched invariant suite only ever observe their subject inside the handler's policy check, and that check runs solely on the success branch of a settlement attempt wrapped in a catch-all exception handler. Measured across thirty two seeded runs at the configured depth, four runs produced no successful settlement at all, and a typical run produced one. On those runs the four properties pass having examined nothing. The guard written specifically to make that visible asserts that an unsigned counter is greater than or equal to zero, which is true for every possible value including zero, and it prints nothing. The accounting properties are unaffected and remain sound; it is the policy layer that is thin. Peer review rightly notes that a complete campaign of two hundred and fifty six runs is not vacuous overall, and our own mutation testing confirms that every economic guard the project identified is still caught, so this is a quality-assurance gap rather than a hole that lets a defect through. The tautological guard remains a real defect, because it was written specifically to make a vacuous run visible and it cannot fail.
Resolved
#6 low Issue
Separation between settler and payout recipients is not covered by any test
The constructor and both administrative setters refuse to let the settler address equal the game company or the team address. This is the only part of the settler trust model the contract can enforce on its own, and the security documentation leans on it. Independent mutation testing removed the check entirely and every suite in the repository still passed, including the machine-searched invariants and both sets of hand-written property tests. The guard is therefore unprotected against accidental removal during future work.
optimization Issues | 2 findings
Acknowledged
#1 optimization Issue
Settlement function has high branch complexity
The settlement function spans roughly two hundred lines with a measured branch complexity of twenty one, which is high for a function that moves money along three paths and destroys principal on a fourth. The logic is correct as far as testing and symbolic checking can establish, and the inline commentary is unusually thorough, but the density is itself a risk for future changes.
Pending
#2 optimization Issue
Redundant local supply interface
The file declares a local interface for the total supply function and uses it once, in the constructor, to compute the upper bound on the participant floor. The OpenZeppelin token interface is already imported in the same file and declares the same function, so the local declaration is redundant and costs deployment bytecode. The identical item was raised against the vesting contract in the first round and was fixed there, which is what makes this worth recording: the two files were consistent before and are not now.
informational Issues | 7 findings
Resolved
#1 informational Issue
Floating compiler pragma against a pinned deployment build
The contract declares a floating pragma that accepts any compiler from 0.8.26 upward, while the main build configuration compiles with 0.8.34 and the secondary build profile pointed at an unversioned compiler binary path. The handover described the codebase as using a single version, but three are in play across the two repositories. A floating pragma means the audited source can be compiled to different bytecode by different people.
Pending
#2 informational Issue
Read-only reentrancy surface for external integrators
Every value-moving entry point carries a reentrancy guard, and the balance-delta measurement around each transfer is a deliberate defence against tokens that take a fee rather than a weakness. The residual point is that the view functions carry no guard, so a token with transfer hooks could allow an external integrator to observe intermediate accounting during a bond or a settlement. This is not reachable with the intended fixed-supply token, which has no hooks, and it becomes a real consideration only if the contract is ever paired with a different asset.
Resolved
#3 informational Issue
Separate control of the settler and the two recipients is a documented assumption worth restating for holders
The security documentation measures a stolen settler key at roughly twenty eight percent of bonded principal over a year and records that the settler recovers none of the money it funds. We reproduced both figures and they are correct within the threat model they are stated under, which is a stolen key rather than a dishonest operator. The documentation also states plainly, immediately below the table, that the settler and the two recipient addresses must be separately controlled and not merely different, and that the contract can only enforce the second half of that. We confirmed by testing that where one party holds all three, half of every funded settlement returns to it, and all of it while no participant is eligible. This is therefore a restatement of a disclosed limitation rather than a new finding, and it is in any case dominated by the under-reporting of revenue that the same documentation already describes as unbounded: a dishonest operator has no need of the recipient addresses at all.
Acknowledged
#4 informational Issue
New deposits absorb the next deduction while earning nothing
Shares bonded during an open epoch are excluded from that epoch's distribution, which is the intended defence against depositing immediately before a settlement. The deduction, however, applies to all shares including the new ones. A depositor whose timing is unlucky therefore pays up to the per-settlement deduction rate on newly bonded principal and receives no distribution in return. The project discloses this as an accepted trade-off; what is missing is the figure a depositor actually faces at the moment of deposit.
Pending
#5 informational Issue
Published description of the participant distribution no longer matches the code
The project documentation states that the participant leg is scaled to the eligible share of the pool and that whatever the eligible pool could not take goes to the two fixed recipients. That describes an earlier revision. In the shipped code the divisor is the eligible share count itself, so the eligible pool takes the entire leg and the remainder is zero in ordinary operation. The described behaviour now occurs only while the launch-window floor is armed, which is the narrow case where the pool is below one thousand shares. A reader of the published material would therefore expect a different revenue split from the one the contract implements.
Pending
#6 informational Issue
Documentation comments are attached to the wrong functions
Three documentation blocks sit above the wrong declarations, so the published documentation for those functions describes code that is not there. The long block explaining the three divisors that were tried and rejected, the fate of what the floor holds back, and the change in what the two fixed recipients receive, carries parameter and return documentation for the waterfall helper but is attached to the epoch credit helper, which has neither those parameters nor those named returns; the waterfall helper itself is then undocumented. The deduction preview function carries two notice tags, the first of which describes the operating cost preview that appears later in the file and has none of its own. The stall deadline reader carries two notice tags where one would do. All three compile without complaint, so nothing catches them.
Pending
#7 informational Issue
Security documentation still describes the floor as a compiled-in constant
The floor became a deployment argument with a different name, and two entries in SECURITY.md still refer to it by the old constant name, one of them quoting the audited value of one thousand tokens as though it were the shipped figure. A comment in the profit share test suite does the same. The shipped value is a thousand times larger and is set at construction rather than compiled in, so a reader reconciling the document against the source will not find the identifier and will find the wrong figure if they take the document at face value. This is the same class of stale-documentation item the response corrected elsewhere and is recorded for the same reason.