RealmTaxableTokenUniV4 $KATO

Risks (12)

• HighLaunch sniped: 1 wallets took 90% of supply in 10 secondssnipersDeterministic

  The launch was captured: 1 wallets bought 90% of the supply within 10 seconds. A small, fast group set the early price and could sell into everyone who bought later — bad for launch fairness and a strong insider/bot signal. They now hold 0% of supply, so current dump pressure from them is low — most of it was already sold, i.e. they exited on later buyers.

  Evidence

  • on-chainsnipers: windowBlocks=100, wallets=1, pctSupplyBought=90, pctSupplyHeldNow=0
  • on-chainsnipers.wallets [0x9bcabbf75b6cb66eaa15ab0caa0bcb48a150385e], pctSupplyBought 90, pctSupplyHeldNow 0
  • on-chainInitial supply minted to contract 0xd1af35970a304d3529c16997c1f2e21ca341d621 (90% — bonding curve / launchpad / vault)
  • on-chainhasSniperProt = false; bundles = []

  Confirmed by: facts, claude-opus-5.5

• MediumContract is upgradeableproxy-upgradeDeterministic

  The contract logic can be replaced by its proxy admin (admin type unknown).

  Evidence

  • on-chainminimal proxy; implementation 0x92f714819987c945A78d1D4030839C6e57c3F29d; admin unknown

  Confirmed by: facts

• MediumTokenFactory can change feesfeesDeterministic

  registerFees((address,uint256,bool)[]) (tokenFactory): Restricted state-changing function (custom — review). Fees can be raised after people buy, turning sells into a loss or a de-facto honeypot.

  Evidence

  • codeRealmToken.sol:L342
    Show source

    function registerFees(IRealmFactory.FeeShare[] calldata feeShares) external {

  • staticprivilege registerFees((address,uint256,bool)[]) restricted to tokenFactory
    Show source

    Restricted state-changing function (custom — review)

  Confirmed by: facts

• MediumSelling not simulated; core swap-hook tax code not reviewedhoneypotAI

  The fork buy/sell simulation was skipped, and slither did not run, so nothing here proves that selling works. The swap tax is applied in RealmSwapHook, but only its thin RealmHook wrapper was provided (it emits an event and calls the parent). The hook's address bits give it beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. Those let it take part of every swap amount, and in principle revert swaps. The facts list its fee router and treasury as immutable, and no admin setter is shown. Still, how sells are taxed cannot be confirmed from code, and neither can whether they can be blocked.

  Evidence

  • on-chainRealmHook 0xAE4c0Cf7C3Feb79e0c244EdBC6A3f8a3290940cC hook permissions (from address bits) = beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta
  • codeRealmHook.sol:L60-L74
    Show source

    function _afterSwap(
            address sender,
            PoolKey calldata key,
            SwapParams calldata params,
            BalanceDelta delta,
            bytes calldata hookData
        ) internal override returns (bytes4, int128) {
            PoolId id = key.toId();
            (uint160 sqrtPriceX96,,,) = poolManager.getSlot0(id);
            emit RealmPoolState(
                Currency.unwrap(key.currency1), PoolId.unwrap(id), sqrtPriceX96, poolManager.getLiquidity(id)
            );
    
            return super._afterSwap(sender, key, params, delta, hookData);
        }

  Confirmed by: claude-opus-5.5

• MediumMain pool liquidity held by a contract not confirmed as a lockerliquidityAI

  The main v4 pool (about $70k liquidity) has 100% of its position liquidity held by contract 0x7749…c016. The facts report 0% LP locked or burned. The token code says protocol positions are owned by the graduator's RealmLpLocker as permanent depth. However, the material does not confirm that 0x77493d... is that locker, and the locker's source was not provided. If this contract can withdraw the position, the pool could be drained.

  Evidence

  • on-chainuniswap-v4 0x938a519053…: v4 position liquidity other holders: 0x77493d5efc88817a252a1a17acd48951af0ec016 [contract — possibly a locker/launchpad] 100%
  • on-chainpool 0x938a519053b4973805900331d87e37cee412d418a5722295e6c091c63ad0b7e1 liquidityUsd 70465, lpBurnedPct 0, lpLockedPct 0
  • codeRealmTaxableTokenUniV4.sol:L115-L123
    Show source

    /// @notice Deposits `quote`'s accrued liquidity buffer as a single-sided position just below the
        ///         current price on that quote's pool — a protective bid wall. Placed through the venue's
        ///         `RealmLpLocker` (`graduator.LP_LOCKER()`), which owns the position — permanent pool depth
        ///         whose native fees it collects for the 30/70 split — and places it in the fixed grid range
        ///         just below the price, topping up the wall already there or minting it.
        ///         Keeper-gated and off the swap hot path, mirroring `processBurn`. Spends at most
        ///         `_maxSpend` of the buffer, once per block per quote: the target range follows the LIVE
        ///         tick, so a manipulator could pump the price across a range boundary and dump into a wall
        ///         placed at the inflated level — the cap and cooldown bound that per block (each needs a fresh, fee-paying pump).

  Confirmed by: claude-opus-5.5

• MediumProtocol owner can upgrade the fee router holding KATO feesproxy-upgradeAI

  SwapLpFeeRouter (0x823c…A957) is a UUPS proxy. Its owner, 0x8de6…B078, can upgrade it to any code with no timelock. The router receives the pool's LP fees and holds token-side fees, including KATO, in pendingTokenFees until a keeper converts or burns them. A malicious upgrade could redirect the creator and treasury fee streams, or dump the parked KATO into the pool. The same owner can also upgrade RealmSwapper and RealmTreasuryRouter. Code comments call the owner a cold multisig, but that is not verified.

  Evidence

  • codeSwapLpFeeRouter.sol:L121-L122
    Show source

    /// @dev UUPS upgrade gate: only the owner can swap the implementation.
        function _authorizeUpgrade(address) internal override onlyOwner {}

  • codeSwapLpFeeRouter.sol:L205-L209
    Show source

    function depositTokenFees(address token, address quote, uint256 amount) external {
            uint256 balanceBefore = IERC20(token).balanceOf(address(this));
            IERC20(token).safeTransferFrom(msg.sender, address(this), amount);
            pendingTokenFees[token][quote] += IERC20(token).balanceOf(address(this)) - balanceBefore;
        }

  • on-chainSwapLpFeeRouter owner = 0x8de64782f04F8528E3C88094F9a6AFc8B741B078
  • codeRealmSwapper.sol:L644
    Show source

    function _authorizeUpgrade(address) internal override onlyOwner {}

  Confirmed by: claude-opus-5.5

• MediumFake $KATO contract was promoted before the real launchsocialAI

  About an hour before @katofund posted the live contract, another account posted a different address as the $KATO CA on Robinhood Chain. A later reply labeled that address a "Rug CA" and said it used the same pad, tax, and funding method. This investigation did not verify that the other contract rugged. Anyone buying from ticker-only posts can send money to the wrong token. The address in the official bio and launch post matches the contract under review.

  Evidence

  • Xhttps://x.com/bitecong/status/2117665828036653309
    Show source

    🤖 AI Signal (RBH) $KATO
    
    CA: 0xea53d70ffab87b0114ab73c49ca64cb7e74156ef

  • Xhttps://x.com/Kr4yne/status/2117683084493766928
    Show source

    @katofund 0xea53d70ffab87b0114ab73c49ca64cb7e74156ef  
    Rug CA  
    
    0x262c134f2c375dce3d028dd4ef232ee30bd1936b
    Real CA
    
    Same pad, same tax, same funding method, 1 hour before the real launch

  • Xhttps://x.com/katofund/status/2117680457156632647
    Show source

    $KATO is live on Robinhood Chain.
    
    0x262c134f2c375dce3d028dd4ef232ee30bd1936b

  Confirmed by: grok-4.7

• Low4% buy/sell tax for ~10 years goes entirely to the creatorfeesAI

  Every pool buy and sell pays 4% tax, taken by the Uniswap v4 hook. The tax runs for taxDurationSeconds = 315,360,000 (about 10 years). At launch it decayed from 19% down to 4% over 14,400 seconds (4 hours); that window has passed. burnBps, dividendsBps and liquidityBps are all 0. So none of the tax is used for buy-back-and-burn, holder dividends or added liquidity: it all goes to the fee handler 0xe693…f3D4 for the creator's fee receivers. Nobody can raise the tax. On top of it, the pool LP fee is 1%.

  Evidence

  • on-chainbuyTaxBps = 400 (4%), sellTaxBps = 400 (4%)
  • on-chaintaxDurationSeconds = 315360000; buyTaxDecayStartBps = 1900; taxDecayDuration = 14400; launchTimestamp = 1793729137
  • on-chainburnBps = 0, dividendsBps = 0, liquidityBps = 0; feeHandler = 0xe693579893A4E7066c2f69858694bcE9D4Fbf3D4
  • codeEarningsAllocation.sol:L117-L161
    Show source

    function _splitEarnings(address asset, uint256 amount, uint256 burnShare, uint256 liquidityShare)
            internal
            returns (uint256 fundAmount)
        {
            if (!_earningsGraduated()) {
                return amount;
            }
    
            // First point at which a token is provably past graduation AND actually earning. Modules that
            // need a one-off "the token is live now" moment hook in here rather than into `markGraduated()`,
            // which still runs mid-graduation with the graduator holding the whole supply.
            // BEFORE the zero-amount exit, not after: a token whose every bucket is peeled upstream in token
            // space reaches here with `amount == 0` on EVERY earnings routing, and that is exactly the token
            // whose dividends would otherwise never open.
            _onGraduatedEarnings();

  • on-chainpoolLpFeeBps = 100 (1%)

  Confirmed by: claude-opus-5.5

• LowUnidentified contract holds 10% of supplyholdersAI

  Contract 0x004B…dF6c holds 10% of supply. The factory supports creator vaults (up to 30% of supply), so this may be a creator vault. Its lock terms are not in the material. If it unlocks or is controlled by the creator, the 10% could be sold into the pool.

  Evidence

  • on-chaintopHolders: 0x004BdeB827f3dE05B5375475Cb354E55531edF6c pct 10 isContract true
  • on-chainRealmFactoryUniV4Direct MAX_CREATOR_VAULT_TOTAL_BPS = 3000 (30%), CREATOR_VAULT_FACTORY = 0x3B730eB37E6c947e22aC838584b72A4030595b05

  Confirmed by: claude-opus-5.5

• LowKeeper registry admin can open processing calls to anyoneotherAI

  processBurn, processLiquidity and processDividends are restricted to keepers listed in RealmKeepersRegistry. Its owner or admins can call setPermissionless(true), which lets anyone call them on every Realm token. That re-opens the sandwich attack the gate exists to prevent. For KATO this has little effect today because burn, liquidity and dividend shares are all 0, so the buffers stay empty.

  Evidence

  • codeRealmKeepersRegistry.sol:L81-L97
    Show source

    function isKeeper(address account) external view returns (bool) {
            return keepers[account] || permissionless;
        }
    
        /// @notice Allow or revoke a keeper.
        /// @dev Revocation is immediate and total — a keeper holds no funds and has nothing to unwind, so
        ///      there is no reason for this to be anything but a single write.
        function setKeeper(address account, bool allowed) external onlyAdmin {
            keepers[account] = allowed;
            emit KeeperSet(account, allowed);
        }
    
        /// @notice Open (or close again) every keeper-gated call to everyone, on every token.
        function setPermissionless(bool enabled) external onlyAdmin {
            permissionless = enabled;

  • codeKeeperGated.sol:L36-L38
    Show source

    function _requireKeeper() internal view {
            require(IRealmKeepersRegistry(REALM_KEEPERS_REGISTRY).isKeeper(msg.sender), NotAKeeper());
        }

  • on-chainburnPendingEth = 0, liquidityPendingEth = 0, permissionless = false

  Confirmed by: claude-opus-5.5

• Low'Trading for months' claim not backed by weeks-old accountsclaims-mismatchAI

  The project account reposted a claim that Kato had already been trading on its own for months. The public X accounts are only weeks old: @founderkato was created 15 Oct 2026 and @katofund on 26 Oct 2026, with the token deployed 3 Nov 2026. That does not prove the trading claim is false, but the social record does not show months of history, and no named person is attached to it.

  Evidence

  • Xhttps://x.com/katofund/status/2117682049754742986
    Show source

    RT @founderkato: Kato has been trading on its own for months.
    
    Today it gets a token.

  • webhttps://x.com/katofund

  Confirmed by: grok-4.7

• LowCopied caller posts inflated launch hypesocialAI

  At launch, an alert bot said Dexscreener promotion was paid, and two accounts posted nearly the same "called it N minutes ago" text with huge percentage gains and the contract address. That is typical paid or copied shilling. It does not by itself mean the token cannot be sold, but it inflates how much real interest the launch had.

  Evidence

  • Xhttps://x.com/dex_kolwatcher/status/2117683623814168686
    Show source

    Detect PAID DEXScreener: $KATO 👇

  • Xhttps://x.com/Tata_Solana/status/2117690435632353608
    Show source

    $KATO called it 42 minutes ago at launch and this thing ripped +17620% to $470K mcap.

  • Xhttps://x.com/kajiharu0511/status/2117685836384792752
    Show source

    $KATO called it 23 minutes ago at launch and already up +13790% with $70K volume.

  Confirmed by: grok-4.7

Positive signals (2)

• PositiveToken owner renounced and tax can only decreaseownershipAI

  owner() is the zero address, so the owner-only functions on the token (setTaxBps, rescueTokens, proposeNewOwner) cannot be called. proposedOwner is also zero, so no pending owner can step in. Even before the renounce, setTaxBps could only lower taxes (TaxBpsCanOnlyDecrease). The token is a clone of a fixed implementation (minimal proxy), so its code cannot be swapped.

  Evidence

  • on-chainowner() returns 0x0000000000000000000000000000000000000000 (renounced)
  • on-chainproposedOwner = 0x0000000000000000000000000000000000000000 (zero address)
  • on-chainproxyType = minimal, implementation 0x92f714819987c945A78d1D4030839C6e57c3F29d

  Confirmed by: claude-opus-5.5

• PositiveVerified official account posts the reviewed contractsocialAI

  @katofund is a verified account created 26 Oct 2026 (about eight days before deploy), with 102 followers and 1 following. Its bio and the site it links both point at the same contract address as this review. Engagement on the launch post (32 likes) is small but not a huge follower/engagement mismatch. The founder account is also verified but only says "Creator @katofund" and gives no legal name, so a doxx claim would be unverifiable — none was clearly made.

  Evidence

  • webhttps://x.com/katofund
  • webhttps://kato.cash/

  Confirmed by: grok-4.7

Notes (1)

• InfoScanner bot's 17% fee and insider claims not confirmed by factssocialAI

  LarpCheck, an automated scanner bot, alleged a 17% sell fee, 24% held by linked wallets, and an unconfirmed link between the coin and the fund. The facts given for this contract do not include a fee rate or linked-wallet graph, so those claims stay unverified. They also do not match the figures we do have: ownership is renounced and the top 10 holders are about 19.8%, not 24%. The team later said the tax settled at a flat 5%; that promise was not checked against code in this pass.

  Evidence

  • Xhttps://x.com/Larpcheckbot/status/2117684964309237783
    Show source

    KATO · TOTAL 28/100 · NARRATIVE: PARTLY REAL 35 · COIN: RIGGED 20 (insiders 24%)
    Small fund pilot, rigged coin: 28 linked wallets hold 24%, 17% sell fee.

  • on-chainowner() = null; ownerRenounced = true; top10Pct = 19.7816; holdersCount = 290
    Show source

    owner null, ownership renounced, top 10 about 19.8%

  • Xhttps://x.com/katofund/status/2117740016030163039
    Show source

    The $KATO tax is now a flat 5% on buys and sells, for good.

  Confirmed by: grok-4.7