true402
guide · ElizaOS

Add a rug check to your ElizaOS agent

Your ElizaOS agent can sign a swap in milliseconds — and buy a honeypot just as fast. This guide adds a pre-trade gate that proves a Base token is actually sellable before your agent spends a cent.

Install and wire the true402 rug-check plugin
# 1. Install the plugin (in the official ElizaOS plugin registry)
elizaos plugins add elizaos-plugin-true402
# or: npm i elizaos-plugin-true402

# 2. Register it in your character/agent config and add your payer key
{
  "plugins": ["elizaos-plugin-true402"],
  "settings": {
    "secrets": { "TRUE402_PAYER_PRIVATE_KEY": "0x..." }
  }
}

# The plugin calls the true402 API base: https://true402.dev/api
# Two actions:
#   CHECK_TOKEN_SAFETY      -> POST /v1/base/token-report      -> avoid | caution | ok
#   CHECK_LIQUIDITY_HISTORY -> POST /v1/base/liquidity-history -> removals already observed
§01 · why a static scan is not enough

The honeypot problem

Most token scanners read contract source and flags. That catches obvious junk, but the dangerous case is a token you can buy and cannot sell — a honeypot. Static analysis cannot always tell the difference, because the sell path can be gated by hidden state, blocklists, or transfer hooks that only fail at execution time.

true402 does the thing that matters for an autonomous trader: a real on-chain buy/sell simulation using a state-override eth_call. It buys, then tries to sell, and measures the actual output. That proves sellability rather than guessing at it. On top of the simulation it checks liquidity, ownership and mint authority, and deployer reputation, then rolls everything into a single verdict.

§02 · install the plugin

Add true402 to your agent

The plugin is published to npm as elizaos-plugin-true402 and listed in the official ElizaOS plugin registry (ElizaOS v2). Install it with the CLI:

  1. Run elizaos plugins add elizaos-plugin-true402 (equivalent to npm i elizaos-plugin-true402).
  2. Add the plugin id to your character's plugins array.
  3. Put a funded Base payer key in settings.secrets.TRUE402_PAYER_PRIVATE_KEY — this wallet is your identity and pays per call. There is no account and no API key to provision.

The plugin registers two actions: CHECK_TOKEN_SAFETY (the pre-trade verdict, POST /v1/base/token-report, ~$0.01) and CHECK_LIQUIDITY_HISTORY (what has already happened to the token's liquidity, POST /v1/base/liquidity-history, ~$0.005). See §03 for why you want both.

See the copy-paste block above for the exact config shape.

§03 · the pre-trade-gate pattern

Check the verdict before buying

The rule is simple: gate every buy on a fresh verdict. Before your agent submits a swap for a token address, call the composite report and branch on the result.

  1. Your trade action receives a target token address, e.g. 0xabc....
  2. The plugin calls POST /v1/base/token-report at https://true402.dev/api for that address.
  3. The response carries a verdict of avoid, caution, or ok.
  4. Proceed with the swap only when the verdict is ok. Treat avoid as a hard stop and caution as a stop-or-confirm depending on your risk policy.

Because the check happens inside the action, the gate runs on the exact address and moment of the trade — not on stale data cached hours earlier.

The plugin ships two actions, and the second one is the half people miss. CHECK_TOKEN_SAFETY is the gate above. CHECK_LIQUIDITY_HISTORY (POST /v1/base/liquidity-history, ~$0.005) answers the question a live simulation structurally cannot, because it is about the past: every liquidity removal observed against the token, with amounts and transaction hashes, plus the other tokens drained in the same transaction — one actor, several pools. A pool drained last month simulates perfectly today if someone re-seeded it, so the safety verdict alone will not catch it. Run both before a large position. Every answer carries the block range the archive covers, so none observed is not a claim of safety.

For narrower signals not wrapped as actions, your own code can call the stalls over HTTP: POST /v1/token-safety for a structural 0–100 score, POST /v1/base/address-safety for a contract or wallet, POST /v1/base/deployer-check to weigh the deployer's history, or POST /v1/base/tx-preflight to inspect an unsigned transaction immediately before signing it.

§04 · pricing, free trial, and x402

How payment works

Calls are settled per request over x402 — USDC on Base, signed by your payer wallet. No subscription, no API key, no dashboard. The safety stalls also include a small free daily trial, so you can wire the gate and exercise it in development before any spend.

Each stall has its own per-call price, listed in the stall and endpoint reference. Fund the payer wallet with a small USDC float and the plugin handles the 402 payment handshake for you on each call.

§05 · try it and go deeper

Verify and reference

Before touching your agent, you can sanity-check any token in the browser — it exercises the same backend your agent will use.

Once the manual check looks right, keep the plugin gate in front of every buy action so the agent never trades a token it has not just verified as sellable.

§ questions

Answered for machines.

What is the difference between a rug check and a honeypot check?

A rug check looks at liquidity, ownership, mint authority, and deployer history to gauge intent. A honeypot check proves you can actually sell. true402 does both: it runs a real on-chain buy/sell simulation via state-override eth_call, then layers the structural checks into one verdict.

Do I need an API key or account to use the plugin?

No. There is no account, no signup, and no API key. Your Base payer wallet is your identity. You set TRUE402_PAYER_PRIVATE_KEY in your ElizaOS secrets, and the plugin pays per call over x402 with USDC on Base at request time.

How much does each check cost?

You pay per call in USDC on Base, with a small free daily trial on the safety stalls for development. Each stall has its own per-call price — see the stall and endpoint reference at https://true402.dev/docs/api for current prices.

Which stall should my agent call before a trade?

Use the CHECK_TOKEN_SAFETY action, which calls POST /v1/base/token-report. It returns a single avoid, caution, or ok verdict that combines the honeypot simulation with liquidity, ownership, and deployer signals. Gate the buy on that verdict. Before a large position also run CHECK_LIQUIDITY_HISTORY (POST /v1/base/liquidity-history), which reports the liquidity removals already observed against the token — a re-seeded pool simulates perfectly today, so the live verdict alone cannot see it. Drop to token-safety or deployer-check over HTTP when you only need a narrower signal.

Can I test a token without wiring the plugin first?

Yes. Run a live check in the browser at https://true402.dev/check. It needs no config, no key, and no ElizaOS setup, and it hits the same backend the plugin uses.