I Built a Liquidity Sniper Bot for pons on Robinhood Chain

I’ve been experimenting with automated trading on Robinhood Chain, and one problem immediately stood out:

How do you detect a new token launch, evaluate its liquidity, and react quickly enough to trade it automatically?

That led me to build a pons liquidity sniper bot.

The goal isn't simply to "buy new tokens." The interesting engineering problem is building a system that can detect launches onchain, filter risky tokens, estimate liquidity and price, execute trades, and manage the position automatically.

Here’s how I approached it.

The idea

The bot follows an event-driven pipeline:

Robinhood Chain
      ↓
Detect pons launch
      ↓
TokenLaunched event
      ↓
Risk filters
      ↓
Liquidity + price analysis
      ↓
Trading decision
      ↓
Swap execution
      ↓
Position monitoring
      ↓
Take profit / Stop loss

Instead of continuously polling every token, the bot listens for the blockchain events that matter.

That makes the system simpler and much more responsive.

Why Robinhood Chain + pons?

Robinhood Chain mainnet uses chain ID 4663 and ETH as its native token.

Robinhood Chain documentation

pons provides token launches and liquidity infrastructure on Robinhood Chain, making it an interesting environment for experimenting with automated onchain strategies.

pons documentation

The important part is that the blockchain itself gives us the data needed to build the bot.

Detecting new launches

The first component watches the pons factory for TokenLaunched events.

Conceptually:

publicClient.watchContractEvent({
  address: PONS_FACTORY,
  abi: ponsAbi,
  eventName: "TokenLaunched",

  onLogs: async (logs) => {
    for (const log of logs) {
      await analyzeLaunch(log);
    }
  },
});

When a launch appears, the bot extracts things like:

token address
deployer
liquidity pool
paired asset
launch configuration
restrictions
initial buy information

This becomes the starting point for the trading decision.

The bot doesn't buy everything

This was probably the most important design decision.

A sniper bot that buys every new token isn't really a strategy.

It's just an automated way to lose money faster.

Before entering a trade, I want the bot to check:

Is the token valid?
        ↓
Is the liquidity sufficient?
        ↓
Is the pool the expected pool?
        ↓
Are launch restrictions acceptable?
        ↓
Does the price/liquidity relationship make sense?
        ↓
Does the risk score pass?
        ↓
BUY

Possible filters include:

minimum liquidity
maximum estimated market cap
token/pool verification
creator information
holder concentration
trading restrictions
slippage
maximum position size

Names and symbols aren't enough. They can be copied.

The contract address is what matters.

Liquidity matters more than market cap

A common mistake with new tokens is focusing on market cap.

For a new launch, I'd rather know:

"How much liquidity can I actually trade against?"

than:

"What is the displayed market cap?"

A token can have a large theoretical market cap while having very little liquidity.

That creates huge price impact.

So the bot treats liquidity as one of the primary inputs to the decision.

Getting the price

Current pons pools use Uniswap V3 infrastructure.

The bot can read the pool's slot0() data and use sqrtPriceX96 to derive the current price.

The important detail is token ordering and decimals.

sqrtPriceX96
      ↓
raw token price
      ↓
adjust token0/token1
      ↓
adjust decimals
      ↓
usable token price

This is one of those areas where a seemingly small mistake can make an automated trading system produce completely wrong numbers.

Execution

Once a token passes the filters, the execution layer prepares the swap.

The flow looks like:

Signal
  ↓
Calculate position size
  ↓
Calculate minimum output
  ↓
Build transaction
  ↓
Simulate / validate
  ↓
Send transaction
  ↓
Wait for confirmation
  ↓
Record position

I also keep execution separate from the strategy logic.

That way I can change the trading strategy without rewriting the blockchain transaction layer.

Position management

Buying is only half of the system.

After entering, the bot monitors the position and evaluates:

current price
entry price
unrealized PnL
liquidity
time in position
stop-loss conditions
take-profit conditions

For example:

Entry
 ↓
 ├── Take profit → SELL
 ├── Stop loss   → SELL
 ├── Liquidity risk → EXIT
 └── Otherwise → KEEP MONITORING

The exact thresholds are strategy parameters, not hardcoded assumptions.

Risk management

This is where I'd spend most of the development time.

The bot should have hard limits such as:

MAX_POSITION_SIZE
MAX_DAILY_LOSS
MAX_SLIPPAGE
MAX_OPEN_POSITIONS
MAX_GAS
MAX_TOKEN_EXPOSURE

And most importantly:

KILL_SWITCH = true

If something goes wrong, I want the ability to stop new trades immediately.

Automation is useful.

Uncontrolled automation is dangerous.

The architecture

The final system is intentionally modular:

┌──────────────────────┐
│ Robinhood Chain RPC  │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Launch Event Monitor │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Token Risk Analyzer  │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Liquidity / Pricing  │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Trading Strategy     │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Execution Engine     │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Position Manager     │
└──────────────────────┘

Each component has one job.

That makes it easier to test, replace, and eventually run multiple strategies against the same infrastructure.

What I'd improve next

The current version is mainly an engineering foundation.

The next things I'd experiment with are:

better token risk scoring
faster event processing
more accurate liquidity analysis
dynamic position sizing
volatility-based entry thresholds
backtesting historical launches
better exit strategies
persistent trade analytics
multiple strategies running simultaneously

I'd also like to collect enough launch data to answer a more interesting question:

Do these signals actually provide a measurable trading edge, or are they just fast ways to participate in highly volatile markets?

That's the part I'm most interested in testing.

Open source

I've published the project here:

GitHub — Robinhood Chain Bot

The goal is to keep experimenting openly and improve the architecture based on real data rather than assumptions.

If you're also building trading bots, launch monitors, or onchain infrastructure, I'd be interested in hearing how you're approaching it.

Resources

Contact info

Telegram: https://t.me/BenjaminCup