bactory (bactory) security report
Radar by SecureChain AI scanned bactory on Base. The verified source review found a one-time external blacklist gate that can block transfers and privileged asset-recovery functions. Slither was not run.
The contract has no public mint function after deployment and uses standard OpenZeppelin ERC-20 accounting, but it contains material centralized-control risks. A steward can permanently bind an external trade gate whose banned-account response can block transfers, and stewards can recover assets held by the token contract.
Trust score: 48/100. Source verified: Yes. Chain: base. Contract: 0x1695e53a7fdd30648e1bc3186342a55644076cd4.
This report was last modified on 2026-10-07 and contains 2 material findings.
high finding: Privileged and irreversible trade gate can block token transfers
The owner or immutable feeRecipient can bind a trade gate exactly once. After binding, every non-mint transfer checks the external gate for both the sender and recipient; a banned response reverts the transfer. Because the gate cannot be replaced or removed, a gate administrator or gate failure can create a transfer restriction or complete token lock.
Evidence: BactoryToken.bindTradeGate is external onlySteward and rejects a second binding with GateLocked. BactoryToken._update calls ITradeGate(gate).banned(from) and ITradeGate(gate).banned(to) for every transfer where from is not the zero address, reverting with BlockedAccount when either result is true. Stewardship.isSteward grants authority to owner() and the immutable feeRecipient.
Recommendation: Publish and review the complete trade-gate implementation and its administrator controls before binding. Use a governed, auditable gate with explicit failure behavior, bounded blocking powers, and an emergency recovery or unbind mechanism if the intended design permits it. Treat the immutable one-time binding as a major deployment trust assumption.
medium finding: Stewards can withdraw ETH and arbitrary ERC-20 tokens held by the contract
The owner and feeRecipient have direct authority to transfer ETH and any ERC-20 balance held by the token contract to an arbitrary nonzero address. This is a privileged asset-recovery capability and can affect funds accidentally or intentionally sent to the contract.
Evidence: Stewardship.recoverEther(address to, uint256 amount) is external onlySteward and performs to.call{value: amount}(). Stewardship.recoverToken(address asset, address to, uint256 amount) is external onlySteward and calls IERC20(asset).safeTransfer(to, amount). isSteward returns true for owner() or the immutable feeRecipient.
Recommendation: Document this authority as custodial recovery functionality, restrict it to narrowly defined rescue assets where practical, emit dedicated recovery events, and use multisignature or timelocked governance for steward accounts. Do not send user funds to the token contract unless this authority is accepted.