Bitreum (BTE) security report
Radar AI scanned the verified Bitreum BTE contract. Source review found fixed supply, no owner mint or blacklist, and zero reported buy and sell tax. Material risks include a creator-selected external distributor that can revert transfers, delayed creator-controlled transfer limits, a short launch allowlist guard, and concentrated contract-held balances. Slither was not run.
The token is a fixed-supply ERC-20 with zero reported buy and sell tax and no verified owner control, but it is not risk-free. The deployment creator can configure an arbitrary transfer-callback distributor that may revert transfers, and the source does not enforce that one-time guard, limit, or distributor initialization occurs during the launch transaction.
Trust score: 68/100. Source verified: Yes. Chain: ethereum. Contract: 0x51dd8687ecc330e337e62acbf931dc251802ffff.
This report was last modified on 2026-09-29 and contains 4 material findings.
high finding: Creator-selected distributor can freeze all token transfers
The creator can set distributor to an arbitrary address through initDistributor. Every non-mint transfer and burn then performs an external call to distributor.onTransfer(from,to). If that contract reverts, ordinary transfers revert as well, creating a complete transfer lock. The token does not validate that the distributor is trusted or non-reverting.
Evidence: initDistributor accepts any distributor_ address and is authorized only by msg.sender == creator. _update executes IFusingDistributorSink(distributor).onTransfer(from, to) after every transfer whenever distributor != address(0). GoPlus also reports external_call=1.
Recommendation: Restrict the distributor to a verified immutable implementation or a vetted allowlist, make the callback non-blocking with failure isolation, or remove the external callback from the transfer path. Confirm that distributor initialization is permanently disabled or irrevocably fixed after launch.
medium finding: Transfer limits can be initialized outside the stated launch transaction
The source comments state that initLimits is called inside the launch transaction, but the contract only checks the caller address and a one-time boolean. It does not verify the current transaction, launch block, or initialization deadline. The creator can therefore delay initialization and later impose maxWallet and maxTx restrictions for up to 21 minutes from the delayed call.
Evidence: initLimits checks only msg.sender == creator and limitsSet == false, then sets limitsEndAt = uint64(block.timestamp) + limitsSeconds. No check requires execution during construction or the original launch transaction. MAX_LIMITS_SECONDS is 21 minutes.
Recommendation: Bind initialization to the deployment transaction or enforce a short, explicit initialization deadline. Publish the configured maxWallet, maxTx, exempt accounts, and limitsEndAt before trading begins.
medium finding: Initial launch guard depends on a creator-controlled recipient list
During the guard window, any transfer to an address not in guardAllowed reverts. The list is written by the creator through initGuardList and the source does not independently verify that the pool, routers, or intended users are included. A misconfigured or malicious list can prevent expected launch transfers for up to 60 seconds.
Evidence: _update reverts with LaunchGuardActive when block.timestamp < guardEndsAt, from != address(0), and guardAllowed[to] is false. initGuardList writes the allowlist once using only the creator authorization. guardSeconds_ may be configured up to MAX_GUARD_SECONDS of 60.
Recommendation: Validate required launch infrastructure addresses on-chain, constrain guard initialization to the deployment transaction, and provide a tested fallback path that cannot strand pool or user transfers.
medium finding: Token ownership is materially concentrated in a contract address
Supplied GoPlus evidence reports one contract address holding approximately 79.04% of total supply, with another contract holding approximately 9.995%. If these balances are not permanently inaccessible or governed by transparent mechanisms, movements by those addresses could create substantial price and distribution risk. The evidence does not identify the contracts or establish whether they are pools, lockers, or protocol-controlled wallets.
Evidence: GoPlus holders data lists 0x000000000004444c5dc75cb358380d2e3de08a90 at 790,365,012.525 tokens, or 0.7903650125 of the reported 1,000,000,000 total supply, and 0xd4392981fb0de10da7893ebbca43663af521ea96 at 99,950,000 tokens, or 0.09995.
Recommendation: Identify and verify the controlling code and purpose of the large contract-held balances, document release or withdrawal permissions, and monitor transfers from these addresses.