DEV Community

Cover image for Robinhood Chain Development with TypeScript: Building Pons Trading Systems
hamssog
hamssog

Posted on Originally published at hamssog.substack.com

Robinhood Chain Development with TypeScript: Building Pons Trading Systems

#typescript #trading #blockchain #web3

When people search for a Robinhood Chain developer, they usually are not looking for another generic blockchain application.

They have a specific product in mind.

Maybe it is:

  • a Pons Sniper Bot
  • a Pons Bundler
  • a Pons Copy Trading Bot
  • a Pons Trading Terminal
  • a Stock Token Trading Bot
  • a Stock Token Arbitrage Bot
  • a wallet tracker
  • a launch monitor
  • a multi-wallet trading system

The difficult part is rarely making one blockchain call.

The difficult part is connecting market data, protocol logic, risk management, transaction execution, persistence, and reconciliation into one system that can actually operate.

That is the area I focus on.

The architecture I use

For trading automation, I prefer this separation:

                 ROBINHOOD CHAIN
                        ↓
                PROTOCOL / DATA
                        ↓
                 STRATEGY ENGINE
                        ↓
                   RISK ENGINE
                        ↓
                EXECUTION ENGINE
                        ↓
              TRANSACTION STATE
                        ↓
                POSITION STATE
                        ↓
                RECONCILIATION
                        ↓
             API / DASHBOARD / ALERTS
Enter fullscreen mode Exit fullscreen mode

The strategy decides what should happen.

Risk decides whether it is allowed.

Execution handles the transaction.

Reconciliation determines what actually happened onchain.

That makes the system much easier to test and extend.

Robinhood Chain is an EVM development environment

Robinhood's current documentation describes Robinhood Chain as an Arbitrum Layer-2 built on Ethereum, with ETH as the native gas token. Mainnet uses chain ID 4663, while the testnet uses 46630. The network supports standard Ethereum development tooling and EVM wallet/RPC integrations.

For a TypeScript application, that means the familiar stack can be used:

TypeScript
   ↓
viem / ethers
   ↓
RPC
   ↓
Smart Contracts
   ↓
Robinhood Chain
Enter fullscreen mode Exit fullscreen mode

That is useful because the application architecture does not need to be reinvented around a proprietary SDK.

Pons development is protocol-specific

Pons is where generic EVM knowledge stops being enough.

The official Pons contracts repository currently documents two generations:

V1
→ fixed-supply ERC-20
→ Uniswap V3 launch position

V2
→ bonding curve
→ curve trading
→ graduation
→ locked Uniswap V4 pool
Enter fullscreen mode Exit fullscreen mode

Both generations are live, and the official repository lists separate factories for V1 and V2.

That distinction affects:

events
pricing
execution
liquidity
launch lifecycle
quote calculation
contract addresses
Enter fullscreen mode Exit fullscreen mode

So I would not build a "Pons integration" and assume it works across both versions.

The implementation needs to know which generation it is integrating.

Pons V2 changes the trading lifecycle

Pons V2 starts a token on a bonding curve.

The lifecycle is:

CREATE
   ↓
BONDING CURVE
   ↓
TRADING
   ↓
CURVE COMPLETION
   ↓
UNISWAP V4
Enter fullscreen mode Exit fullscreen mode

The official V2 documentation describes the curve as holding the token supply and pricing trades according to the current curve state. After graduation, liquidity moves into a permanently locked Uniswap V4 pool.

That means a Pons V2 application needs to understand phase.

A token being newly launched is not the same execution environment as a graduated token.

Building a Pons Sniper Bot

One concrete application is a Pons Sniper Bot.

The basic workflow is:

TokenLaunched
      ↓
Decode Launch
      ↓
Apply Filters
      ↓
Read Curve State
      ↓
Calculate Quote
      ↓
Risk Check
      ↓
Submit Buy
      ↓
Monitor Transaction
      ↓
Reconcile Position
Enter fullscreen mode Exit fullscreen mode

The important part is that launch detection is only the beginning.

A useful sniper needs to understand the current curve and its trading rules.

Pons V2 documents launch protection through a decaying buy-side snipe tax. The documentation says the tax starts at 99% and decays toward zero over the first five seconds. The tax is recipient-specific, and additional exemption addresses can be defined when the launch is created.

So a quote engine should not simply calculate curve mathematics.

It should also account for:

curve state
+
trade fee
+
creator tax
+
snipe tax
+
slippage
Enter fullscreen mode Exit fullscreen mode

The repository I maintain for the Pons sniper demonstrates the V2 launch-detection and execution flow, including dry-run support and risk controls.

GitHub: 0xhamssog/pons-sniper-bot

Pons V2 quote calculation

The quote is one of the places where a superficial implementation can break.

The current Pons V2 documentation distinguishes between:

getReserves()
Enter fullscreen mode Exit fullscreen mode

and the curve's physical quote reserve.

The documentation recommends using the pricing reserves for quote calculations rather than treating arbitrary contract balances as the pricing state.

Conceptually:

Curve Reserves
      ↓
Fee Calculation
      ↓
Tax Calculation
      ↓
Trade Size
      ↓
Expected Tokens
      ↓
Minimum Tokens Out
Enter fullscreen mode Exit fullscreen mode

The bot should calculate minTokensOut from the actual expected execution rather than from a generic percentage.

That becomes especially important when several transactions are moving the curve.

Partial fills near graduation

Another important V2 edge case occurs near the end of the bonding curve.

The current documentation describes a final buy that may be partially filled when the requested amount would exceed the remaining sellable token inventory. Unused quote can be refunded in the same transaction.

That means:

Requested Buy
     ↓
Available Curve Inventory
     ↓
Maximum Fill
     ↓
Partial Execution
     ↓
Refund
Enter fullscreen mode Exit fullscreen mode

A bot that assumes:

```text requested amount = filled amount




can produce incorrect portfolio state.

The transaction layer therefore needs actual fill information.

---

## Building a Pons Bundler

A bundler solves a different problem from a sniper.

The current public Pons V2 bundler implementation I work with launches a token using `launchAndBuy`, registers additional buyer wallets as snipe-tax exemptions, and then submits those additional buys separately. The repository explicitly describes this as a launch bundler rather than an ERC-4337 UserOperation bundler.

The workflow is:
Enter fullscreen mode Exit fullscreen mode

Launch Configuration
↓
launchAndBuy
↓
Master Buy
↓
Buyer Wallets
↓
Parallel buy() Transactions
↓
Transaction Tracking
↓
Wallet State


markdown

An important protocol detail is that the extra wallets do **not** share the same atomic transaction.

The public implementation documents up to 32 additional buyer wallets as `snipeTaxExemptions`.

That distinction matters when designing the user experience.

The UI should not promise atomic multi-signer execution if the underlying protocol does not provide it.

GitHub: **0xhamssog/pons-bundler**

---

## Pons Copy Trading Bot

Copy trading is another product where the infrastructure changes.

Instead of watching launches, the system watches wallets.
Enter fullscreen mode Exit fullscreen mode

Tracked Wallet
↓
Onchain Activity
↓
Trade Decoder
↓
Normalized Signal
↓
Copy Rules
↓
Risk Engine
↓
Execution
↓
Position


plaintext

The important part is:



```text
detected transaction ≠ automatic copy
Enter fullscreen mode Exit fullscreen mode

A client may want:

copy 10%
max trade $500
max position $2,000
only selected tokens
minimum liquidity
maximum slippage
wallet allowlist
cooldown
Enter fullscreen mode Exit fullscreen mode

So the copy-trading system should transform wallet activity into a configurable strategy signal.

That lets the same tracking engine serve several different copy strategies.

Pons Trading Terminal

Not every trading product needs to be fully automated.

A Pons Trading Terminal can provide a human-facing interface over the same trading infrastructure:

Market Discovery
Token Detail
Wallet Management
Trading
Multi-Wallet Controls
Positions
P&L
Transaction History
Alerts
Automation
Enter fullscreen mode Exit fullscreen mode

The architecture becomes:

             WEB TERMINAL
                  ↓
                 API
                  ↓
            TRADING ENGINE
                  ↓
             RISK ENGINE
                  ↓
              EXECUTOR
                  ↓
           ROBINHOOD CHAIN
Enter fullscreen mode Exit fullscreen mode

This is useful because manual execution and automated strategies can share the same backend.

Stock Token development

Robinhood's current Stock Token documentation describes Stock Tokens as standard ERC-20 contracts with 18 decimals, corresponding to specific underlying equities or ETFs. It also provides onchain Chainlink pricing and asset metadata.

That makes several applications possible:

Stock Token Trading Bot
Stock Token Arbitrage Bot
Portfolio Tracker
Trading Dashboard
Risk System
Lending Application
Analytics
Enter fullscreen mode Exit fullscreen mode

The development pattern is similar:

Asset Registry
      ↓
Price Layer
      ↓
Strategy
      ↓
   Risk
      ↓
Execution
      ↓
Position
      ↓
Reconciliation
Enter fullscreen mode Exit fullscreen mode

Stock Token pricing is not just one number

Robinhood's current Stock Token APIs expose:

/assets
/prices/{symbol}
/corporate-actions
Enter fullscreen mode Exit fullscreen mode

The /assets response includes deployments, currentMultiplier, and trading capabilities.

The /prices/{symbol} endpoint returns the underlying-equity bid/ask without multiplier adjustment, while the onchain Chainlink price is multiplier-adjusted. The /prices endpoint is currently documented with a 15-second cache and a 60 requests/second rate limit.

A robust price adapter therefore needs to normalize the sources:

interface NormalizedPrice {
  symbol: string;
  source: "REST" | "CHAINLINK" | "DEX";
  priceUsd: number;
  timestamp: number;
  multiplierAdjusted: boolean;
}
Enter fullscreen mode Exit fullscreen mode

Then the strategy layer can consume normalized data without caring which provider produced it.

Corporate actions belong in the data layer

Stock Token applications also need to account for corporate actions.

The current API exposes currentMultiplier and corporate-action information, including events that explain changes in the multiplier.

That suggests:

Corporate Action
      ↓
Multiplier
      ↓
Normalized Price
      ↓
Portfolio Valuation
      ↓
Strategy
Enter fullscreen mode Exit fullscreen mode

The application should not hard-code assumptions about a token's economic representation into the strategy.

Risk engine

Across these products, the risk engine can remain reusable.

Typical rules include:

max trade size
max position
max exposure
minimum edge
maximum slippage
maximum gas
maximum quote age
maximum concurrent trades
daily loss limit
Enter fullscreen mode Exit fullscreen mode

A strategy produces:

interface TradeIntent {
  symbol: string;
  side: "BUY" | "SELL";
  quantity: bigint;
  maxSlippageBps: number;
  strategyId: string;
}
Enter fullscreen mode Exit fullscreen mode

The risk engine produces:

interface RiskDecision {
  approved: boolean;
  reason?: string;
}
Enter fullscreen mode Exit fullscreen mode

This keeps strategy code independent from safety rules.

Execution state machine

The execution engine is probably the most reusable component across all of these products.

I would model transaction state explicitly:

type TransactionState =
  | "CREATED"
  | "SIGNED"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "FAILED"
  | "UNKNOWN";
Enter fullscreen mode Exit fullscreen mode

Normal flow:

CREATED
   ↓
SIGNED
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED
Enter fullscreen mode Exit fullscreen mode

Failure/recovery flow:

SUBMITTED
   ↓
RPC TIMEOUT
   ↓
UNKNOWN
   ↓
RECONCILE
   ↓
CONFIRMED / FAILED / PENDING
Enter fullscreen mode Exit fullscreen mode

This is particularly important for automated trading.

An RPC timeout does not automatically prove that the transaction failed.

Reconciliation

The blockchain is the final source of truth for execution state.

So I would separate:

Application State
        ↓
Transaction Receipt
        ↓
Onchain Events
        ↓
Wallet Balances
        ↓
Canonical Position State
Enter fullscreen mode Exit fullscreen mode

Suppose local state says:

BUY 100
Enter fullscreen mode Exit fullscreen mode

but only 63 tokens were actually received.

The final position must become:

63
Enter fullscreen mode Exit fullscreen mode

Reconciliation protects the application from:

missed events
RPC failures
application restarts
partial fills
delayed confirmations
Enter fullscreen mode Exit fullscreen mode

Suggested TypeScript structure

A reusable Robinhood Chain trading codebase can be organized like this:

src/
├── protocols/
│   ├── pons/
│   │   ├── v1/
│   │   └── v2/
│   └── stockTokens/
│
├── market-data/
│   ├── robinhoodApi.ts
│   ├── chainlink.ts
│   └── dex.ts
│
├── strategies/
│   ├── sniper.ts
│   ├── copyTrading.ts
│   └── arbitrage.ts
│
├── risk/
│   └── riskEngine.ts
│
├── execution/
│   ├── executor.ts
│   ├── stateMachine.ts
│   └── transactions.ts
│
├── portfolio/
│   ├── positions.ts
│   └── pnl.ts
│
├── reconciliation/
│   └── reconcile.ts
│
├── api/
│
└── index.ts
Enter fullscreen mode Exit fullscreen mode

The important architectural decision here is keeping protocol adapters separate from strategies.

That means a strategy can consume normalized data without embedding Pons-specific contract calls throughout the application.

What I would build for different requirements

A client may need only one part of this stack.

Small integration

```text id="devrc29"
Pons contract integration
Event decoder
Quote calculation
Execution module




### Trading MVP



```plaintext
One strategy
One wallet
Risk controls
Dry-run
Execution
Trade history
Enter fullscreen mode Exit fullscreen mode

Production bot 

Multiple assets
Persistent state
Transaction monitoring
Reconciliation
Alerts
Monitoring
Enter fullscreen mode Exit fullscreen mode

Complete product 

Frontend
API
Trading Engine
Wallet Management
Risk
Portfolio
Analytics
Monitoring
Enter fullscreen mode Exit fullscreen mode

Advanced infrastructure 

Multi-wallet
Multiple strategies
Backtesting
Historical data
Custom APIs
Advanced risk
Execution orchestration
Enter fullscreen mode Exit fullscreen mode

Starting smaller also makes it possible to validate a trading idea before building the complete product.

Public implementation proof

I prefer showing code rather than simply describing protocol knowledge.

Pons Sniper Bot

Pons V2 launch detection, curve quoting, dry-run execution, filtering, and risk controls.

GitHub: 0xhamssog/pons-sniper-bot

Pons Bundler

Pons V2 launchAndBuy, additional wallet exemptions, and parallel curve buys.

GitHub: 0xhamssog/pons-bundler

Stock Token Arbitrage

Robinhood Chain Stock Token arbitrage infrastructure around external/reference pricing and onchain markets.

GitHub: 0xhamssog/robinhood-stock-token-arbitrage-bot

These projects are useful as starting points for custom systems rather than being limited to one fixed implementation.

What can be built

The product surface I focus on is specific:

Product Main Engineering Problem
Pons Sniper Bot Launch detection + curve execution
Pons Bundler Multi-wallet launch execution
Pons Copy Trading Bot Wallet signals + configurable copying
Pons Trading Terminal Trading UI + execution backend
Stock Token Trading Bot Automated strategy execution
Stock Token Arbitrage Bot Pricing + executable spread
Wallet Tracker Onchain activity + position state
Launch Monitor Event detection + alerts
Multi-Wallet Trading Coordinated execution + risk
Custom Trading Infrastructure Reusable backend + execution systems

The exact implementation depends on the strategy, wallet model, execution requirements, and product scope.

Why I focus on exact products

There is a big difference between searching for:

"blockchain developer"
Enter fullscreen mode Exit fullscreen mode

and searching for:

"Pons sniper bot developer"

"Pons bundler"

"Pons copy trading bot"

"Pons trading terminal"

"Stock Token trading bot"

"Robinhood Chain trading bot"
Enter fullscreen mode Exit fullscreen mode

The second group represents a much more specific engineering requirement.

That is also how I approach development.

Instead of starting with:

"What blockchain technology can I build?"

I start with:

"What trading product needs to exist?"

Then I build the protocol integration underneath it.

From protocol integration to product

The long-term architecture can look like:

                    ROBINHOOD CHAIN
                           │
             ┌─────────────┴─────────────┐
             ↓                           ↓
           PONS                      STOCK TOKENS
             │                           │
             └──────────┬────────────────┘
                        ↓
                  DATA LAYER
                        ↓
                 STRATEGY LAYER
                        ↓
                   RISK LAYER
                        ↓
                EXECUTION LAYER
                        ↓
                  STATE LAYER
                        ↓
              RECONCILIATION
                        ↓
          ┌─────────────┼─────────────┐
          ↓             ↓             ↓
       Terminal        API          Alerts
Enter fullscreen mode Exit fullscreen mode

This makes the underlying infrastructure reusable.

A new client does not necessarily need an entirely new trading engine.

A new product can reuse:

wallet management
risk
execution
transaction state
portfolio
reconciliation
monitoring
Enter fullscreen mode Exit fullscreen mode

and replace only the protocol-specific and strategy-specific components.

Conclusion

Robinhood Chain development is most interesting to me when it moves beyond a single contract call and becomes a real trading application.

That means building:

Protocol Integration
      +
Market Data
      +
Strategy
      +
   Risk
      +
Execution
      +
Persistent State
      +
Reconciliation
      =
Trading Product
Enter fullscreen mode Exit fullscreen mode

For Pons, that can become a Sniper Bot, Bundler, Copy Trading Bot, or Trading Terminal.

For Stock Tokens, it can become a Trading Bot, Arbitrage Bot, Portfolio System, or Trading Interface.

For a larger project, those components can become a complete Robinhood Chain trading platform.

I focus on that middle layer between trading idea and working software.

Custom Robinhood Chain and Pons development: trading bots, multi-wallet systems, trading terminals, Stock Token automation, execution engines, APIs, and supporting infrastructure.

The starting point can be a small integration or MVP and expand as the product requirements become clearer.

Top comments (0)