Anyport AI (PORT) security report
Radar by SecureChain AI reviewed Anyport AI's verified Ethereum source. Material findings include an owner-controlled transfer gate, unlimited liquidity-lock extensions, and potentially trapped ETH in the locker.
The source does not expose a public mint function, transfer tax, blacklist, proxy upgrade path, or pause function. However, the owner controls irreversible trading activation, creating a material transfer-lock risk. PortLPLocker has additional custody and operational risks involving indefinite lock extensions and potentially trapped ETH.
Trust score: 48/100. Source verified: Yes. Chain: ethereum. Contract: 0xe8a65eff72ccc149470a58f95f1390804646c21f.
This report was last modified on 2026-10-07 and contains 3 material findings.
high finding: Owner-controlled trading gate can block transfers indefinitely
The owner alone can call enableTrading(), and ordinary token transfers revert while tradingEnabled is false. If ownership is renounced before activation, no account can call enableTrading(), leaving nonzero-to-nonzero transfers permanently disabled.
Evidence: AnyportAI.enableTrading() is external onlyOwner and sets tradingEnabled to true. AnyportAI._update() reverts with TradingNotOpenYet() when tradingEnabled is false and both from and to are nonzero unless either address equals owner(). Ownable.renounceOwnership() sets owner to address(0), and enableTrading() has no alternative activation path.
Recommendation: Activate trading through a publicly verifiable process before any ownership renunciation, and publish an operational guarantee or deployment invariant preventing premature renunciation. Consider removing the gate after launch or using a time-bounded, independently verifiable activation mechanism.
medium finding: Beneficiary can extend the liquidity lock without an upper bound
The designated beneficiary can repeatedly extend the NFT unlock time to any later timestamp. This means the stated unlock schedule is not immutable and liquidity withdrawal can be delayed indefinitely by the privileged beneficiary.
Evidence: PortLPLocker.extendLock(uint256 newUnlockTime) is protected only by onlyBeneficiary and accepts any newUnlockTime greater than the current unlockTime. There is no maximum extension, governance delay, timelock, or independent approval requirement.
Recommendation: Use a fixed maximum unlock time or require a transparent multi-party or governance-controlled authorization for extensions. Publish beneficiary controls and emit monitoring alerts for LockExtended events.
medium finding: Direct native ETH sent to the locker may be permanently trapped
PortLPLocker accepts native ETH through its receive function, but exposes no function that transfers arbitrary ETH to the beneficiary or another recovery address. ETH sent directly to the contract can therefore remain inaccessible unless it is handled through a supported position-manager fee flow.
Evidence: PortLPLocker defines receive() external payable {}. The contract has no ETH withdrawal or rescue function. withdraw() transfers only the position NFT, while collectFees() invokes positionManager.modifyLiquidities() for the configured position.
Recommendation: Remove the payable receive path if direct ETH is not required, or add a narrowly scoped recovery function with explicit authorization, event logging, and safeguards for funds required by active position operations.