Español 
Deutsch 
Русский HazeCrypto, protocol
13 March 2026. One high-severity finding, on the ROI model itself.
Open the reportCheck it yourself. Here are the addresses.
Every claim below can be confirmed on BscScan without an account and without trusting anyone. The operator links some of these addresses in passing; here they are in one place, each with the check to run and what that check does not prove.
The short version
- Four addresses matter: the protocol contract, the token, the burn address and the liquidity pool.
- The protocol contract is verified and ownership has been renounced, and both are readable on BscScan without an account.
- The burn address holds what the buybacks sent it, so the burn claim is checkable transaction by transaction.
- The pool is a public PancakeSwap V3 pair, so its balance is the liquidity of everyone in that pair, not the protocol’s own position.
- claimRewards is a public write function, so the available balance (and the principal once a term ends) can be claimed from BscScan with the web app offline.
- What none of it proves: that the advertised rate can be funded. No contract exposes that figure.
Four checks
- 01
The protocol contract is verified and renounced
Open the address, go to the Contract tab and confirm the source is marked verified. Then open Read Contract and call owner(). A return value of 0x0000000000000000000000000000000000000000 means ownership is renounced: the rules cannot be changed by anyone, including the team.
0xc90E5785632dAaB9Cb61F5050dA393090541A76DOpen on BscScan - 02
The token supply is what is claimed
Open the token contract and read totalSupply. On 30 September 2026 it returned 1,261,128 TURBO, not a round million, so read the live figure rather than trusting a quoted one. The same page shows the holder count and every transfer since deployment.
0x64920e7f4f270f302e8b728f69b5a9fc24fda2d3Open on BscScan - 03
The burns actually happened
The operator states 10% of admin fees buy $TURBO daily and send it to the burn address. Open the burn address and look at its $TURBO balance and incoming transfers, that balance is tokens permanently out of circulation. The buyback contract that performs it is public too.
0x000000000000000000000000000000000000dEaDOpen on BscScan - 04
The liquidity pool holds what it should
Deposits are stated to go into a USDC/USDT pool. The address is a public PancakeSwap V3 pair, so its USDT and USDC balances are the liquidity of everyone in that pair, not the protocol’s own position. Read them for the size of the pair, and do not read them as a figure for how much TurboLoop has locked. The balance does not show that.
0x4f31fa980a675570939b737ebdde0471a4be40ebOpen on BscScan
The audits
Three reports, all public. Read them rather than the badge. The protocol audit carries a high-severity finding that the badge does not show.
HazeCrypto, token
10 June 2026. Covers the $TURBO contract and the buyback contract.
Open the reportSolidityScan, protocol
99.99 / 100, 0 critical, 0 high, 0 medium, 0 low
Open the reportRead your own figures without the dashboard
Read Contract needs no wallet and no account: you type an address and get the answer the dashboard would have shown you. Useful when the front end is down, and useful for checking what it shows when it is up.
| Function | What it returns |
|---|---|
| getAvailableRewards(address) | What is claimable right now for that address. |
| getDepositCount(address) | How many positions the address has opened. Up to 400 are allowed. |
| getDepositInfo(address, index) | One position: amount, start time, plan, whether it is already settled. |
| getUserInfo(address) | Username, referrer, registration flag and the running totals. |
| getUserTeamInfo(address) | Team volume and counts, and the current rank index. |
| getLevelEarnings(address) | Twenty numbers: commission earned on each referral level. |
| getLevelDownlines(address) | Twenty numbers: how many people sit on each level. |
| getDailyRewardStatus() | The current day number and how far its processing has got. |
The write side is just as open: claimRewards pays out the available balance to whoever owns the address, with no front end involved. That is the part worth knowing before you need it.
The constants, as declared in the source
These are not settings. They are declared constant in the verified source, so no transaction changes them, and there is no function that could.
| Constant | Value |
|---|---|
| MINIMUM_DEPOSIT | 1 USDT |
| MINIMUM_WITHDRAW | 1 USDT |
| MINIMUM_COMPOUND | 1 USDT |
| REFERRAL_QUALIFICATION | 25 USDT |
| SERVICE_FEE_PCT | 600 / 10000 = 6% |
| MAX_POSITIONS | 400 |
| REFERRAL_DEPTH | 20 |
| MAX_UPLINE_DEPTH | 100 |
| MAX_LEADERSHIP_PCT | 1000 / 10000 = 10% |
| TIME_STEP | 86,400 seconds |
Percentages divide by PERCENTS_DIVIDER = 10000, so SERVICE_FEE_PCT = 600 is 6%. launchDate() returns 10 March 2026, 13:00 UTC, which is where the day counter starts. Read from the source on 6 October 2026.
Where the fees go
Both fees have one destination, and it is a constant address.
The source takes 6% on deposit and 6% on ROI and sends both to SERVICE_FEE_WALLET, a constant address that cannot be reassigned. Both are withdrawn from the liquidity pool rather than deducted from you: the deposit is recorded at the full amount and the ROI is credited in full. The balance of that wallet is the public record of what the fees have collected, and of what left the pool alongside the payouts.
0xC8D2701882A9A629e9a9332950Fef78EE4FFD9A9 Open on BscScan The $100,000 bounty, and what it is evidence of
The operator offers six figures to anyone who can show the team is able to harm holders. Taken at face value it is a strong signal: a team expecting to be caught does not advertise a prize for catching it. Here are the stated terms, then the parts that are not covered by them.
The stated terms
- $100,000 in USDT for a verified finding, paid to a wallet of your choice within seven days.
- Scope is the deployed contract: a centralisation risk, a vulnerability or a rug-pull mechanism.
- Open to anyone, anywhere. No NDA and no qualification check.
- Submission is a written report plus a proof of concept, sent through @TurboLoop_Official.
- Several findings are paid separately, with no cap stated and no negotiation down.
What you can establish without taking anyone’s word
- The scope is small enough to read in an evening. The contract’s ABI, the published list of calls it accepts, holds seven functions that change anything, six of them the depositor’s own, and owner() returns the zero address.
- That is also why the bounty is cheap to offer: with no pause, no fee setter and no owner withdrawal in the code, the obvious categories are already closed.
- The terms describe control and code. The finding already on record, the auditor’s high-severity note that dividends come from other users’ deposits, is about the economics instead, so it sits outside that wording.
- Nothing about the award is on chain: no escrow address, no rules page, no record of a payout made. Verification is the operator’s own judgement, and the arbitration channel is a Telegram account.
Read it as what it is: evidence that the contract has no admin levers, which that list already shows. It is not evidence that the advertised rate can be funded, and that is the question the audit raised.
What these checks do not prove
This is the part almost nobody publishes, so it is worth stating plainly. Passing every check above still leaves these open.
- An audit reduces the chance of known vulnerability classes. It does not prove the code is free of errors, and it does not review whether the economics can sustain the promised rate.
- Renounced ownership cuts both ways. Nobody can change the rules, which also means nobody can patch a flaw or pause the contract if something goes wrong.
- A verified contract tells you what the code does, not whether the payout rate is sustainable. The rate is a parameter; where the money to pay it comes from is not something the chain can confirm.
- Pool balances are a snapshot. They show what is there now, not what will be there when your term ends.