Bugglo: reading contracts on chain 4663, and admitting the rest

Version 1.0 — engine bugglo@0.4.0. Research tool, not financial advice.

Abstract

Robinhood Chain went live on 1 July 2026 as a permissionless Arbitrum Orbit layer 2, chain 4663. Capital arrived before safety tooling did, and the token-security services traders reach for either do not cover the chain or answer questions they cannot actually see. This paper describes Bugglo: a read-only contract inspector that talks to chain 4663 and no other chain, reports each finding with the reason it was reachable, and treats "I could not check this" as a first-class result rather than a gap to be smoothed over. Its strongest verdict is CAUTION. It never certifies a token as safe, and it is designed so that it cannot.

1. The gap

Permissionlessness is a design choice, not a defect — it is the same property that lets an honest developer ship on day one without asking anyone. But it means the instruments that measure a chain arrive after the money does. Within two weeks of launch, journalists were documenting honeypots on chain 4663: contracts that accept a buy, credit the wallet for a moment, and return the tokens to the deployer.

The tooling did not keep pace. GoPlus, the most widely used token-security API, lists the chain as supported and returns 14 fields where the same endpoint on Ethereum returns 37 — without is_honeypot, is_mintable, is_proxy, lp_holders or owner_percent. TokenSniffer, Honeypot.is and RugCheck.xyz do not claim chain 4663 at all.

2. The failure mode: a fabricated absence

The specific failure this project exists to prevent is not a wrong number. It is an invented absence — a tool reporting nothing where it should report that it cannot see.

Two observed examples. First: for a token sitting in a $9.77m Uniswap pool, GoPlus returned is_in_dex: 0. It did not report that it could not see the pool; it returned a zero, which reads exactly like a finding. Second: an AI agent wired to general-purpose MCP servers was asked for a rug check on a real token and replied that the address was "not a token contract, an empty wallet with no code and zero balance" — adding that it had checked "Robinhood Chain (Mezo)". Mezo is a different chain. The contract carries 4,830 bytes of code, a live supply, and real liquidity.

Neither system failed loudly. A blank was dressed as a result, and a true finding about the wrong place was presented as a finding about the right one. Every design decision below follows from treating that, and not inaccuracy, as the primary risk.

3. Design principles

3.1 Identity before inspection. Before reading anything, the engine asks the RPC which chain it is and requires the answer to be 4663 (0x1237 on the wire). If the endpoint names another chain, it stops. It does not fall through to another RPC and answer from wherever it lands, because an answer from the wrong chain is worse than no answer. Every report prints the chain it checked at the top.

3.2 Silence is not a pass. A public RPC can be rate-limited, down, or DNS-intercepted by an ISP. When the chain is unreachable the verdict is CANNOT CHECK and the summary says so in one sentence: no findings, not good ones and not bad ones. A green report that cannot be trusted is worse than a blank one that can.

3.3 Disclosure, not judgement. Privileged powers in bytecode are reported as facts about the code, not as accusations. Plenty of honest tokens are mintable.

3.4 One engine, three doors. There is a single rugCheck function. The CLI, the MCP server and this web app all call it, rather than three lookalikes kept in step by hand — so a terminal, an agent and the site cannot drift into telling you three different things about one address.

4. What the engine measures

Code presence and size. Whether there is a contract at the address at all, and how large it is. No code is its own verdict: NOT A CONTRACT.

ERC-20 conformance. Whether the contract answers the standard interface.

Ownership, as three distinct states. Renounced, held by a live address, or missing a standard owner() function entirely. These are kept apart on purpose: a contract whose owner() call reverts has renounced nothing, and collapsing the two would manufacture a guarantee out of a revert.

Upgradeability. Whether the contract is a proxy whose implementation can be replaced tomorrow.

Privileged powers in bytecode. Mint, pause and blacklist selectors are located inside the compiled code rather than called, because a mint that reverts for you still mints for the owner. This check reports that the powers exist, and separately reports whether a live owner remains. It does not resolve which address may invoke which power — whoever holds the keys can use them, and the bytecode does not say who that is.

Market depth, from a third party. Liquidity, volume and the balance of buys against sells come from DexScreener, not from the chain. The engine names the depth of the deepest pool, and when a valuation stands many times above that pool it says so: a price that only exists on paper, because the pool cannot pay it out.

Exit simulation. The engine simulates a full exit against the identified pool. When market data is unavailable, or no pool exists, the result is UNKNOWN — an absent market is not a pass.

Supply at addresses that can be named. Launcher, owner, factory, DEX pools and burn sinks are asked for their balances. This is a partition with an unaccounted remainder, not a holder distribution — see §6.

Deployer forensics. Deep deployer history is served by paid x402 tools. Without a funded wallet key they return a price probe rather than a report, so this is not part of the free path.

5. The verdict ladder

No verdict is a number. When the engine can read a token it grades what it found on a short scale: NO RED FLAGS IN WHAT I COULD CHECK when nothing is flagged, MIXED for a single warning, CAUTION for two or more. That is the whole ladder, and there is no louder grade.

When too little could be read to grade honestly, the verdict is INSUFFICIENT DATA, and it ranks above the graded verdicts deliberately: missing two answers, the tool will not assemble a concern level out of the gaps. Beside it sit the two blunt outcomes — NOT A CONTRACT, when there is no code at the address, and CANNOT CHECK, when the chain is out of reach.

The ceiling is worth sitting with. A token with a live owner, a mint selector and a few-thousand-dollar pool draws three warnings: CAUTION. An entirely ordinary owned, mintable token draws two: also CAUTION. The engine is not ranking the first above the second, and it is calling neither a rug. CAUTION means look closer, not run.

6. What it cannot measure

These are published as part of every result, with the reason attached, rather than omitted.

Holder concentration.A true holder distribution requires replaying the token's entire Transfer history. On chain 4663 a full-range log query times out, a 1M-block window times out too, and no indexer covers the chain. What is measurable is the neighbouring question — supply held at addresses that can be named. The distinction is the whole point: a partition of named addresses is not a distribution of holders. The remainder may be ten thousand independent buyers or one wallet the launcher opened an hour before launch, and those two worlds are identical from here. So the reassuring reading is the dangerous one: an insider balance of 0% is not evidence of a fair launch, because moving the bag to a fresh address costs one transaction. The report leads with what is unaccounted for, never with a clean number, and there is no score.

Liquidity-lock status. Resolving a lock requires a known locker registry. There is no locker registry for this chain, so a locked pool and an unlocked one look identical from here.

Attribution of powers. As above: the engine proves a power exists in the code and reports whether an owner is live. It cannot tell you who is able to use it.

7. Architecture

The engine is a small library over viem and nothing else — npx cold-start is the entire first-impression budget. It ships through three doors that share one implementation:

Command line. No account, no API key, no backend:

npx bugglo <address>

MCP server. For an agent to call before it acts on a contract it never read — the exact situation in §2:

{
  "mcpServers": {
    "bugglo": { "command": "npx", "args": ["-y", "bugglo-mcp"] }
  }
}

This site. The same engine behind a chat interface.

Resolver resilience. Where an ISP DNS-blocks the RPC hostname, every read fails for reasons that have nothing to do with the token, so the client resolves over DNS- over-HTTPS rather than reporting a chain outage as a finding. If DoH is blocked too, it fails honestly and the caller reports CANNOT CHECK. It never guesses.

8. Non-goals, and what this is not

Bugglo will not call a token a rug, and it will never call one safe. On this chain today nothing can read a contract and promise either, and a tool claiming otherwise would be the most dangerous one on it. A report that flags nothing is not a guarantee of safety; a flagged one is not proof of fraud.

The engine is read-only and cannot move your funds. The hosted backend does spend its own USDC via x402 for paid tools, which is a separate thing from your wallet and is metered against a daily cap. Never enter a private key or seed phrase into this or any other product.

The engine is MIT licensed. The reference implementation and its tests are the normative specification — where this document and the code disagree, this document is the bug.

References

Reported honeypots and losses on chain 4663 are drawn from reporting by Protos (10 July 2026) and U.Today (13 July 2026). Each is a reported loss — a victim account relayed by a journalist rather than on-chain forensics — and the word reported stays attached to it. Chain-level figures are from Blockscout, L2BEAT and DefiLlama as of mid-July 2026. Comparison tooling was tested directly; De.Fi Scanner and RobinScan were not tested and no claim is made about either.

Further reading: Bugglo CLI documentation, RobinX MCP, FAQ.