OAK

Risks (9)

• MediumSource code is not verifiedotherDeterministic

  The contract source is not published on the explorer, so nobody can read what it really does. The analysis relies on bytecode only.

  Evidence

  • on-chainexplorer: no verified source for 0x6511c233790Ec10f7d673c64DC82C3F941D57828

  Confirmed by: facts

• MediumSnipers bought 9.4% at launch and have sold outsnipersAI

  Two wallets bought 9.39% of supply in the first 100 blocks. They now hold 0%, so there is no remaining sniper supply overhang. No bundles were detected.

  Evidence

  • on-chainsnipers: pctSupplyBought 9.3887, pctSupplyHeldNow 0
  • on-chainbundles: []

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• MediumOne owner key controls treasury and subscription paymentswebsiteAI

  Oak's token, about, and security pages say the treasury and contract admin is a single-owner wallet with no second signature. That one key can spend treasury funds, redirect future subscription payments, replace the price signer, and retire subscriptions. It cannot spend user wallet balances, but a compromised or dishonest key can redirect subscriber payments and shut paid access. The wallet address itself is not printed in the fetched page text, so the exact key cannot be confirmed here.

  Evidence

  • webhttps://oakagentkit.org/token.html
    Show source

    One owner key can spend treasury funds, redirect future subscription payments, replace the price signer and retire subscriptions. There is no second-signature requirement.

  • webhttps://oakagentkit.org/security.html
    Show source

    It cannot spend user wallet balances. Safe support is an optional deployment profile, not the launch setup.

  Confirmed by: grok-4.7, gpt-5.6-sol

• LowFee operator sets slippage when converting fees, adding sell pressurefeesAI

  Accrued OAK-denominated fees and the buyback leg can only be converted by the trusted feeSweepOperator 0xa101…cA83. The operator chooses the minimum outputs. The code itself notes that the price-impact bound is not manipulation resistance. A careless or malicious operator could let fee conversions be sandwiched. The loss falls only on the fee pot (creator, protocol, buyback), not on holders' balances. Each conversion also sells accrued OAK fees into the pool, which adds some sell pressure.

  Evidence

  • codePonsV2MemeHook.sol:L500-L531
    Show source

    function sweepPoolFees(PoolId poolId, uint256 minConversionQuoteOut, uint256 minBuybackTokensOut)
            external
            nonReentrant
        {
            LaunchInfo memory info = launches[poolId];
            if (!info.registered) revert UnknownPool();
            bool isOperator = msg.sender == feeSweepOperator;
            if (!isOperator && msg.sender != info.creator) revert NotFeeSweepOperator();
            if (!isOperator && _requiresTrustedOperator(poolId, info)) revert InternalSwapRequiresOperator();
    
            (uint256 convertedFeeQuote, uint256 convertedTaxQuote, uint256 convertedBuybackQuote, bool converted) =
                _convertPendingMemecoin(poolId, info, minConversionQuoteOut);
            // Only a conversion that actually executed is subject to the caller's
            // minimum. Enforcing it when there was nothing to convert, or when the
            // swap filled nothing and the pending amount was restored for a later

  • codePonsV2MemeHook.sol:L757-L764
    Show source

    * That ceiling limits how far this swap moves the price, not where the
         * price started. A front-run that depresses spot first shifts the whole
         * band down with it, so the bound is slippage control rather than
         * manipulation resistance. What actually caps the loss on a sandwich is
         * the caller's `minConversionQuoteOut` / `minBuybackTokensOut`, which is
         * why every price-sensitive sweep is gated to the sweep operator by
         * `_requiresTrustedOperator`. Treat those minimums as the real defense
         * and size them off an independent price.

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• LowDeployer-linked wallets hold ~3.8%, mostly in unverified vestinginsidersAI

  The deployer-funded contract 0xbdb5…9b91 holds 2.9989%. It is referenced on the project site as OakTeamVesting and is owned by the deployer. Its source is unverified, but its functions look like a standard vesting wallet (start, cliff, duration, release). The deployer wallet itself holds another 0.7585% and has burned 0.4% of supply. The deployer has sold 0%. The vesting schedule (cliff, duration) and whether the owner can redirect it cannot be verified without source.

  Evidence

  • on-chaininsiders: wallets 0xbdb50e1ab95516d4f1cfcbb8ee704dc1e65f9b91, 0xe1f6638f3276a88557ad4e81c50bfd5aa99fc50c fundedBy 0x84b1b9e5d1cafd9543e684bb39e9cbd478189ee2 pctSupplyHeldNow 2.9989
  • on-chainlocker 0xbDB50e1aB95516D4f1CfCbB8eE704dc1e65f9b91 verified=false owner=0x84b1B9e5D1cAfD9543E684BB39E9cbD478189EE2
  • on-chainDeployer 0x84b1b9e5d1cafd9543e684bb39e9cbd478189ee2 holds 0.7585% now; deployerSoldPct=0

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• LowOne funder's 3-wallet cluster holds about 4%holdersAI

  Three wallets funded by 0xf70d…dbef together hold 3.9713%. Two of them appear in the top holders list. If this is one entity, it could sell a meaningful block. Overall concentration is moderate: the top 10 holders, excluding infrastructure, hold about 27.9%.

  Evidence

  • on-chainclusters: funder 0xf70da97812cb96acdf810712aa562db8dfa3dbef wallets 0x7df718cdeb3dddcad753101e54ee8bdda71dff20, 0x5a7a61face3c7bf578098ad80fe7e7c471b4277c, 0x30383931df912159d94694e010c8611ce6c6d95a pctSupplyHeldNow 3.9713
  • on-chaintop10Pct = 27.9467

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• LowSecond pool's liquidity is unlocked and mostly from one walletliquidityAI

  A separate Uniswap v4 pool, 0x81ce49bb1bc7d2fb9f2d508de813ce30a58eb99cfaf3f12278571f2d37bc5e99 (about $29k), is not part of the Pons launch. 0% of its LP is locked, and 82.28% of it comes from one wallet, 0x51ff…5edb. That wallet can withdraw its liquidity at any time. This would thin out trading in that pool. It does not affect the locked main pool.

  Evidence

  • on-chainliquidity pool 0x81ce49bb1bc7d2fb9f2d508de813ce30a58eb99cfaf3f12278571f2d37bc5e99: lpLockedPct=0, liquidityUsd=29007
  • on-chainuniswap-v4 0x81ce49bb1b…: v4 position liquidity holders: 0x51ffe129b0c5699829aa99b892f21658527f5edb [other: wallet (unlocked)] 82.2809%

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• LowSite and GitHub disagree on version and project countclaims-mismatchAI

  The public site tells people to install Oak 0.2.5 and claims one connection to 29 Robinhood Chain projects. The GitHub readme still describes 26 projects and says the 0.2.5 package publication is pending, so the install command on the site may not match what is actually published. This is a docs lag, not proof the token cannot be sold.

  Evidence

  • webhttps://oakagentkit.org/
    Show source

    Connect your AI assistant to 29 Robinhood Chain projects with Oak. Install Oak 0.2.5 and subscribe through Oak to use hosted actions.

  • webhttps://github.com/OakAgentKit/oak
    Show source

    One MCP for 26 projects on Robinhood Chain.

  • webhttps://github.com/OakAgentKit/oak
    Show source

    The prepared version is 0.2.5. Publication is pending; wait for the release before running the pinned install command.

  Confirmed by: grok-4.7, gpt-5.6-sol

• LowClaimed payment-funded buy-and-burn not yet seen on-chainclaims-mismatchAI

  The complete burn analysis found zero buyback burns: all six observed burns were attributed to the deployer or a holder without a pool purchase. Thus the claimed on-chain payment-funded buy-and-burn flow is absent from the observed burn history.

  Evidence

  • Xhttps://x.com/OakAgentKit/status/2117800816056918199
    Show source

    Every payment splits on chain: 25% buys robinhood:0x6511c233790ec10f7d673c64dc82c3f941d57828 and burns it, 75% goes to Oak's treasury.

  • on-chaintoken.burns.buybackBurns = 0; token.burns.complete = true
    Show source

    "buybackBurns": 0, "complete": true

  • on-chaintoken.burns.by: 0x84b1b9e5d1cafd9543e684bb39e9cbd478189ee2 deployer, pct=0.4, count=3, buyback=0; 0x5d754384a7c0503dbe1b67595aca7ebe1dad305e holder, pct=0.0028, count=3, buyback=0
    Show source

    "count": 6

  Confirmed by: gpt-5.6-sol · Disputed by: claude-opus-5.5, grok-4.7

Positive signals (6)

• PositiveOngoing token burns verified on-chain: 0.4% of supply burnedburnDeterministic

  0.4% of the supply ever minted is burned, in 6 burn transfer(s), last 2026-11-04. Burned by: the deployer 0x84b1…9ee2 (0.4%, 3 burns); holder 0x5d75…305e (0.0%, 3 burns). Burned tokens are gone for good, which reduces the supply over time.

  Evidence

  • on-chainTransfer events to 0x0 / 0x…dEaD and balanceOf(burn addresses) of 0x6511c233790ec10f7d673c64dc82c3f941d57828

  Confirmed by: facts

• PositiveBuys, sells and transfers work with 0% token taxhoneypotAI

  A real buy and sell through the graduated Uniswap v4 pool were simulated. Both went through and returned exactly the expected amounts. A second wallet that received tokens by transfer could also sell, and selling still worked one hour later. The token itself charges no tax on buy, sell or transfer. The 2% pool-level swap fee (see the separate fee finding) is already included in the quotes. There is no sign of a honeypot.

  Evidence

  • forksimulation: canBuy=true, canSell=true, buyTaxPct=0, sellTaxPct=0, transferTaxPct=0
    Show source

    second wallet (received via transfer) could sell

  • forksimulation notes
    Show source

    sell after +1h: ok

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• PositiveToken comes from the Pons template with no owner functionsotherAI

  The OAK contract source is not verified on the explorer. However, FACTS show it was created by the Pons launch deployer 0x3711…1A42. That verified contract only deploys tokens via CREATE2 using the PonsV2LauncherToken creation code and mints the whole supply to the curve. The exposed function list has no owner, mint, pause, blacklist or fee setters. burnFrom exists but appears to be the standard allowance-based burn; this cannot be confirmed without source. Inference: this is the standard Pons template with no owner powers over holder balances.

  Evidence

  • on-chainCreated by factory contract 0x3711ceA4feaDE896C913C68F01Eda97Cb06D1A42; tx sender 0x84b1B9e5D1cAfD9543E684BB39E9cbD478189EE2
  • codePonsV2LaunchDeployer.sol:L99-L109
    Show source

    function deployLaunch(LaunchDeployment calldata params)
            external
            onlyFactory
            returns (address token, address curve)
        {
            _requireMetadataWithinLimits(params);
    
            bytes32 salt = _launchSalt(params);
            curve = Create2.deploy(0, salt, _curveCreationCode(params));
            token = Create2.deploy(0, salt, _tokenCreationCode(params, curve));
        }

  • codePonsV2LaunchDeployer.sol:L166-L185
    Show source

    /**
         * @dev Creation code for the launch's token, given the curve it mints its
         * whole supply to.
         */
        function _tokenCreationCode(LaunchDeployment calldata params, address curve) private view returns (bytes memory) {
            return abi.encodePacked(
                type(PonsV2LauncherToken).creationCode,
                abi.encode(
                    params.name,
                    params.symbol,
                    params.logo,
                    params.description,
                    params.socials,
                    params.originalDeployer,
                    curve,

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• PositiveMain pool liquidity permanently locked by Pons lockerliquidityAI

  The graduated Uniswap v4 pool 0xdb324dde34ef01debe23f8f8ab4bb6053154b5dea8646dec9d8ea65e414fad59 holds about $72.5k of liquidity. All of its LP position is held by the Pons launch locker, labelled as a permanent LP lock. The deployer holds none of it. The verified locker function table shows only factory-gated lock functions and no withdraw or unlock function. The creator therefore cannot pull this liquidity.

  Evidence

  • on-chainliquidity pool 0xdb324dde34ef01debe23f8f8ab4bb6053154b5dea8646dec9d8ea65e414fad59: lpLockedPct=100, lpHeldByDeployerPct=0, liquidityUsd=72510
  • on-chainv4 position liquidity holders: 0x267444d099b10fb5ed7c3cc7b7c767adca574952 [locked: PonsV2LaunchLocker (permanent LP lock)] 100%

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• PositivePool hook cannot block sells or trap liquidityotherAI

  The hook's address bits enable only beforeInitialize, afterSwap and afterSwapReturnDelta. - beforeInitialize only checks that the factory created the pool. - afterSwap has no whitelist or direction check. Its only revert path is an inexact token transfer, which does not occur for OAK or native ETH. - No remove-liquidity callback is enabled, so the hook cannot trap liquidity providers. The returned delta is limited to the frozen fee amount.

  Evidence

  • codePonsV2MemeHook.sol:L184-L201
    Show source

    function getHookPermissions() public pure override returns (Hooks.Permissions memory) {
            return Hooks.Permissions({
                beforeInitialize: true,
                afterInitialize: false,
                beforeAddLiquidity: false,
                afterAddLiquidity: false,
                beforeRemoveLiquidity: false,
                afterRemoveLiquidity: false,
                beforeSwap: false,
                afterSwap: true,
                beforeDonate: false,
                afterDonate: false,
                beforeSwapReturnDelta: false,
                afterSwapReturnDelta: true,
                afterAddLiquidityReturnDelta: false,

  • codePonsV2MemeHook.sol:L429-L432
    Show source

    function _beforeInitialize(address sender, PoolKey calldata, uint160) internal view override returns (bytes4) {
            if (sender != factory) revert NotFactory();
            return IHooks.beforeInitialize.selector;
        }

  • codePonsV2MemeHook.sol:L845-L855
    Show source

    function _takeExact(Currency currency, address token, uint256 amount) private {
            if (currency.isAddressZero()) {
                poolManager.take(currency, address(this), amount);
                return;
            }
    
            uint256 balanceBefore = IERC20(token).balanceOf(address(this));
            poolManager.take(currency, address(this), amount);
            uint256 received = IERC20(token).balanceOf(address(this)) - balanceBefore;
            if (received != amount) revert InexactQuoteTransfer(token, amount, received);
        }

  • on-chainv4 hook 0xE5e702641Ea86F4ae6cC3cDaeD2B886f976Be044 permissions: beforeInitialize, afterSwap, afterSwapReturnsDelta

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• PositiveSite openly states no audit and no holder yieldwebsiteAI

  The security page states there is no third-party audit. The token page says holding $OAK only buys access, Oak never promises returns, and it does not pay holders from protocol fees. Those limits are stated in the project's own words.

  Evidence

  • webhttps://oakagentkit.org/security.html
    Show source

    Oak has no third-party audit. Your wallet stays on your computer; you review what it is about to do.

  • webhttps://oakagentkit.org/token.html
    Show source

    Oak never promises returns, never pays holders from protocol fees, and never distributes fee payouts or rewards to token holders.

  Confirmed by: grok-4.7, gpt-5.6-sol

Notes (5)

• LowPool charges a fixed 2% swap fee that cannot be raisedfeesAI

  The Pons hook takes a cut of every swap in the graduated pool: 1% hook fee plus 1% creator tax, charged on the unspecified side of the swap. Where the money goes: - 30% of the hook fee goes to the Pons protocol. - Part of the creator's share of the hook fee is earmarked for buyback, but only if buyback is enabled for this pool. - The rest of the hook fee and the full creator tax go to the creator via the fee escrow. These rates are copied into the pool's own record at registration. afterSwap reads only that record, not the hook's live settings. So if the Pons owner later raises hookFeeBps (cap 10%), the change only affects future launches, not OAK. The code has no function that changes creatorTaxBps or hookFeeBps for an already-registered pool. The total is also hard-capped at 20% at registration. The fee is ordinary launchpad economics and cannot be turned into a sell block.

  Evidence

  • codePonsV2MemeHook.sol:L444-L485
    Show source

    function _afterSwap(address, PoolKey calldata key, SwapParams calldata params, BalanceDelta delta, bytes calldata)
            internal
            override
            returns (bytes4, int128)
        {
            // The conversion and buyback legs swap against this same pool, but
            // they are never taxed here: v4-core skips a pool's hooks when the
            // hook itself is the caller (Hooks.afterSwap). Were that not so, the
            // skim would come out of the buyback before it reached the vault.
            PoolId poolId = key.toId();
            LaunchInfo memory info = launches[poolId];
            if (!info.registered) return (IHooks.afterSwap.selector, 0);
            if (info.hookFeeBps == 0 && info.creatorTaxBps == 0) return (IHooks.afterSwap.selector, 0);
    
            bool specifiedIsCurrency0 = (params.amountSpecified < 0) == params.zeroForOne;

  • codePonsV2MemeHook.sol:L364-L378
    Show source

    launches[poolId] = LaunchInfo({
                registered: true,
                memecoinIsCurrency0: memecoinIsCurrency0,
                memecoin: memecoin,
                quoteToken: quoteToken,
                creator: creator,
                buybackCreatorRecipient: buybackCreatorRecipient,
                protocolFeeRecipient: policy.protocolFeeRecipient,
                creatorTaxBps: creatorTaxBps,
                protocolFeeShareBps: policy.protocolFeeShareBps,
                buybackBurnBps: policy.buybackBurnBps,
                hookFeeBps: policy.hookFeeBps,
                maxInternalPriceImpactBps: policy.maxInternalPriceImpactBps,
                buybackEnabled: buybackEnabled
            });

  • codePonsV2MemeHook.sol:L251-L255
    Show source

    function setHookFeeBps(uint256 bps) external onlyOwner {
            if (bps > MAX_HOOK_FEE_BPS) revert InvalidBps();
            hookFeeBps = bps;
            emit HookFeeBpsUpdated(bps);
        }

  • codePonsV2MemeHook.sol:L352
    Show source

    if (uint256(creatorTaxBps) + policy.hookFeeBps > MAX_TOTAL_TRADE_FEE_BPS) revert InvalidBps();

  • on-chaincurve: graduated=true, feeBps=100, creatorTaxBps=100

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• LowPons 2-of-N multisig administers launchpad contractsownershipAI

  The Safe 0x263e…19Dd (signing threshold 2) owns the hook, factory, buyback vault and LP locker. Ownership of the hook cannot be renounced. What this Safe can do: - Change protocol-wide fee policy for new launches. - Rotate the fee sweep operator. - Call rescuePoolFees. This only pays the pool's pending fees to the recorded protocol and creator recipients, not to itself. - Re-point the vault's or locker's factory address. - Use factory functions such as rescueSweptGraduation, rescueCurveFees and a creator-fee-recipient override. Factory source was omitted. None of the verified code shown lets it take holders' OAK or the locked LP. It is a protocol-level trust point, not a project-specific one.

  Evidence

  • codePonsV2MemeHook.sol:L235-L237
    Show source

    function renounceOwnership() public pure override {
            revert OwnershipCannotBeRenounced();
        }

  • codePonsV2MemeHook.sol:L555-L603
    Show source

    function rescuePoolFees(PoolId poolId)
            external
            onlyOwner
            nonReentrant
            returns (uint256 protocolAmount, uint256 creatorAmount)
        {
            LaunchInfo memory info = launches[poolId];
            if (!info.registered) revert UnknownPool();
            address quoteToken = info.quoteToken;
    
            if (quoteToken != address(0)) {
                (protocolAmount, creatorAmount) = _rescueCurrency(poolId, info, quoteToken);
            }
            (uint256 memecoinProtocol, uint256 memecoinCreator) = _rescueCurrency(poolId, info, info.memecoin);
            if (protocolAmount == 0 && creatorAmount == 0 && memecoinProtocol == 0 && memecoinCreator == 0) {

  • on-chainSafeL2 0x263ed295dAFaE1d9AAdD6E56c4B6F9f38eE019Dd getThreshold = 2
  • staticPonsV2LaunchFactory fn rescueSweptGraduation(address,address) [owner] @PonsV2LaunchFactory.sol:L1254-L1286 — sends tokens out, sends ETH

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• InfoProject helper contracts on token page are unverifiedotherAI

  The site's token page references two unverified contracts: - 0x9d3A…BD30, with functions such as setPriceSigner, safe, oakToken and syncPhase. - 0x0704…08f4, with functions such as sweepStuck, lastBurnAt, oracle and safe. These look like project-run buyback, burn or sale helpers. Without source, nobody can confirm who can call sweepStuck or setPriceSigner, or what funds those contracts hold. This is an unknown, not proof of harm.

  Evidence

  • on-chainsite-mention 0x0704AE41934EE9b71A85cBd308786CfE503108f4 verified=false: fn sweepStuck() [unknown (unverified)]
  • on-chainsite-mention 0x9d3Ae2a760B6266F8A92240a59e5006D1AADBD30 verified=false: fn setPriceSigner(address) [unknown (unverified)]

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• InfoWebsite is docs for a CLI tool, no wallet connectionwebsiteAI

  The automated deposit and withdraw tests found no wallet-connect interface on the site. One test ended in an AI driver timeout; the other found that the site is documentation only. No transactions or approvals were requested, so nothing risky was observed on the site.

  Evidence

  • forkdappTests withdraw: observed
    Show source

    Oak Agent Kit is a CLI/MCP agent tool website with informational documentation only; there is no dApp interface

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• InfoX account is new and the team is anonymoussocialAI

  @OakAgentKit was created on 2026-10-24, the domain on 2026-10-27, and the token on 2026-11-02. The account is verified with 686 followers and ordinary post engagement. The about page and recent posts do not name a founder or show identity proof, so 'who runs this' is unverifiable. That is a trust gap, not evidence of a rug.

  Evidence

  • webhttps://oakagentkit.org/about.html
    Show source

    Oak is independent and is not affiliated with Robinhood.

  Confirmed by: grok-4.7