PI Network (PI) security report
Radar AI scanned the verified PI Network contract on BNB Smart Chain. Findings include trapped native BNB, hidden airdrop transfers, privileged fee exemptions, and USDT fee-swap accounting risk.
The contract is not free of material business-logic and control risks. The most concrete issues are permanent native-coin custody without a withdrawal path and extra pseudo-random recipient transfers during buys and sells. Owner-controlled fee exemptions also create preferential transfer treatment.
Trust score: 45/100. Source verified: Yes. Chain: bsc. Contract: 0xca12ffac4a4ec5fcd06f2fb77c0804f99facd612.
This report was last modified on 2026-10-14 and contains 5 material findings.
medium finding: Native BNB can be permanently trapped
The contract accepts native BNB through both deposits() and receive(), but the verified source contains no function that transfers native BNB out of the contract. Any BNB sent to either entry point can therefore become irrecoverable.
Evidence: deposits() is external payable and only emits RealLogs(msg.sender, msg.value). The receive() function is also payable and empty. No withdrawal or transfer-of-ETH function exists in Token or the supplied inherited contracts.
Recommendation: Remove payable entry points if native BNB is not required, or add a narrowly controlled withdrawal mechanism with explicit accounting and recipient authorization. Treat any existing balance as potentially unrecoverable until separately verified.
medium finding: Buy and sell transfers include undisclosed pseudo-random airdrop transfers
Transfers involving swapPair perform two additional transfers from the original sender to addresses derived from block.timestamp, amount, and loop index. This reduces the sender's effective balance beyond the stated transfer amount and can cause transfers to revert when the sender lacks the extra amount.
Evidence: In _transfer(), when from == swapPair or to == swapPair, airdropNumbs is fixed at 2. For each iteration, airdropAmount = amount / 10**9 and super._transfer(from, ad, airdropAmount) is executed, followed by the final super._transfer(from, to, amount - fees). The airdrop recipients are generated with keccak256(abi.encodePacked(i, amount, block.timestamp)).
Recommendation: Remove the hidden transfers or disclose and account for them explicitly. If an airdrop is required, use a separately authorized distribution mechanism, cap its cost, and ensure the transfer accounting cannot make ordinary buys or sells unexpectedly fail.
medium finding: Owner can selectively exempt arbitrary accounts from fees
The owner can change fee-exemption status for any list of addresses. This allows privileged accounts to receive different buy or sell treatment from ordinary accounts and can materially alter the economic behavior of transfers involving the swap pair.
Evidence: setTrailblazers(address[] calldata accounts, bool flag) is public onlyOwner and sets isExcludeFromFee[accounts[i]] = flag. _transfer() skips fee calculation whenever either endpoint is excluded from fees.
Recommendation: Restrict fee exemptions to immutable operational addresses or publish and enforce a transparent allowlist policy. Emit a dedicated event for changes and consider governance or timelock control for future modifications.
medium finding: Fee processing can forward pre-existing USDT to the fund receiver
When fee swapping runs, the contract calculates fundPortion from the token contract's entire USDT balance after the swap rather than only the USDT obtained by that swap. USDT already held by the token contract can therefore be included in the amount sent to the configured fund receiver.
Evidence: _executeSwapAndLiquify() records beforeBal, performs the swap, then calculates swapped = afterBal - beforeBal. However, it sets fundPortion = afterBal - lpPortion rather than deriving the fund portion solely from swapped. It then transfers fundPortion to _cfgx.fundReceiver.
Recommendation: Calculate marketing and liquidity portions exclusively from swapped, preserve unrelated token balances, and add invariant tests covering pre-existing USDT, unsolicited transfers, and repeated swap execution.
medium finding: Trading activation is centrally controlled and buys can remain disabled
The owner alone controls the tradingEnabled flag. Before activation, non-exempt buys from the swap pair revert, creating an operational dependency on the owner and a potential transfer restriction for ordinary buyers.
Evidence: enableTrading() is external onlyOwner and sets tradingEnabled to true. In _transfer(), when from == swapPair and the endpoints are not fee-exempt, the function reverts with TDP3 if !tradingEnabled.
Recommendation: Document the activation process and state clearly whether trading is permanently intended to be owner-controlled. Consider one-time irreversible activation or a timelocked governance process if centralized activation is not required.