BrettToken $BRETT

Risks (1)

• LowUnknown who controls the main liquidity or whether it is lockedliquidityAI

  At launch, addLiquidity paired the contract's token balance (85% of supply was minted to the contract) and sent the v2 LP tokens to owner(), which was the deployer at the time. Most trading now happens in other pools: a Uniswap v3 pool with about $1.38M and an Aerodrome Slipstream pool with about $618k. The facts layer could not analyse who owns those LP positions, because log scans failed and Slipstream ownership was not analysed. Whoever controls these positions could withdraw them. Their identity and any lock are unknown.

  Evidence

  • codeBrettToken.sol:L1294-L1301
    Show source

    uniswapV2Router.addLiquidityETH{value: address(this).balance}(
                address(this),
                balanceOf(address(this)),
                0,
                0,
                owner(),
                block.timestamp
            );

  • codeBrettToken.sol:L1267
    Show source

    _mint(address(this), (totalSupply / 100) * 85);

  • on-chainliquidity: uniswap-v3 0xBA3F945812a83471d709BCe9C3CA699A19FB46f7 liquidityUsd 1375751; aerodrome-slipstream 0x4e829F8A5213c42535AB84AA40BD4aDCCE9cBa02 liquidityUsd 618117
  • on-chainaerodrome-slipstream: LP position ownership not analysed for this pool type; LP analysis uniswap-v3: eth_getLogs: invalid params

  Confirmed by: claude-opus-5.5

Positive signals (4)

• PositiveOwnership renounced and no backup admin existsownershipAI

  owner() returns the zero address. Every admin function (fees, wallets, limits, swap settings, airdrop, withdrawStuckTokens, addLiquidity, enableTrading) uses the standard OpenZeppelin onlyOwner check, so no one can call them any more. No second admin path was found. The launch whitelist (_isBrett) can only be written by the internal setBrett, which is called once in the constructor. Wallet variables such as marketingWallet only receive fee ETH and give no control. The contract is not a proxy, so its code cannot be replaced.

  Evidence

  • on-chainowner() returns 0x0000000000000000000000000000000000000000 (renounced)
  • codeBrettToken.sol:L81-L83
    Show source

    function _checkOwner() internal view virtual {
            require(owner() == _msgSender(), "Ownable: caller is not the owner");
        }

  • codeBrettToken.sol:L1315-L1319
    Show source

    function setBrett(address[] memory _bretts, bool set) internal {
            for(uint256 i = 0; i < _bretts.length; i++){
                _isBrett[_bretts[i]] = set;
            }
        }

  • codeBrettToken.sol:L1269
    Show source

    setBrett(_bretts, true);

  • on-chainisProxy: false
  • on-chainowner() = null; ownerRenounced = true
    Show source

    owner:null, ownerRenounced:true, verified:true

  Confirmed by: claude-opus-5.5, grok-4.7

• Positive0% buy/sell tax confirmed; fees were capped at 3% in codefeesAI

  The live buyTotalFees and sellTotalFees are both 0. The fork simulation confirmed a 0% token tax on buy, sell and transfer. The facts layer says the fee setters have no upper bound, but that is wrong. Both setters require the total to be at most 300/10000, which is 3%. Since ownership is renounced, the setters cannot be called and fees stay at 0. The line sellTotalFees = _previousFee at the end of each transfer only restores the same stored value (0) and cannot raise the fee.

  Evidence

  • codeBrettToken.sol:L1358-L1361
    Show source

    require(
                _marketingFee + _developmentFee + _liquidityFee <= 300,
                "ERC20: Must keep fees at 3% or less"
            );

  • codeBrettToken.sol:L1373-L1376
    Show source

    require(
                _marketingFee + _developmentFee + _liquidityFee <= 300,
                "ERC20: Must keep fees at 3% or less"
            );

  • codeBrettToken.sol:L1594
    Show source

    sellTotalFees = _previousFee;

  • on-chainbuyTotalFees = 0; sellTotalFees = 0
  • forkbuyTaxPct 0, sellTaxPct 0, transferTaxPct 0; second wallet could sell; sell after +1h: ok

  Confirmed by: claude-opus-5.5

• PositiveTrading cannot be switched off and launch limits are disabledhoneypotAI

  tradingActive is true. The contract has no function that sets it back to false: enableTrading only switches trading on and refuses to run twice. limited is false, so the launch-time rules no longer apply. Those rules were a buy whitelist (_isBrett) and a max-wallet check on buys from the v2 pair. maxWallet and maxTransaction both equal 100% of supply. The simulation bought and sold successfully, including a sell from a second wallet and a sell one hour later.

  Evidence

  • codeBrettToken.sol:L1304-L1308
    Show source

    function enableTrading() public onlyOwner {
            require(!tradingActive, "Trading already active.");
            tradingActive = true;
            swapEnabled = true;
        }

  • codeBrettToken.sol:L1499-L1502
    Show source

    if (limited && from == address(uniswapV2Pair)) {  // has to be the LP 
                    require(balanceOf(to) + amount <= maxWallet, "Forbid");
                    require(_isBrett[from] || _isBrett[to], "Forbid");
                }

  • on-chaintradingActive = true; limited = false; maxWallet = 10000000000000000000000000000
  • forkcanBuy true, canSell true, inconclusive false

  Confirmed by: claude-opus-5.5

• PositiveVerified X account created just before launch, still activesocialAI

  @BasedBrett was created on 2024-02-20, four days before this contract was deployed (2024-02-24). The account is verified, has about 141k followers, and recent posts still get hundreds of likes, which does not look like a dead or freshly bought account.

  Evidence

  • Xhttps://x.com/BasedBrett/status/2116538176726827099
    Show source

    We know where to go, we know what to do.

  • on-chaindeployedAt = 2024-02-24T06:47:51.000Z
    Show source

    X profile createdAt 2024-02-20T16:34:10.000Z, verified, followers 141357, bio: $BRETT - The Leading Memecoin on Base.

  Confirmed by: grok-4.7

Notes (4)

• InfoTeam got 15% of supply at launch; current holdings unknowninsidersAI

  The constructor minted 10% of supply to the deployer and 5% to a hard-coded 'brettMultisig' wallet. That same wallet is also the marketing, development and liquidity fee wallet. The deployer now holds 0%. The multisig's current balance and the top-holder list could not be built because the transfer scan failed, so any dump risk from team or insider wallets cannot be measured.

  Evidence

  • codeBrettToken.sol:L1265-L1266
    Show source

    _mint(owner(), (totalSupply / 100) * 10); 
            _mint(brettMultisig, (totalSupply / 100) * 5);

  • codeBrettToken.sol:L1228
    Show source

    address brettMultisig = 0x9BA188E4B2C46C15450EA5Eac83A048E5E5D9444;

  • on-chainDeployer 0x46f64bec31eaf281176f9bb5899107a80e932b45 holds 0% now
  • on-chainTransfer history too large for full scan ... holder figures are approximate; topHolders: []

  Confirmed by: claude-opus-5.5

• InfoSlither 'high' alerts are not exploitable in practiceotherAI

  Slither flagged three issues. Each is harmless today: - 'arbitrary-send-eth' in _swapBack: ETH goes to the fixed marketingWallet, which only the (renounced) owner could change. - Reentrancy in _transfer: _swapBack only touches the trusted router and the fee wallets. With 0% fees it exits early because no fee tokens are tracked. - 'unchecked-transfer' in withdrawStuckTokens: the function can no longer be called. None of these give an outside attacker or an admin a way to take holder funds.

  Evidence

  • staticslither: arbitrary-send-eth BrettToken._swapBack() (BrettToken.sol#1627-1683)
  • codeBrettToken.sol:L1629-L1636
    Show source

    uint256 totalTokensToSwap = _tokensForLiquidity +
                _tokensForMarketing +
                _tokensForDevelopment;
            bool success;
    
            if (contractBalance == 0 || totalTokensToSwap == 0) {
                return;
            }

  • codeBrettToken.sol:L1441
    Show source

    function withdrawStuckTokens(address tkn) public onlyOwner {

  Confirmed by: claude-opus-5.5

• InfoDeployer's only other token, HONEY, has an unknown outcomedeployer-historyAI

  The deployer also created HONEY (0x0e82…2097). Its outcome is recorded as unknown, so this is neither a red flag nor a trust signal.

  Evidence

  • on-chaindeployerHistory: 0x0e82F2d85750218E7a6aa3f78324993FA6572097 HONEY outcome unknown
  • on-chaindeployerHistory token 0x0e82F2d85750218E7a6aa3f78324993FA6572097 symbol HONEY outcome unknown
    Show source

    deployer 0x46F64BeC31Eaf281176f9bb5899107A80e932B45; HONEY outcome unknown

  Confirmed by: claude-opus-5.5, grok-4.7

• InfoThird-party post matches renounced, zero-tax factsclaims-mismatchAI

  A listing post describes this same contract as a Feb 2024 Base memecoin with a fixed supply, zero taxes, and a renounced contract. That renounce claim matches the on-chain owner fact. Taxes and supply were not independently re-checked in this social pass.

  Evidence

  • Xhttps://x.com/PulswitchApp/status/2116359735779766535
    Show source

    $Brett is a memecoin on Base, launched in Feb. 2024 as a fan tribute to the Brett character from Matt Furie’s Boy’s Club comic (Pepe’s best friend). It has become the unofficial mascot of the Base ecosystem, with a fixed ~10 billion supply, zero taxes, and a renounced contract.

  • on-chainownerRenounced = true
    Show source

    owner:null, ownerRenounced:true

  Confirmed by: grok-4.7