DEV Community: hamssog

Building a Robinhood Trading MCP Risk Gateway with TypeScript

hamssog — Wed, 07 Oct 2026 05:39:35 +0000

AI agents can now do more than answer questions.

They can interact with external applications through tools.

Robinhood's Trading MCP is one example: an external AI agent can connect to Robinhood and use supported account, portfolio, market-data, watchlist, equities, options, crypto, scanner, alert, and order-related tools. Robinhood also provides trade-approval controls for agentic trading.

That creates a new engineering problem.

The difficult part is not:

AI
 ↓
Place Order

The difficult part is:

AI Agent
   ↓
Trading MCP
   ↓
Permission Layer
   ↓
Risk Gateway
   ↓
Approval / Policy
   ↓
Order Execution
   ↓
Audit
   ↓
State Reconciliation

For this project, I am building a reusable Robinhood Trading MCP Risk Gateway with TypeScript.

The goal is to demonstrate how I would put deterministic controls between an AI agent and trading execution.

This is not an LLM stock-prediction system.

It is an execution-control system.

Why put a risk gateway between the agent and the broker?

An AI model can interpret instructions and select tools.

It should not automatically become the final authority over trading limits.

Consider:

User:
"Buy $5,000 of this stock."

The agent might generate:

symbol = XYZ
side = buy
amount = $5,000

But the application's risk policy might say:

maximum order = $1,000

The gateway should reject the request.

AI Agent
   ↓
Trade Intent
   ↓
Risk Gateway
   ↓
REJECTED

This is the central design principle:

The agent can propose an action, but deterministic application code decides whether that action is allowed.

The architecture

The initial architecture is:

+----------------------+
| AI Agent             |
+----------+-----------+
           |
           v
+----------------------+
| Robinhood Trading    |
| MCP                  |
+----------+-----------+
           |
           v
+----------------------+
| Tool Permission      |
| Layer                |
+----------+-----------+
           |
           v
+----------------------+
| Trade Intent         |
| Validation           |
+----------+-----------+
           |
           v
+----------------------+
| Risk Gateway         |
+----------+-----------+
           |
           v
+----------------------+
| Approval / Policy    |
+----------+-----------+
           |
           v
+----------------------+
| Execution            |
+----------+-----------+
           |
           v
+----------------------+
| Audit / State        |
+----------------------+

The gateway sits in the middle.

That makes the execution boundary explicit.

Robinhood's external-agent model

Robinhood's current Trading MCP documentation describes MCP as a mechanism for connecting an external AI agent to Robinhood so the agent can access information and take supported actions. Robinhood documents connections for platforms including Claude, ChatGPT, Codex, Cursor, Grok, Perplexity, OpenClaw, Replit, and others.

The external agent uses a dedicated MCP account for trading.

The agent can read information from the user's Robinhood accounts, while trading through the dedicated Agentic/MCP account.

That distinction is important when designing an application around the integration.

Read tools versus write tools

The first permission boundary I want is the separation between reading and changing state.

Conceptually:

Read
----
get_accounts
get_portfolio
get_watchlists
get_market_data
get_positions
get_history

versus:

Write
-----
place order
cancel order
modify order

Robinhood's current tool documentation exposes separate categories of account, portfolio, market-data, trading and advanced-order capabilities.

That allows the application to define permissions independently.

A research agent might receive only read permissions.

A portfolio assistant might receive read plus proposal permissions.

A trading agent might receive execution permissions only after additional policy checks.

The project structure

I want the repository to remain simple:

robinhood-mcp-risk-gateway/
├── src/
│   ├── agent/
│   │   └── agent-types.ts
│   │
│   ├── mcp/
│   │   ├── mcp-client.ts
│   │   └── tool-registry.ts
│   │
│   ├── permissions/
│   │   ├── permission.ts
│   │   └── permission-engine.ts
│   │
│   ├── trades/
│   │   ├── trade-intent.ts
│   │   ├── trade-validator.ts
│   │   └── trade-service.ts
│   │
│   ├── risk/
│   │   ├── risk-policy.ts
│   │   └── risk-engine.ts
│   │
│   ├── approvals/
│   │   └── approval-service.ts
│   │
│   ├── audit/
│   │   └── audit-log.ts
│   │
│   ├── state/
│   │   └── execution-state.ts
│   │
│   └── index.ts
│
├── test/
│   ├── unit/
│   └── integration/
│
├── examples/
├── docs/
├── package.json
├── tsconfig.json
├── .env.example
└── README.md

The core business rules should not be coupled directly to the AI model.

Structured trade intent

I don't want the rest of the application to consume free-form model output.

Instead, convert it into a typed intent.

For example:

type TradeIntent = {
  symbol: string;
  side: "buy" | "sell";
  orderType: "market" | "limit";
  quantity?: number;
  notional?: number;
  limitPrice?: number;
  rationale?: string;
};

The application can then validate the object before it reaches execution.

The flow becomes:

Natural Language
      ↓
AI Agent
      ↓
Structured Trade Intent
      ↓
Schema Validation
      ↓
Risk Validation

The AI's output becomes an input to the software system.

It is not the software system itself.

Why structured output matters

Compare these two outputs.

Free-form:

"Let's buy a meaningful amount of XYZ because momentum looks strong."

Structured:

{
  symbol: "XYZ",
  side: "buy",
  orderType: "market",
  notional: 500
}

The second can be validated.

For example:

max order = $1,000
requested = $500
result = ALLOWED

But:

max order = $1,000
requested = $5,000
result = REJECTED

This is much easier to test.

Risk policy

The risk policy should be deterministic.

A basic model:

type RiskPolicy = {
  maxOrderNotional: number;
  maxPositionNotional: number;
  maxPortfolioExposure: number;
  maxDailyLoss: number;
  maxTradesPerDay: number;
  allowedSymbols: Set<string>;
};

The risk engine can evaluate:

order size
position size
portfolio exposure
daily trading count
daily loss
symbol restrictions

The exact rules can be extended later.

Risk evaluation

The core API can be small:

type RiskDecision =
  | {
      allowed: true;
      checks: string[];
    }
  | {
      allowed: false;
      reason: string;
      failedChecks: string[];
    };

Then:

function evaluateTrade(
  trade: TradeIntent,
  policy: RiskPolicy,
): RiskDecision {
  // deterministic checks
}

The output should explain why a trade was accepted or rejected.

Example risk checks

A trade might go through:

Trade Intent
    |
    +--> symbol allowed?
    |
    +--> order size allowed?
    |
    +--> position limit allowed?
    |
    +--> portfolio exposure allowed?
    |
    +--> daily loss limit allowed?
    |
    +--> trading limit allowed?

Only when the required checks pass does the trade continue.

All checks pass
      ↓
Execution allowed

Symbol allowlists

One simple control is restricting which assets the agent can trade.

For example:

const allowedSymbols = new Set([
  "AAPL",
  "NVDA",
  "MSFT",
]);

Then:

if (!policy.allowedSymbols.has(trade.symbol)) {
  return {
    allowed: false,
    reason: "SYMBOL_NOT_ALLOWED",
    failedChecks: ["allowedSymbols"],
  };
}

This is intentionally boring.

Risk controls should be boring.

Position limits

Suppose the application has:

maximum position = $2,500

and the current position is:

$2,200

A new:

$500

order should fail because it would push exposure beyond the configured limit.

Current position
    $2,200
       +
New order
      $500
       =
    $2,700

Limit = $2,500

Result = REJECTED

The important part is that the decision is deterministic.

Portfolio exposure

The gateway can also enforce portfolio-level constraints.

For example:

Technology exposure: 48%
Maximum:             40%

An agent might still propose another technology trade.

The risk engine rejects it.

This creates a portfolio-aware execution boundary:

Agent
 ↓
Trade
 ↓
Portfolio State
 ↓
Risk Policy
 ↓
Decision

Daily loss controls

Another useful guardrail is a daily loss limit.

For example:

maximum daily loss = $500

If the application detects that the threshold has already been reached:

Trade Intent
     ↓
Risk Engine
     ↓
DAILY_LOSS_LIMIT
     ↓
Rejected

The agent does not get to override the policy.

Tool permissions

Risk is only one layer.

The agent also needs permissions.

I model capabilities such as:

READ_ACCOUNT
READ_PORTFOLIO
READ_MARKET_DATA
READ_WATCHLIST
PROPOSE_TRADE
PLACE_ORDER
CANCEL_ORDER

Then define which agent has which capability.

For example:

type AgentPermissions = {
  readAccount: boolean;
  readPortfolio: boolean;
  readMarketData: boolean;
  proposeTrade: boolean;
  placeOrder: boolean;
  cancelOrder: boolean;
};

A research agent can have:

readAccount = true
readPortfolio = true
readMarketData = true
placeOrder = false

An execution agent can be given a narrower set of explicitly required write permissions.

Human approval

Robinhood currently supports trade approvals for agentic trading. With approvals enabled, the agent can propose trades but the user must review and manually place them in Robinhood; with approvals disabled, eligible trades can be placed by the agent without manual confirmation of each order. Robinhood notes that certain trades may still require approval.

That maps naturally to two application modes.

Assisted mode

Agent
  ↓
Trade Intent
  ↓
Risk
  ↓
Approval Request
  ↓
Human
  ↓
Robinhood

Automated mode

Agent
  ↓
Trade Intent
  ↓
Risk
  ↓
Policy
  ↓
Robinhood

I would build assisted mode first.

Approval state

The application can represent approval explicitly:

type ApprovalStatus =
  | "NOT_REQUIRED"
  | "PENDING"
  | "APPROVED"
  | "REJECTED";

The trade lifecycle then becomes:

PROPOSED
   ↓
VALIDATED
   ↓
RISK_CHECKED
   ↓
APPROVAL_PENDING
   ↓
APPROVED
   ↓
SUBMITTED

Or:

RISK_CHECKED
   ↓
REJECTED

This makes the execution path easy to audit.

Order state

Once an order is submitted, the application still needs to track it.

A useful state machine:

id="robinhood-order-state"
PROPOSED
   ↓
VALIDATED
   ↓
APPROVED
   ↓
SUBMITTED
   ↓
OPEN
   ↓
FILLED
   ↓
RECONCILED

Failure paths:

SUBMITTED
   ├── REJECTED
   ├── CANCELED
   └── FAILED

The important distinction is:

order submitted

versus:

order filled

The second requires actual execution state.

Audit logging

Every meaningful agent action should produce an audit record.

For example:

type AuditRecord = {
  id: string;
  timestamp: string;
  agentId: string;
  action: string;
  tool: string;
  inputHash?: string;
  riskDecision?: string;
  approvalStatus?: string;
  result?: string;
  error?: string;
};

The goal is to answer:

Why did this order happen?

An audit trail should let us reconstruct:

User Request
     ↓
Agent Decision
     ↓
Tool Call
     ↓
Risk Decision
     ↓
Approval
     ↓
Order
     ↓
Result

The AI should not bypass the gateway

The architecture should enforce one execution route.

Not:

Agent
 ├── MCP
 ├── Direct API
 └── Another execution path

Instead:

Agent
   ↓
Trading MCP
   ↓
Risk Gateway
   ↓
Execution

There should be one clearly defined path to a trading action.

That makes permissions, logging, testing, and monitoring much easier.

Market data and account data

Robinhood's current agent tooling includes account, portfolio, watchlist, market-data, equities, options, crypto, scanner, alerts, and advanced order capabilities.

That means the agent can potentially build decisions from multiple sources:

Portfolio
     +
Market Data
     +
Watchlist
     +
Trading Rules
     ↓
Trade Proposal

The important engineering boundary remains:

Data
 ↓
Analysis
 ↓
Trade Intent
 ↓
Risk
 ↓
Execution

Portfolio-aware execution

A simple trading bot might know only:

symbol
price
signal

A portfolio-aware agent can incorporate:

current positions
buying power
existing exposure
trade history
P&L

For example:

Agent:
"Buy $500 of XYZ."

Portfolio:
Existing XYZ = $2,200

Risk:
Maximum XYZ position = $2,500

Result:
REJECT

The agent does not need to be trusted to remember the limit.

The policy engine enforces it.

Example workflow

Here is an example from start to finish:

User
 |
 | "Find a momentum opportunity
 |  and propose a $500 trade."
 |
 v
AI Agent
 |
 | market-data tools
 v
Robinhood MCP
 |
 v
Trade Intent
 |
 v
Risk Gateway
 |
 +--> symbol check
 +--> order-size check
 +--> position check
 +--> portfolio check
 |
 v
Approval
 |
 v
Order
 |
 v
Robinhood
 |
 v
Execution State
 |
 v
Audit Log

This is the architecture I want the GitHub project to demonstrate.

TypeScript service boundary

The core service can have one main operation:

async function processTradeIntent(
  intent: TradeIntent,
): Promise<TradeDecision> {
  validateTradeIntent(intent);

  const riskDecision = riskEngine.evaluate(intent);

  if (!riskDecision.allowed) {
    return {
      status: "REJECTED",
      riskDecision,
    };
  }

  return approvalService.handle(intent);
}

The important part is that the AI model does not call the broker directly.

It submits a typed request into the application's controlled pipeline.

Testing risk rules

Risk logic should be highly testable.

For example:

max order = $1,000

$500  → allowed
$1,000 → allowed
$1,001 → rejected

Position limits:

current = $2,000
limit   = $2,500

order = $400 → allowed
order = $500 → allowed
order = $501 → rejected

Symbol restrictions:

AAPL → allowed
XYZ  → rejected

Daily loss:

daily loss = $490
limit      = $500

new trade allowed if other constraints pass

Tests should cover boundary values.

Testing permissions

Permission tests should verify that an agent cannot use tools it does not have.

For example:

Research Agent
    ↓
get_portfolio
    ↓
ALLOW

But:

Research Agent
    ↓
place_order
    ↓
DENY

This gives the permission layer a simple and deterministic contract.

Testing approval flows

Test both modes.

Assisted:

Trade
 ↓
Risk passes
 ↓
Approval pending
 ↓
User approves
 ↓
Execution

Rejected:

Trade
 ↓
Risk passes
 ↓
Approval pending
 ↓
User rejects
 ↓
No execution

Automated:

Trade
 ↓
Risk passes
 ↓
Policy permits automation
 ↓
Execution

These tests should be independent of the actual AI model.

Testing failure paths

The system should also handle:

MCP unavailable
tool timeout
invalid tool result
risk rejection
approval timeout
order rejected
order canceled
execution failure
state synchronization failure

The goal is not to make the AI appear perfect.

The goal is to make the surrounding system behave predictably when the AI or external infrastructure is imperfect.

Secrets and account security

The gateway must not become a place where secrets are casually stored.

Do not:

log credentials
commit .env files
store private secrets in audit records
print authentication tokens

Use environment variables or an appropriate secret-management layer.

The repository should contain:

.env.example

but never actual credentials.

Why this architecture is reusable

The risk gateway does not have to be limited to one strategy.

It can sit underneath:

Momentum Agent
     ↓
Risk Gateway

Rebalancing Agent
     ↓
Risk Gateway

Portfolio Agent
     ↓
Risk Gateway

Research + Execution Agent
     ↓
Risk Gateway

The agent changes.

The controls remain.

The bigger architecture

The project fits into a larger trading system:

                         USER
                           |
                           v
                       AI AGENT
                           |
                           v
                 ROBINHOOD TRADING MCP
                           |
                           v
                 +--------------------+
                 | Permission Layer   |
                 +----------+---------+
                            |
                            v
                 +--------------------+
                 | Trade Intent       |
                 | Validation         |
                 +----------+---------+
                            |
                            v
                 +--------------------+
                 | Risk Gateway       |
                 +----------+---------+
                            |
                            v
                 +--------------------+
                 | Approval / Policy  |
                 +----------+---------+
                            |
                            v
                 +--------------------+
                 | Robinhood Order    |
                 +----------+---------+
                            |
                            v
                      ORDER STATE
                            |
                            v
                       AUDIT LOG

The gateway is the control point.

Why this is different from a traditional trading bot

A traditional bot often looks like:

Signal
 ↓
Order

A controlled agentic trading system looks more like:

User Intent
     ↓
AI Agent
     ↓
Tools
     ↓
Structured Intent
     ↓
Permission
     ↓
Risk
     ↓
Approval / Policy
     ↓
Execution
     ↓
Audit
     ↓
Reconciliation

That is a fundamentally different engineering problem.

What this proves to a client

The valuable statement is not:

"I can connect ChatGPT to Robinhood."

The stronger statement is:

I can build the controlled infrastructure around an AI trading agent.

That includes:

AI integration
+
MCP
+
Tool permissions
+
Structured outputs
+
Risk controls
+
Approval workflows
+
Execution
+
Auditability
+
State management
+
Failure handling

That is much closer to what a real trading product requires.

Final architecture

                       ROBINHOOD AI AGENT
                               |
                               v
                       TRADING MCP
                               |
                               v
                      TOOL PERMISSIONS
                               |
                               v
                     STRUCTURED INTENT
                               |
                               v
                        RISK ENGINE
                               |
                     +---------+---------+
                     |                   |
                     v                   v
                  REJECT              APPROVE
                                         |
                                         v
                                  TRADE APPROVAL
                                         |
                                         v
                                    ROBINHOOD
                                         |
                                         v
                                   ORDER STATE
                                         |
                                         v
                                    AUDIT LOG
                                         |
                                         v
                                  RECONCILIATION

The core principle is simple:

AI proposes. Software validates. Policy controls. Robinhood executes.

That is the architecture I am using to explore the new generation of Robinhood agentic trading infrastructure.

Building an EVM Event Indexer with TypeScript and viem

hamssog — Mon, 05 Oct 2026 11:16:29 +0000

A trading system needs to know more than whether a transaction was submitted.

It needs to know what happened on-chain.

A wallet traded.

A token was launched.

A position changed.

A protocol emitted an event.

A transaction was reverted.

A pool graduated.

For an automated trading application, these events eventually need to become structured application data.

That is the problem I am solving with this project:

Build a reusable EVM Event Indexer that turns blockchain logs into application-ready trading state.

The implementation uses:

TypeScript
viem
SQLite
Vitest
EVM-compatible networks

The indexer is designed to support applications such as:

Pons monitoring
wallet tracking
copy trading
arbitrage
stock-token systems
trading terminals
portfolio tracking
custom EVM applications

The key architecture is:

Blockchain
    ↓
Block Scanner
    ↓
Event Decoder
    ↓
Event Normalizer
    ↓
Deduplication
    ↓
Persistent Store
    ↓
State Processor
    ↓
API / Dashboard / Alerts

Why build an event indexer?

Reading blockchain data directly from every application quickly becomes repetitive.

Without a central indexing layer:

Pons Monitor
 └── reads logs

Wallet Tracker
 └── reads logs

Copy Trader
 └── reads logs

Trading Terminal
 └── reads logs

Each application ends up implementing its own:

block scanning
ABI decoding
event filtering
retry logic
deduplication
checkpointing

I prefer:

                EVM Blockchain
                       |
                       v
                 Event Indexer
                       |
        +--------------+--------------+
        |              |              |
        v              v              v
     Pons App      Wallet App     Trading App

One indexing layer.

Multiple consumers.

Raw EVM logs are not application state

A blockchain gives us low-level data.

A trading application usually wants high-level objects.

For example, the chain may provide an event containing encoded values.

The application may actually need:

type TradeEvent = {
  protocol: string;
  trader: `0x${string}`;
  token: `0x${string}`;
  side: "buy" | "sell";
  amountIn: bigint;
  amountOut: bigint;
  transactionHash: `0x${string}`;
  blockNumber: bigint;
};

The indexer performs the transformation:

Raw Log
   ↓
Decode
   ↓
Normalize
   ↓
Typed Domain Event

Now downstream code does not need to understand low-level log encoding.

Overall architecture

The project is split into several responsibilities:

+----------------------+
| EVM Blockchain       |
+----------+-----------+
           |
           v
+----------------------+
| Block Scanner        |
+----------+-----------+
           |
           v
+----------------------+
| Log Fetcher          |
+----------+-----------+
           |
           v
+----------------------+
| Event Decoder        |
+----------+-----------+
           |
           v
+----------------------+
| Event Normalizer     |
+----------+-----------+
           |
           v
+----------------------+
| Deduplication        |
+----------+-----------+
           |
           v
+----------------------+
| SQLite               |
+----------+-----------+
           |
           v
+----------------------+
| State Processors     |
+----------+-----------+
           |
           v
+----------------------+
| API / Alerts / UI    |
+----------------------+

The protocol-specific logic stays separate from the generic indexing engine.

Project structure

A simple repository structure:

evm-trading-event-indexer/
├── src/
│   ├── scanner/
│   │   ├── block-scanner.ts
│   │   └── log-fetcher.ts
│   │
│   ├── decoder/
│   │   ├── event-decoder.ts
│   │   └── abi-registry.ts
│   │
│   ├── normalizer/
│   │   └── event-normalizer.ts
│   │
│   ├── checkpoint/
│   │   └── checkpoint-store.ts
│   │
│   ├── persistence/
│   │   ├── database.ts
│   │   └── event-repository.ts
│   │
│   ├── deduplication/
│   │   └── event-deduplicator.ts
│   │
│   ├── reconciliation/
│   │   └── chain-reconciler.ts
│   │
│   ├── protocols/
│   │   ├── generic/
│   │   └── pons/
│   │
│   ├── state/
│   │   ├── trade-state.ts
│   │   ├── wallet-state.ts
│   │   └── position-state.ts
│   │
│   └── index.ts
│
├── test/
│   ├── unit/
│   ├── integration/
│   └── fixtures/
│
├── examples/
├── docs/
├── package.json
├── tsconfig.json
└── README.md

The important rule is:

Keep protocol-specific event decoding separate from generic scanning and persistence.

Block scanning

The first job is discovering blocks that need to be processed.

For historical indexing:

Start Block
    ↓
Block Range 1
    ↓
Block Range 2
    ↓
Block Range 3
    ↓
Latest Block

For live indexing:

Last Indexed Block
        ↓
New Blocks
        ↓
Fetch Logs
        ↓
Process
        ↓
Advance Checkpoint

The same processing pipeline should ideally handle both cases.

Block ranges

I prefer processing configurable block chunks rather than requesting an enormous historical range in one operation.

For example:

fromBlock = 1,000,000
toBlock   = 1,010,000

Then:

1,010,001 → 1,020,000

and so on.

The chunk size should be configuration rather than hard-coded.

That makes the indexer easier to adapt to different RPC environments and workloads.

Fetching logs with viem

With viem, event log retrieval can be performed through the public client.

For a known contract and event:

const logs = await client.getLogs({
  address: contractAddress,
  event: tradeEvent,
  fromBlock,
  toBlock,
});

The important part is filtering as early as possible.

Do not retrieve unrelated data and decode everything in application code when the RPC layer can filter it.

Useful filters include:

contract address
event signature
indexed parameters
block range

Event definitions

The indexer needs ABI definitions for the events it understands.

For example:

const tradeEvent = {
  type: "event",
  name: "TradeExecuted",
  inputs: [
    {
      indexed: true,
      name: "trader",
      type: "address",
    },
    {
      indexed: true,
      name: "token",
      type: "address",
    },
    {
      indexed: false,
      name: "amountIn",
      type: "uint256",
    },
    {
      indexed: false,
      name: "amountOut",
      type: "uint256",
    },
  ],
} as const;

The decoder can then convert matching logs into typed objects.

Decoding events

The decoder should have one job:

Convert an on-chain log into a domain event.

For example:

type DecodedTrade = {
  type: "TRADE_EXECUTED";
  trader: `0x${string}`;
  token: `0x${string}`;
  amountIn: bigint;
  amountOut: bigint;
  transactionHash: `0x${string}`;
  blockNumber: bigint;
  logIndex: number;
};

A good decoder should preserve the original blockchain identifiers.

At minimum:

transaction hash
block number
block hash
log index
contract address

These values are useful later for debugging and reconciliation.

Normalize events

Different protocols often represent similar actions differently.

One contract may emit:

TradeExecuted

Another:

Swap

Another:

Buy

The application may want one normalized concept:

TRADE_EXECUTED

So I use a normalization layer:

Protocol Event
      ↓
Protocol Decoder
      ↓
Normalized Event

For example:

type NormalizedEvent =
  | {
      type: "TRADE_EXECUTED";
      protocol: string;
      trader: `0x${string}`;
      token: `0x${string}`;
      amountIn: bigint;
      amountOut: bigint;
      transactionHash: `0x${string}`;
      blockNumber: bigint;
    }
  | {
      type: "TOKEN_LAUNCHED";
      protocol: string;
      token: `0x${string}`;
      creator: `0x${string}`;
      transactionHash: `0x${string}`;
      blockNumber: bigint;
    };

Now the rest of the application can consume a consistent interface.

Deduplication

An indexer should assume that an event may be seen more than once.

This can happen because of:

process restarts
retries
overlapping scans
checkpoint rollback
manual replay
reprocessing after an error

So the processing pipeline should be idempotent.

A log identity can be represented using:

chainId
transactionHash
logIndex

I also keep block metadata for reconciliation:

blockHash
blockNumber

The important behavior is:

Process event
     ↓
Process same event again
     ↓
No duplicate application event

Unique event constraints

The database should help enforce deduplication.

A table can contain:

events
------
id
chain_id
block_number
block_hash
transaction_hash
log_index
contract_address
event_name
event_data
indexed_at

Then define a unique constraint over the event identity.

For example:

(chain_id, transaction_hash, log_index)

The application can then safely retry processing without creating duplicate event records.

Checkpointing

The indexer needs to know where it stopped.

A checkpoint record can be:

checkpoints
-----------
chain_id
stream
last_block
updated_at

The processing flow should be:

Fetch block range
       ↓
Decode logs
       ↓
Normalize
       ↓
Persist
       ↓
Advance checkpoint

Do not reverse the last two steps.

This is dangerous:

Fetch
  ↓
Checkpoint
  ↓
Persist

If the process crashes between checkpointing and persistence, the indexer may permanently skip events.

Crash recovery

Suppose:

Blocks 10,000 - 10,100

are being processed.

The application crashes after processing through block 10,060.

After restarting:

read checkpoint
      ↓
resume from safe position
      ↓
reprocess overlapping events if necessary
      ↓
deduplication prevents duplicates

This combination is powerful:

Checkpointing
+
Idempotent Processing
+
Persistent Events

It makes recovery much safer.

Real-time indexing

After historical backfill is complete, the indexer can continue watching new blocks.

A simple loop:

while running

    latestBlock = getBlockNumber()

    if latestBlock > checkpoint
        process range

    wait

end

But the implementation should avoid a naive busy loop.

Use:

configurable polling
controlled sleep intervals
error backoff
cancellation support

The indexer should be able to shut down cleanly.

Historical backfill and live mode

I think of these as two operating modes:

+---------------------+
| Historical Backfill |
+----------+----------+
           |
           v
     Indexed State
           |
           v
+---------------------+
| Real-Time Indexing  |
+---------------------+

The important part is that they use the same decoder, normalizer, repository, and state-processing logic.

That reduces the risk of having:

backfill behavior ≠ live behavior

Reorganization awareness

One of the assumptions an indexer should avoid is:

A processed block can never change.

Chains can experience reorganizations.

That means the indexer should keep enough metadata to recognize block identity:

block number
block hash
parent hash

When the canonical chain changes, affected indexed data may need to be rolled back and replayed.

The exact policy depends on the chain and application.

For a trading application, the important thing is to make this a deliberate part of the architecture.

Events versus contract reads

Events and current contract state serve different purposes.

Events tell us:

Something happened.

A contract read tells us:

This is the state now.

For example:

Events:
Trade A
Trade B
Trade C

do not necessarily mean that simply summing those events gives the complete current state.

Some systems have:

cancellations
transfers
fees
refunds
partial executions
migrations
state resets

The indexer therefore needs to know when event history is enough and when state must be queried directly.

State processors

I do not want the indexer itself to become the complete trading engine.

Instead:

Indexed Event
      ↓
State Processor
      ↓
Position / Wallet / Protocol State

For example:

type TradeState = {
  wallet: `0x${string}`;
  token: `0x${string}`;
  position: bigint;
  tradeCount: number;
};

The indexer produces reliable input.

The state processor converts that input into a product-specific view.

Wallet tracking

A wallet tracker is a natural consumer.

The flow becomes:

Blockchain
   ↓
Event Indexer
   ↓
Trade Events
   ↓
Wallet Filter
   ↓
Wallet Activity

The application can then expose:

recent trades
positions
tokens
transaction history
PnL

The indexer itself remains generic.

Copy trading

The same indexed event can trigger another system.

For example:

Wallet Event
     ↓
Indexer
     ↓
Copy Strategy
     ↓
Risk Check
     ↓
Transaction Manager
     ↓
Blockchain

This creates a closed trading loop.

The indexer observes.

The strategy decides.

The transaction manager executes.

Pons event indexing

Pons is a useful example because its application layer can benefit from indexed launch and trading activity.

The current Pons V2 documentation describes launch, bonding-curve trading, graduation, and subsequent pool trading, with protocol events that can be indexed to reconstruct activity. (docs.ponsfamily.com)

A Pons-focused application can therefore use:

Pons Contracts
      ↓
Pons Event Decoder
      ↓
Normalized Pons Events
      ↓
Pons State

That state can power:

launch monitor
wallet tracker
trading dashboard
alerts
copy trading
analytics

Example Pons launch pipeline

Conceptually:

TOKEN_LAUNCHED
       ↓
Create Token Record
       ↓
Monitor Trading Events
       ↓
Update Curve State
       ↓
Detect Graduation
       ↓
Update Venue

The protocol adapter handles Pons-specific decoding.

The rest of the indexing infrastructure stays generic.

Building a generic protocol adapter

A protocol adapter can expose something like:

interface ProtocolAdapter {
  getSources(): IndexerSource[];

  decode(log: unknown): NormalizedEvent | null;

  normalize(event: unknown): NormalizedEvent | null;
}

Then the engine can register:

Generic EVM Adapter
Pons Adapter
Future Protocol Adapter

without changing the core scanner.

Persistence

For the reference implementation, SQLite is enough to demonstrate the architecture.

The database can store:

events
checkpoints
trades
tokens
wallet activity

The important distinction is between:

raw indexed data

and:

derived application state

Keeping those layers separate makes rebuilding state easier.

Rebuilding state

Suppose the position-state logic changes.

If the raw events are still stored, the state can be rebuilt:

Raw Events
    ↓
Replay
    ↓
New State Processor
    ↓
New State

This is a powerful property.

It prevents the system from depending entirely on whatever derived state happened to exist at one point in time.

API layer

The indexer can expose application-ready data through an API.

For example:

GET /events
GET /trades
GET /wallets/:address
GET /tokens/:address
GET /positions/:address

A WebSocket layer can later provide real-time updates.

For example:

New Trade
   ↓
Indexer
   ↓
WebSocket
   ↓
Trading Dashboard

The API should consume indexed state rather than performing raw blockchain scans on every request.

Monitoring

A production-style indexer needs its own monitoring.

Useful metrics include:

latest indexed block
indexing lag
events processed
processing errors
RPC failures
processing latency
reorg events
database latency

For example:

Blockchain height: 2,000,100
Indexed height:    2,000,096

Indexing lag:      4 blocks

This tells the operator whether the indexer is healthy.

Failure handling

The indexer should expect failures.

Examples:

RPC timeout
RPC rate limit
malformed event
decoder error
database error
process crash
network interruption
chain reorganization

The right response is not always:

retry forever

Some errors should be retried.

Some should be isolated.

Some should stop the affected stream and require investigation.

Error isolation

Suppose one malformed event causes a decoder error.

I do not want the entire indexer to lose all future blocks.

Instead:

Block
 ├── Event A → Processed
 ├── Event B → Processed
 ├── Event C → Decoder Error
 └── Event D → Processed

Depending on the application's requirements, the problematic event can be recorded for investigation while the system continues processing safely.

The exact policy should be explicit.

Idempotent processing

A retry should be safe.

For example:

First attempt:
block 200 → events A, B, C

Crash after B

Retry:
block 200 → events A, B, C

A correct idempotent pipeline produces:

A → one record
B → one record
C → one record

not:

A → duplicate
B → duplicate
C → duplicate

This is why event identity and database constraints are part of the architecture rather than an afterthought.

Testing strategy

The project uses two categories of tests.

Vitest
  ↓
Indexer / TypeScript logic

Integration tests
  ↓
RPC + local EVM + contracts

The important tests include:

event decoding
event normalization
block-range scanning
checkpointing
deduplication
historical replay
restart recovery
RPC failure
database failure

Decoder tests

Given a known event fixture:

raw log
  ↓
decoder
  ↓
expected normalized event

The test should verify every important field:

trader
token
amount
transaction hash
block number
log index

These tests protect against ABI or mapping mistakes.

Checkpoint tests

A useful scenario:

Process blocks 100-110
Crash after block 105
Restart
Resume safely

The expected result is that the event stream is complete and duplicates are eliminated.

Reprocessing tests

Another important test is deliberate replay:

Process block 500
Process block 500 again
Process block 500 again

Expected:

one event
one derived trade
one state update

This demonstrates idempotency.

Integration test

A simple end-to-end local test:

Mock Contract
      ↓
Emit Event
      ↓
Local EVM
      ↓
Indexer
      ↓
Decode
      ↓
Normalize
      ↓
Persist
      ↓
Query Indexed Event

This proves that the complete pipeline works rather than only testing isolated functions.

Connecting the indexer to a trading system

The indexer becomes especially useful when connected to the rest of the trading stack:

                   Blockchain
                       |
                       v
                 Event Indexer
                       |
                       v
                  Trading State
                       |
                       v
                    Strategy
                       |
                       v
                  Risk Engine
                       |
                       v
              Transaction Manager
                       |
                       v
                  Blockchain

This creates a feedback loop:

Observe
   ↓
Decide
   ↓
Execute
   ↓
Observe Again

That is the architecture behind many automated trading systems.

Connecting it to the transaction manager

The event indexer and transaction manager solve different problems.

The transaction manager answers:

What happened to the transaction I submitted?

The event indexer answers:

What happened on-chain?

Together:

Strategy
   ↓
Transaction Manager
   ↓
Blockchain
   ↓
Event Indexer
   ↓
Updated State

This is much more robust than treating a transaction hash as the final result.

Where this can be used

The same indexing layer can support:

Pons Launch Monitor
Pons Wallet Tracker
Pons Copy Trading
Stock Token Monitoring
Stock Token Trading
Arbitrage Detection
Trading Terminals
Portfolio Analytics
Wallet Intelligence
Custom EVM Applications

The indexer does not need to become a product-specific monolith.

It provides the data foundation underneath those products.

The engineering principles

The project is built around a few rules:

Blockchain is the source of truth.
Processing should be idempotent.
Checkpoints must be persistent.
Raw events should be retained.
Protocol logic should be isolated.
Uncertain state should remain explicit.
Recovery must be possible after restart.

These principles are more important than the particular TypeScript classes used to implement them.

What I am trying to prove with this project

The important capability is not simply knowing how to call:

client.getLogs(...)

The real engineering problem is building everything around it:

Block scanning
+
Event decoding
+
Normalization
+
Historical backfill
+
Real-time indexing
+
Checkpointing
+
Deduplication
+
Persistence
+
Reorg awareness
+
Failure recovery
+
State reconstruction

That is what turns blockchain logs into usable infrastructure.

Final architecture

                         EVM Blockchain
                               |
                               v
                         Block Scanner
                               |
                               v
                          Log Fetcher
                               |
                               v
                         Event Decoder
                               |
                               v
                       Event Normalizer
                               |
                               v
                         Deduplication
                               |
                               v
                       Persistent Store
                               |
                               v
                        State Processor
                               |
             +-----------------+-----------------+
             |                 |                 |
             v                 v                 v
          Positions           PnL             Alerts
             |                 |                 |
             +-----------------+-----------------+
                               |
                               v
                         API / Dashboard

And for an automated trading application:

Indexed Events
      ↓
Strategy
      ↓
Risk Engine
      ↓
Transaction Manager
      ↓
Solidity / EVM Executor
      ↓
Blockchain
      ↓
Event Indexer

The loop closes.

The application observes the blockchain, makes a decision, executes the decision, observes the result, and updates its state.

That is the infrastructure I am building for reusable EVM trading systems, Pons applications, Stock Token systems, arbitrage, copy trading, trading terminals, and custom blockchain products.

Building an EVM Transaction Manager for Automated Trading Bots

hamssog — Sat, 03 Oct 2026 13:46:09 +0000

A trading bot can detect an opportunity correctly and still execute incorrectly.

The strategy may be fine.

The transaction infrastructure may not be.

For automated EVM trading, I treat transaction management as its own engineering layer.

The system has to handle:

Signal
  ↓
Transaction Request
  ↓
Nonce Allocation
  ↓
Simulation
  ↓
Submission
  ↓
Pending
  ↓
Confirmation
  ↓
Reconciliation

And the failure paths matter just as much:

Pending
  ├── Reverted
  ├── Timed Out
  ├── Replaced
  ├── RPC Failure
  └── Unknown Nonce Consumption

For this project, I am building an EVM Transaction Manager with TypeScript, viem, SQLite, Vitest, and Foundry.

The goal is to create reusable infrastructure that can sit underneath:

automated trading bots
arbitrage systems
copy-trading systems
Pons applications
stock-token trading systems
trading terminals
custom EVM applications

This is not a trading strategy.

It is the transaction lifecycle underneath the strategy.

Architecture

The basic architecture is:

+----------------------+
| Trading Strategy     |
+----------+-----------+
           |
           v
+----------------------+
| Risk / Execution     |
+----------+-----------+
           |
           v
+----------------------+
| EVM Transaction      |
| Manager              |
+----------------------+
| Nonce Manager        |
| Persistence          |
| Submission           |
| Monitoring           |
| Retry Policy         |
| Replacement          |
| Reconciliation       |
+----------+-----------+
           |
           v
+----------------------+
| EVM RPC              |
+----------+-----------+
           |
           v
+----------------------+
| Blockchain            |
+----------------------+

The strategy should not own:

nonce allocation
transaction persistence
receipt polling
replacement logic
recovery after restart

Those responsibilities belong inside the transaction manager.

Why transaction management needs its own layer

A naive bot often looks like:

const hash = await walletClient.sendTransaction({
  account,
  to,
  data,
});

That produces a transaction hash.

It does not provide a complete execution lifecycle.

A more useful abstraction is:

submit()
   ↓
transaction ID
   ↓
pending
   ↓
confirmed / reverted
   ↓
reconciled

This lets the rest of the application work with a logical transaction rather than directly managing every RPC operation.

Project structure

The repository is organized around clear responsibilities:

src/
├── config/
│   └── env.ts
│
├── domain/
│   ├── transaction.ts
│   ├── transaction-status.ts
│   └── transaction-error.ts
│
├── clients/
│   └── evm-client.ts
│
├── nonce/
│   ├── nonce-manager.ts
│   └── nonce-lock.ts
│
├── persistence/
│   ├── database.ts
│   └── transaction-repository.ts
│
├── submission/
│   ├── transaction-submitter.ts
│   ├── fee-policy.ts
│   └── replacement-policy.ts
│
├── monitoring/
│   ├── transaction-monitor.ts
│   ├── receipt-monitor.ts
│   └── confirmation-monitor.ts
│
├── reconciliation/
│   └── transaction-reconciler.ts
│
└── services/
    └── transaction-manager.ts

The goal is not to create dozens of abstractions.

The goal is to keep blockchain access, persistence, lifecycle state, and business logic from becoming one giant class.

Transaction domain model

I use an explicit transaction record.

A simplified TypeScript version:

export type TransactionStatus =
  | "CREATED"
  | "QUEUED"
  | "SIMULATING"
  | "SUBMITTING"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "REVERTED"
  | "REPLACEMENT_PENDING"
  | "REPLACED"
  | "TIMED_OUT"
  | "RECONCILIATION_REQUIRED"
  | "RECONCILED"
  | "FAILED";

And the record:

export type TransactionRecord = {
  id: string;
  chainId: number;
  account: `0x${string}`;
  nonce: number;
  to: `0x${string}`;
  data?: `0x${string}`;
  value?: bigint;

  currentHash?: `0x${string}`;
  replacementHashes: `0x${string}`[];

  status: TransactionStatus;

  attemptCount: number;

  createdAt: number;
  submittedAt?: number;
  confirmedAt?: number;
  reconciledAt?: number;
  lastCheckedAt?: number;

  blockNumber?: bigint;
  blockHash?: `0x${string}`;

  errorCode?: string;
  errorMessage?: string;
};

One important implementation detail is avoiding JavaScript floating-point numbers for EVM amounts and fee values.

Use bigint for values that represent on-chain integers.

Explicit state transitions

A transaction should not be able to jump randomly between states.

For example:

CREATED
   ↓
QUEUED
   ↓
SIMULATING
   ↓
SUBMITTING
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED
   ↓
RECONCILED

Failure paths:

SUBMITTED
   ├── REVERTED
   ├── TIMED_OUT
   └── REPLACEMENT_PENDING
                    ↓
                REPLACED

Create a transition validator:

const allowedTransitions: Record<
  TransactionStatus,
  TransactionStatus[]
> = {
  CREATED: ["QUEUED", "FAILED"],
  QUEUED: ["SIMULATING", "FAILED"],
  SIMULATING: ["SUBMITTING", "FAILED"],
  SUBMITTING: ["SUBMITTED", "FAILED"],
  SUBMITTED: [
    "PENDING",
    "CONFIRMED",
    "REVERTED",
    "REPLACEMENT_PENDING",
    "TIMED_OUT",
    "RECONCILIATION_REQUIRED",
  ],
  PENDING: [
    "CONFIRMED",
    "REVERTED",
    "REPLACEMENT_PENDING",
    "TIMED_OUT",
    "RECONCILIATION_REQUIRED",
  ],
  CONFIRMED: ["RECONCILED"],
  RECONCILIATION_REQUIRED: ["RECONCILED", "FAILED"],
  REPLACEMENT_PENDING: [
    "REPLACED",
    "CONFIRMED",
    "REVERTED",
    "RECONCILIATION_REQUIRED",
  ],
  REPLACED: ["CONFIRMED", "RECONCILIATION_REQUIRED"],
  TIMED_OUT: ["REPLACEMENT_PENDING", "RECONCILIATION_REQUIRED"],
  RECONCILED: [],
  REVERTED: [],
  FAILED: [],
};

The exact state model can evolve, but the important part is that transitions are explicit and validated.

Nonce management

Nonce management becomes difficult as soon as multiple transactions use the same account.

Consider:

Strategy A ──┐
Strategy B ──┼──> Same wallet
Strategy C ──┘

If each service independently requests the pending nonce, they can race.

For example:

Request A → nonce 100
Request B → nonce 100

The transaction manager should allocate nonces centrally:

pending nonce = 100

Request A → 100
Request B → 101
Request C → 102

The allocation itself needs concurrency control.

Nonce manager API

A clean interface might look like:

export interface NonceManager {
  getNextNonce(
    account: `0x${string}`
  ): Promise<number>;

  allocateNonce(
    account: `0x${string}`
  ): Promise<number>;

  reconcileNonce(
    account: `0x${string}`
  ): Promise<void>;
}

The implementation should:

query chain state
establish the starting nonce
allocate locally
serialize concurrent allocation
periodically reconcile

The important rule is:

Never assume two concurrent calls will see different chain nonces.

The local allocator is what guarantees uniqueness inside the application.

Concurrent nonce allocation

This should be tested explicitly.

Pseudo-scenario:

const requests = Array.from(
  { length: 50 },
  () => nonceManager.allocateNonce(account)
);

const nonces = await Promise.all(requests);

The test should verify:

50 requests
      ↓
50 unique nonces

and not:

50 requests
      ↓
same nonce repeated

Do not make this reliable through arbitrary delays.

Use an actual mutex or serialized queue.

Keeping chain state and local state synchronized

Local nonce tracking can become stale.

For example:

Local state:
next nonce = 120

Blockchain:
nonce usage has moved forward

The transaction manager needs reconciliation logic.

A useful mental model is:

Blockchain
    ↑
    |
Local Nonce State
    ↑
    |
Transaction Records

The local state is an optimization and coordination mechanism.

The blockchain remains the source of truth.

Submission flow

A transaction submission should look like:

Transaction Request
        ↓
Validate
        ↓
Allocate Nonce
        ↓
Simulate
        ↓
Prepare Fees
        ↓
Submit
        ↓
Persist Hash
        ↓
Monitor

A simplified public API:

const result = await manager.submit({
  account,
  to,
  data,
  value,
});

Return a logical transaction ID as well as the initial transaction hash:

{
  transactionId,
  hash
}

This is important because one logical transaction may later have multiple attempts.

Simulation before submission

For contract calls, the manager can optionally simulate before sending.

The flow is:

Request
  ↓
Simulation
  |
  +-- fail → don't submit
  |
  +-- success
        ↓
      submit

With viem, the application can use simulation before writing when the request supports it.

The important limitation is:

Simulation is a check against one observed state, not a guarantee of future mining success.

The state can change between simulation and execution.

So simulation improves validation but does not replace monitoring and reconciliation.

Fee management

Transaction replacement depends on fee policy.

I keep fee logic separate:

export interface FeePolicy {
  getInitialFees(): Promise<{
    maxFeePerGas: bigint;
    maxPriorityFeePerGas: bigint;
  }>;

  getReplacementFees(
    previous: {
      maxFeePerGas: bigint;
      maxPriorityFeePerGas: bigint;
    },
    attempt: number
  ): {
    maxFeePerGas: bigint;
    maxPriorityFeePerGas: bigint;
  };
}

The replacement policy can then be configured with values such as:

replacementBumpPercent
minimumFeeBump
maxFeePerGasCap
maxPriorityFeePerGasCap

Avoid assuming one universal replacement percentage works across every EVM network.

Retry policy

Retries should be based on failure classification.

For example:

RPC timeout
      ↓
possibly retry

versus:

contract reverted
      ↓
do not blindly retry

A simple classification:

Retryable
---------
temporary RPC failure
transport failure
pending timeout

Not automatically retryable
---------------------------
contract revert
invalid calldata
authorization failure
insufficient funds

The final policy depends on the application.

The important engineering principle is that retry behavior must be intentional.

Replacement transactions

A stuck transaction may need a replacement.

Suppose:

nonce = 200
hash = 0xAAA
status = PENDING

The manager can submit:

nonce = 200
hash = 0xBBB
higher fee

The nonce must stay the same.

That gives:

nonce 200
   |
   +--> 0xAAA
   |
   +--> 0xBBB
   |
   +--> final result

The database should preserve the whole attempt history.

Attempt history

Instead of replacing one hash with another, keep each attempt.

For example:

transaction
-----------
id: tx-123
nonce: 200
currentHash: 0xCCC

attempts
--------
1 → 0xAAA
2 → 0xBBB
3 → 0xCCC

This is useful for debugging.

It also prevents the database from losing important historical information.

Detecting unknown nonce consumption

One subtle case is:

Original:
nonce = 200
hash = 0xAAA

Later:
account nonce advanced

That does not automatically prove:

0xAAA was replaced by 0xBBB

Another transaction may have used nonce 200.

The manager should therefore be conservative:

known replacement
      ↓
REPLACED

but:

unknown nonce consumption
      ↓
RECONCILIATION_REQUIRED

That prevents the application from creating false certainty.

Monitoring pending transactions

The monitor periodically checks active transactions:

+--------------------+
| Transaction Monitor|
+---------+----------+
          |
          +--> TX A
          +--> TX B
          +--> TX C
          +--> TX D

For each transaction:

receipt exists?
     |
     +-- no
     |    |
     |    +--> still pending
     |    +--> timeout policy
     |
     +-- yes
          |
          +--> success
          |
          +--> reverted

Use a configurable polling interval.

Avoid creating a permanent uncontrolled timer for every transaction.

Confirmation tracking

A transaction may be mined but still require additional confirmations.

For example:

Receipt
  ↓
1 confirmation
  ↓
2 confirmations
  ↓
3 confirmations
  ↓
Application accepts final state

Make the required confirmation count configurable.

Persist useful blockchain metadata:

blockNumber
blockHash
transactionIndex
confirmationCount

Reconciliation

Receipt monitoring answers:

Did the transaction get mined?

Reconciliation answers:

What actually happened?

The reconciler can inspect:

transaction
receipt
status
logs
nonce
block

and then update application state.

The lifecycle becomes:

SUBMITTED
    ↓
PENDING
    ↓
CONFIRMED
    ↓
RECONCILED

That last step is important for trading systems because the requested action and the actual blockchain result can differ.

Process restart

Consider:

09:31:00 transaction submitted
09:31:01 process crashes
09:31:03 transaction mined
09:31:10 service restarts

A memory-only application loses context.

A persistent transaction manager can recover:

SQLite
  ↓
find active transactions
  ↓
fetch blockchain state
  ↓
reconcile
  ↓
restore correct status

This is one of the main reasons I store transaction state rather than keeping it only in memory.

SQLite persistence

For a small reusable reference implementation, SQLite is enough.

The main table can contain:

transactions
------------
id
chain_id
account
nonce
to_address
data
value
current_hash
status
attempt_count
created_at
submitted_at
confirmed_at
reconciled_at
block_number
block_hash
error_code
error_message

A second table tracks attempts:

transaction_attempts
--------------------
id
transaction_id
hash
nonce
attempt_number
submitted_at
max_fee_per_gas
max_priority_fee_per_gas
status

Keep SQL inside a repository layer.

Do not spread SQL statements throughout the transaction manager.

Repository interface

For example:

export interface TransactionRepository {
  create(
    transaction: TransactionRecord
  ): Promise<void>;

  update(
    id: string,
    patch: Partial<TransactionRecord>
  ): Promise<void>;

  findById(
    id: string
  ): Promise<TransactionRecord | null>;

  findByHash(
    hash: `0x${string}`
  ): Promise<TransactionRecord | null>;

  findPending(): Promise<TransactionRecord[]>;

  findByAccountAndNonce(
    account: `0x${string}`,
    nonce: number
  ): Promise<TransactionRecord[]>;

  addAttempt(
    attempt: TransactionAttempt
  ): Promise<void>;
}

That allows the domain logic to remain independent of SQLite.

Error handling

Transaction infrastructure benefits from typed errors.

Examples:

NonceAllocationError
NonceMismatchError
SimulationError
SubmissionError
TransactionRevertedError
ReplacementError
ReconciliationError
ConfigurationError

Instead of:

catch (error) {
  throw new Error("something went wrong");
}

preserve useful information.

For example:

throw new SimulationError({
  transactionId,
  cause: error,
});

The application can then decide whether the error is retryable.

Security boundaries

The transaction manager should never become a secret-management system.

Do not:

store private keys in SQLite
log private keys
log seed phrases
include .env in Git
print credentials during debugging

The wallet/account layer should be injectable.

That makes local tests easier and avoids coupling the system to one key-management approach.

Testing strategy

I split testing into two layers.

Foundry
  ↓
Solidity / local contracts

Vitest
  ↓
TypeScript transaction infrastructure

That keeps the test responsibilities clear.

Unit tests

The TypeScript test suite should cover:

Nonce Manager
----------------
initial nonce
sequential allocation
concurrent allocation
reconciliation


State Machine
----------------
valid transition
invalid transition
terminal state


Retry Policy
----------------
retryable failure
non-retryable failure
maximum attempts


Replacement
----------------
same nonce
higher fee
attempt history


Persistence
----------------
create
update
reload
pending lookup
attempt lookup

Failure-path tests

The failure paths are particularly valuable.

Test:

RPC unavailable
RPC timeout
simulation revert
submission error
duplicate nonce
stale nonce
pending timeout
replacement
reverted receipt
missing receipt
process restart
unknown nonce consumption

A transaction manager that only tests:

send → success

does not demonstrate much about reliability.

Foundry integration contracts

For local integration testing, create simple contracts.

For example:

contract MockTarget {
    uint256 public executions;

    function execute() external {
        executions++;
    }
}

And a reverting contract:

contract MockRevertingTarget {
    function execute() external pure {
        revert("MOCK_REVERT");
    }
}

These give the TypeScript integration suite deterministic targets.

End-to-end flow

A complete successful test should look like:

Application
    ↓
Transaction Manager
    ↓
Nonce Allocation
    ↓
Simulation
    ↓
Transaction Submission
    ↓
Transaction Hash
    ↓
Persistence
    ↓
Receipt Monitoring
    ↓
Confirmation
    ↓
Reconciliation
    ↓
RECONCILED

And the failure path:

Application
    ↓
Transaction Manager
    ↓
Submission
    ↓
PENDING
    ↓
Receipt
    ↓
REVERTED

No blind retry.

Using the manager from a trading system

The advantage of this architecture is that the strategy code stays simple.

A Pons strategy could produce:

const request = buildTradeRequest(signal);

An arbitrage strategy could produce:

const request = buildArbitrageRequest(opportunity);

A copy-trading strategy could produce:

const request = buildCopyTradeRequest(trade);

All three can submit through the same transaction manager:

const result = await transactionManager.submit(request);

The infrastructure is reusable.

Example application architecture

A larger trading product can look like:

+-----------------------+
| Trading UI            |
+-----------+-----------+
            |
            v
+-----------------------+
| API                   |
+-----------+-----------+
            |
            v
+-----------------------+
| Strategy / Risk       |
+-----------+-----------+
            |
            v
+-----------------------+
| EVM Transaction       |
| Manager               |
+-----------+-----------+
            |
            v
+-----------------------+
| Blockchain            |
+-----------+-----------+
            |
            v
+-----------------------+
| Indexer / Reconciler  |
+-----------------------+

This is the architecture I prefer over putting transaction logic directly inside every strategy.

Why this matters for Pons and Stock Token systems

The transaction manager does not need to understand one specific protocol.

That is a feature.

For example:

Pons Bot
    |
    v
Execution Request
    |
    v
EVM Transaction Manager
    |
    v
Robinhood Chain

Or:

Stock Token Strategy
    |
    v
Execution Request
    |
    v
EVM Transaction Manager
    |
    v
EVM Protocol

Or:

Arbitrage Strategy
    |
    v
Execution Request
    |
    v
EVM Transaction Manager

The same lifecycle infrastructure can serve all three.

What I am trying to prove

This repository is not primarily about sending an EVM transaction.

It demonstrates the engineering around that transaction:

Solidity / EVM
      +
TypeScript
      +
Nonce Management
      +
Persistence
      +
Retries
      +
Replacement
      +
Receipt Monitoring
      +
Reconciliation
      +
Failure Handling

That is the part of automated trading infrastructure that often determines whether a prototype can evolve into a usable application.

Repository

The project is:

evm-transaction-manager

The repository is intended as a reusable reference implementation rather than a claim of audited or production-certified infrastructure.

The README documents:

architecture
state transitions
nonce management
replacement logic
reconciliation
local setup
testing
failure scenarios

The code is designed so another EVM application can use the transaction manager without embedding transaction lifecycle logic inside its trading strategy.

Final architecture

                 Trading Strategy
                       |
                       v
                 Risk / Validation
                       |
                       v
             +----------------------+
             | EVM Transaction      |
             | Manager              |
             +----------------------+
             | Nonce Management     |
             | Persistence          |
             | Simulation           |
             | Submission           |
             | Monitoring           |
             | Retry Policy         |
             | Replacement          |
             | Reconciliation       |
             +----------+-----------+
                        |
                        v
                     EVM RPC
                        |
                        v
                   Blockchain
                        |
                        v
                Receipt / Events
                        |
                        v
                 Reconciliation
                        |
                        v
                Position / PnL

The strategy determines what transaction should be attempted.

The transaction manager determines how that transaction is submitted, tracked, recovered, and reconciled.

That separation is the foundation for building reliable automated EVM trading systems.

Building a Solidity Trading Executor with Foundry and TypeScript

hamssog — Fri, 02 Oct 2026 06:48:18 +0000

Most trading bot examples stop at the strategy layer:

Price update
   ↓
Signal
   ↓
Buy / Sell

That is enough to demonstrate an idea.

It is not enough to build reusable trading infrastructure.

Once a strategy starts executing real transactions, the system needs to deal with authorization, approved contracts, slippage, deadlines, transaction state, events, failed execution, and reconciliation.

For this project, I am building a reusable EVM Trading Executor with:

Solidity
Foundry
TypeScript
EVM-compatible protocols

The executor is designed to sit underneath different applications rather than being tied to one trading strategy.

Strategy
   ↓
Risk Checks
   ↓
Execution Request
   ↓
Solidity Trading Executor
   ↓
Protocol
   ↓
On-chain Result
   ↓
Events
   ↓
Reconciliation

Why build an execution layer?

A strategy answers:

Should I trade?

An execution system answers:

Can I execute that trade under the required constraints?

Those are different responsibilities.

For example, a strategy may produce:

tokenIn
tokenOut
amountIn
minimumAmountOut
deadline
router

The execution layer should validate those parameters before interacting with an external contract.

That gives the system a clear boundary:

+----------------------+
| Strategy             |
|                      |
| Signal / Opportunity |
+----------+-----------+
           |
           v
+----------------------+
| Trading Executor     |
|                      |
| Validation           |
| Security             |
| Execution            |
+----------+-----------+
           |
           v
+----------------------+
| EVM Protocol         |
+----------------------+

Project structure

A simple project structure can look like:

evm-trading-executor/
├── src/
│   ├── TradingExecutor.sol
│   ├── interfaces/
│   │   └── ITradingExecutor.sol
│   └── libraries/
├── test/
│   ├── TradingExecutor.t.sol
│   ├── TradingExecutorFuzz.t.sol
│   └── TradingExecutorInvariant.t.sol
├── script/
│   └── Deploy.s.sol
├── lib/
├── foundry.toml
└── ts/
    ├── executor.ts
    └── types.ts

The Solidity side owns the execution rules.

The TypeScript side handles application-level orchestration.

The Solidity executor

The first version should keep the core interface small.

interface ITradingExecutor {
    function executeTrade(
        address router,
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 amountOutMinimum,
        uint256 deadline
    ) external returns (uint256 amountOut);
}

The important part is the separation of responsibilities.

The executor receives a trade request.

It does not need to know why the strategy generated it.

Access control

The executor should not allow arbitrary addresses to submit trades.

A basic implementation can use an executor role:

bytes32 public constant EXECUTOR_ROLE =
    keccak256("EXECUTOR_ROLE");

Then the execution function can enforce the role:

function executeTrade(
    address router,
    address tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOutMinimum,
    uint256 deadline
) external onlyRole(EXECUTOR_ROLE) returns (uint256 amountOut) {
    // validation and execution
}

This creates an explicit trust boundary.

A production architecture can separate:

Admin
 ├── configuration
 └── role management

Executor
 └── trade execution

Emergency Operator
 └── pause / recovery

Keeping these responsibilities separate makes the system easier to operate.

Token allowlists

A reusable executor should not blindly interact with arbitrary tokens.

A simple allowlist is:

mapping(address => bool) public allowedTokens;

Then validate both sides of a trade:

require(
    allowedTokens[tokenIn],
    "TOKEN_IN_NOT_ALLOWED"
);

require(
    allowedTokens[tokenOut],
    "TOKEN_OUT_NOT_ALLOWED"
);

This is a small feature with an important purpose.

If a configuration error or compromised service generates an unexpected token address, the executor can reject the request.

Router allowlists

The same approach applies to protocol routers.

mapping(address => bool) public allowedRouters;

Before execution:

require(
    allowedRouters[router],
    "ROUTER_NOT_ALLOWED"
);

Instead of:

execute arbitrary target

the architecture becomes:

Executor
   ↓
Approved Router
   ↓
Approved Protocol

That is much easier to reason about from a security perspective.

Slippage protection

Automated trading should not assume that a quote remains valid indefinitely.

A trade request should include a minimum acceptable output:

uint256 amountOutMinimum;

The executor can then pass the constraint into the underlying protocol.

Conceptually:

Expected output:     100 tokens
Minimum accepted:    98 tokens
Actual output:      101 tokens

The trade can proceed.

But:

Expected output:     100 tokens
Minimum accepted:    98 tokens
Actual output:       94 tokens

should fail.

This is one of the most important differences between a trading executor and a simple transaction sender.

Deadline protection

Execution parameters can also become stale.

The executor should therefore validate the deadline:

require(
    block.timestamp <= deadline,
    "DEADLINE_EXPIRED"
);

This makes time part of the execution contract.

An old request should not remain valid forever.

Validation before external calls

I prefer validating everything possible before making an external call.

A simplified execution flow is:

1. Check caller
2. Check amount
3. Check token allowlist
4. Check router allowlist
5. Check deadline
6. Prepare execution
7. Call protocol
8. Emit event

This has two advantages:

First, invalid requests fail early.

Second, the external protocol is only called after the executor has verified its own rules.

Events

The execution contract should provide a useful event stream.

For example:

event TradeExecuted(
    address indexed executor,
    address indexed router,
    address indexed tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOut
);

The off-chain system can consume this event and update application state.

Solidity Executor
      ↓
TradeExecuted
      ↓
  Indexer
      ↓
Position Engine
      ↓
     PnL
      ↓
Dashboard / Alerts

This is much cleaner than trying to reconstruct every execution entirely from application logs.

TypeScript execution layer

The TypeScript service sits above the contract.

Its job is to prepare and submit execution requests.

A simplified structure is:

type TradeRequest = {
  router: `0x${string}`;
  tokenIn: `0x${string}`;
  tokenOut: `0x${string}`;
  amountIn: bigint;
  amountOutMinimum: bigint;
  deadline: bigint;
};

The service can then construct the transaction:

const hash = await walletClient.writeContract({
  address: executorAddress,
  abi: executorAbi,
  functionName: "executeTrade",
  args: [
    request.router,
    request.tokenIn,
    request.tokenOut,
    request.amountIn,
    request.amountOutMinimum,
    request.deadline,
  ],
});

The exact client library can vary.

The important architecture is:

TypeScript
   ↓
Build execution request
   ↓
Validate application state
   ↓
Call Solidity executor
   ↓
Monitor transaction

Type safety matters

Trading systems move a lot of numeric values:

amountIn
amountOut
price
slippage
gas
fees
balances
reserves

Using JavaScript floating-point numbers for on-chain amounts is dangerous.

I keep token amounts in integer form:

const amountIn = 1000000000000000000n;

and convert only at presentation boundaries.

That keeps calculations aligned with EVM integer arithmetic.

Transaction state

Calling:

writeContract(...)

does not mean the trade is completed.

A useful state machine is:

READY
  ↓
SUBMITTED
  ↓
CONFIRMED
  ↓
RECONCILED

With failure paths:

SUBMITTED
   ├── REVERTED
   ├── DROPPED
   ├── REPLACED
   └── CONFIRMED

The application should distinguish these states.

For example:

transaction submitted

is not equivalent to:

position updated

The latter requires reconciliation with on-chain state.

Reconciliation

After a transaction is confirmed, the off-chain application should verify what actually happened.

A simplified process:

Transaction receipt
       ↓
Execution event
       ↓
Actual token amounts
       ↓
Position update
       ↓
PnL update

This matters particularly for partial fills, refunds, fee deductions, or protocol-specific execution behavior.

A reliable system should use actual on-chain results rather than trusting only the parameters that were originally requested.

Foundry tests

The contract layer needs more than one successful test.

My testing structure is:

Tests
├── Unit
├── Fuzz
├── Invariant
└── Fork

Unit testing

Start with deterministic behavior.

For example:

function test_RejectsUnauthorizedCaller() public {
    vm.prank(attacker);

    vm.expectRevert();
    executor.executeTrade(
        router,
        tokenIn,
        tokenOut,
        amountIn,
        minimumOut,
        deadline
    );
}

Other unit tests should cover:

authorized execution
blocked token
blocked router
expired deadline
invalid amount
successful execution
reverted execution

Fuzz testing

Trading values have a huge input space.

Fuzz testing allows Foundry to generate different values automatically.

For example:

function testFuzz_AmountValidation(
    uint256 amountIn
) public {
    // validate execution behavior
}

This helps find edge cases around:

zero values
very large amounts
boundary conditions
unexpected combinations of parameters

Invariant testing

Some properties should always remain true.

For example:

Unauthorized accounts cannot execute trades.

Another:

Blocked routers cannot be used.

And:

Expired execution requests cannot execute.

These properties are stronger than testing one specific transaction.

They define the rules the executor is supposed to preserve across many state transitions.

Fork testing

Mocks are useful for isolated contract tests.

Fork tests provide another layer.

The idea is:

Real EVM state
      ↓
   Fork
      ↓
Trading Executor
      ↓
Real protocol contracts

This helps expose integration problems that do not appear in fully mocked environments.

For a trading system, integration behavior is critical.

Protocol adapters

One executor may eventually need to support multiple protocols.

I prefer keeping protocol-specific code separate.

                 Trading Executor
                        |
        +---------------+---------------+
        |               |               |
        v               v               v
     Adapter A       Adapter B       Adapter C
        |               |               |
        v               v               v
     Protocol A      Protocol B      Protocol C

The executor owns shared rules such as:

authorization
allowlists
slippage
deadlines
events

The adapter owns protocol-specific behavior.

That keeps the core contract from becoming one enormous protocol-specific implementation.

Where the executor fits in a real trading system

The smart contract is only one layer.

A larger application might look like:

+---------------------------+
| Frontend / Trading UI     |
+-------------+-------------+
              |
              v
+---------------------------+
| API / Trading Service     |
+-------------+-------------+
              |
              v
+---------------------------+
| Strategy + Risk Engine    |
+-------------+-------------+
              |
              v
+---------------------------+
| Transaction Manager       |
+-------------+-------------+
              |
              v
+---------------------------+
| Solidity Trading Executor |
+-------------+-------------+
              |
              v
+---------------------------+
| EVM Protocol              |
+---------------------------+
              |
              v
+---------------------------+
| Indexer / Reconciliation  |
+---------------------------+

Each layer has a different responsibility.

That separation makes debugging much easier.

Reusing the same infrastructure

Once the execution layer is isolated, different applications can use it.

For example:

                    EVM Trading Executor
                            |
        +-------------------+-------------------+
        |                   |                   |
        v                   v                   v
   Sniper Bot         Copy Trading         Arbitrage
        |                   |                   |
        +-------------------+-------------------+
                            |
                            v
                      EVM Execution

This is useful because the strategy can evolve without rewriting the fundamental execution controls.

The same pattern can also support:

Pons trading systems
Stock Token applications
automated arbitrage
copy trading
trading terminals
custom EVM products

What I am actually proving with this project

The main purpose of this repository is not to show that I can write:

contract TradingExecutor {}

The goal is to demonstrate the complete engineering boundary around execution.

That means:

Solidity
+
EVM architecture
+
TypeScript integration
+
Access control
+
Protocol validation
+
Slippage protection
+
Transaction lifecycle
+
Event design
+
Foundry testing
+
Reconciliation

That is the infrastructure I would reuse when turning a trading idea into an actual application.

GitHub

The project is being developed as:

evm-trading-executor

Recommended repository layout:

src/
test/
script/
ts/
foundry.toml
README.md

The README should include:

Architecture
Installation
Environment variables
Deployment
Contract interface
TypeScript usage
Testing
Fork testing
Failure handling

A repository is much more useful to a potential client when it explains both what was built and how the system is intended to be extended.

Final architecture

The complete flow is:

Market / On-chain Data
          ↓
       Strategy
          ↓
      Risk Checks
          ↓
   Execution Request
          ↓
+-----------------------+
| Solidity Executor     |
|                       |
| Access Control        |
| Allowlists            |
| Slippage              |
| Deadline              |
| Validation            |
| Execution             |
| Events                |
+-----------+-----------+
            |
            v
      EVM Protocol
            |
            v
     Transaction Result
            |
            v
       Reconciliation
            |
            v
     Position / PnL State

The strategy decides what should happen.

The execution layer makes sure the requested action follows the application's rules.

That distinction is the foundation I use when building reusable EVM trading infrastructure.

Next extensions

The next iterations can add:

Protocol adapters
Nonce management
Gas policies
Pause / emergency controls
Multi-wallet execution
Execution simulation
MEV-aware routing
Advanced monitoring

The same executor architecture can then become part of a larger custom trading product rather than remaining an isolated Solidity demo.

Testing Solidity Trading Contracts with Foundry: Unit, Fork, and Failure-Path Testing

hamssog — Thu, 01 Oct 2026 06:59:56 +0000

A Solidity contract can compile successfully and still be the wrong contract to put behind a trading system.

For trading infrastructure, I care about a different question:

What happens when execution goes wrong?

A useful test suite should prove more than this:

valid input
    ↓
trade succeeds

It should also prove:

unauthorized caller
    ↓
revert

unsupported router
    ↓
revert

invalid token
    ↓
revert

bad slippage
    ↓
revert

expired transaction
    ↓
revert

external protocol failure
    ↓
revert

valid transaction
    ↓
execute
    ↓
emit event
    ↓
backend reconciles

That is the approach I use when thinking about Solidity and EVM engineering for trading systems.

Robinhood Chain is EVM-compatible, so standard Solidity development and Foundry testing workflows apply to contracts deployed there. The official Robinhood Chain documentation also recommends testing on testnet before deploying to mainnet.

Why testing matters more for trading contracts

A normal application can sometimes recover from a bug with a new deployment.

A smart contract may control assets directly.

That changes the engineering priorities.

For a trading contract, I want explicit guarantees around:

Access
Authorization
Assets
Routers
Amounts
Slippage
Deadlines
State
Events
External Calls

The contract should fail predictably when an assumption is violated.

The test suite should prove those assumptions.

The testing pyramid

I generally think about contract testing in layers:

                 Production
                     ↑
                  Testnet
                     ↑
                 Fork Tests
                     ↑
              Integration Tests
                     ↑
            Invariant / Fuzz Tests
                     ↑
                  Unit Tests

Each layer answers a different question.

Unit tests

Does the contract behave correctly for a known case?

Fuzz tests

Does it behave correctly across many unexpected inputs?

Invariant tests

Does an important property remain true after many actions?

Integration tests

Does the contract interact correctly with the surrounding protocol?

Fork tests

Does it behave correctly against realistic chain state?

Testnet

Does the deployed artifact behave correctly in a real network environment?

Example: a trading executor

Consider a simplified execution contract:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IERC20 {
    function approve(
        address spender,
        uint256 amount
    ) external returns (bool);

    function balanceOf(
        address account
    ) external view returns (uint256);
}

interface IRouter {
    function swap(
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 minAmountOut,
        address recipient
    ) external returns (uint256 amountOut);
}

contract TradingExecutor {
    address public immutable owner;

    mapping(address => bool) public allowedRouter;
    mapping(address => bool) public allowedToken;

    bool public paused;

    error Unauthorized();
    error Paused();
    error RouterNotAllowed();
    error TokenNotAllowed();
    error InvalidAmount();
    error SlippageExceeded();
    error DeadlineExpired();

    event RouterUpdated(
        address indexed router,
        bool allowed
    );

    event TokenUpdated(
        address indexed token,
        bool allowed
    );

    event TradeExecuted(
        bytes32 indexed operationId,
        address indexed router,
        address indexed tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 amountOut
    );

    constructor(address initialOwner) {
        owner = initialOwner;
    }

    modifier onlyOwner() {
        if (msg.sender != owner) {
            revert Unauthorized();
        }

        _;
    }

    function setRouter(
        address router,
        bool allowed
    ) external onlyOwner {
        allowedRouter[router] = allowed;

        emit RouterUpdated(
            router,
            allowed
        );
    }

    function setToken(
        address token,
        bool allowed
    ) external onlyOwner {
        allowedToken[token] = allowed;

        emit TokenUpdated(
            token,
            allowed
        );
    }

    function executeTrade(
        bytes32 operationId,
        address router,
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 minAmountOut,
        uint256 deadline,
        address recipient
    ) external onlyOwner returns (uint256 amountOut) {
        if (paused) {
            revert Paused();
        }

        if (!allowedRouter[router]) {
            revert RouterNotAllowed();
        }

        if (!allowedToken[tokenIn]) {
            revert TokenNotAllowed();
        }

        if (!allowedToken[tokenOut]) {
            revert TokenNotAllowed();
        }

        if (amountIn == 0) {
            revert InvalidAmount();
        }

        if (block.timestamp > deadline) {
            revert DeadlineExpired();
        }

        amountOut = IRouter(router).swap(
            tokenIn,
            tokenOut,
            amountIn,
            minAmountOut,
            recipient
        );

        if (amountOut < minAmountOut) {
            revert SlippageExceeded();
        }

        emit TradeExecuted(
            operationId,
            router,
            tokenIn,
            tokenOut,
            amountIn,
            amountOut
        );
    }
}

This is intentionally simplified.

The important part is the number of assumptions it exposes.

That gives us something concrete to test.

1. Test the happy path

The first test should prove that the intended operation works.

function testExecuteTrade() public {
    mockRouter.setAmountOut(100 ether);

    vm.prank(owner);

    uint256 amountOut = executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );

    assertEq(amountOut, 100 ether);
}

This proves:

authorized caller
+
allowed router
+
allowed tokens
+
valid amount
+
valid deadline
+
acceptable output
=
successful execution

But that is only one path.

2. Unauthorized caller

The next test should prove that another address cannot execute the contract.

function testRejectsUnauthorizedCaller() public {
    vm.prank(attacker);

    vm.expectRevert(
        TradingExecutor.Unauthorized.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

The property is simple:

attacker
   ↓
executeTrade()
   ↓
REVERT

This is one of the first tests I would expect to see in a serious trading contract.

3. Wrong router

The execution contract should not call arbitrary addresses.

function testRejectsUnknownRouter() public {
    address unknownRouter =
        address(0x1234);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.RouterNotAllowed.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        unknownRouter,
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

Now the contract guarantees:

configured router
    ↓
allowed

unknown router
    ↓
rejected

That is a much stronger security boundary than relying on the frontend to select the correct router.

4. Unsupported token

Do the same for assets.

function testRejectsUnsupportedToken() public {
    address unsupportedToken =
        address(0x5678);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.TokenNotAllowed.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        unsupportedToken,
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

This protects against accidental or malicious execution using an unexpected asset.

5. Zero amount

Never assume callers will provide sensible amounts.

function testRejectsZeroAmount() public {
    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.InvalidAmount.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        0,
        0,
        block.timestamp + 60,
        recipient
    );
}

This looks trivial.

It is still worth testing explicitly.

The goal is to make the contract's assumptions visible.

6. Slippage failure

Trading systems need an execution boundary.

Suppose the application expects:

Expected output: 100
Minimum output: 95
Actual output:   90

The trade must fail.

function testRejectsBadSlippage() public {
    mockRouter.setAmountOut(90 ether);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.SlippageExceeded.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

The property is:

amountOut < minAmountOut
        ↓
REVERT

This is far more meaningful than simply testing:

swap works

7. Deadline failure

A quote can become stale.

So test expired execution:

function testRejectsExpiredTrade() public {
    uint256 deadline =
        block.timestamp + 10;

    vm.warp(block.timestamp + 11);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.DeadlineExpired.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        deadline,
        recipient
    );
}

Foundry's cheatcodes make time-dependent testing deterministic.

The test does not need to wait eleven real seconds.

8. Paused execution

If the contract has an emergency control, test it.

function testRejectsPausedExecution() public {
    vm.prank(owner);

    executor.setPaused(true);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.Paused.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

The desired property is:

paused = true
      ↓
no new execution

An emergency control that isn't tested is not much of an emergency control.

9. Event testing

A contract should make important state transitions observable.

For example:

event TradeExecuted(
    bytes32 indexed operationId,
    address indexed router,
    address indexed tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOut
);

Then test the event directly:

function testEmitsTradeExecuted() public {
    mockRouter.setAmountOut(100 ether);

    vm.expectEmit(
        true,
        true,
        true,
        true
    );

    emit TradeExecuted(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        100 ether
    );

    vm.prank(owner);

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

This matters because the backend may depend on this event.

The architecture becomes:

Solidity
   ↓
TradeExecuted
   ↓
viem
   ↓
TypeScript
   ↓
Trade State

10. Fuzz testing

Fixed test values cover known cases.

Fuzzing explores a much larger input space.

For example:

function testFuzzRejectsZeroAmount(
    uint256 amountIn
) public {
    vm.assume(amountIn == 0);

    vm.prank(owner);

    vm.expectRevert(
        TradingExecutor.InvalidAmount.selector
    );

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        amountIn,
        0,
        block.timestamp + 60,
        recipient
    );
}

The useful part of fuzzing is not merely generating random numbers.

It is expressing a property:

for every input satisfying condition X,
property Y must remain true

For trading contracts, useful fuzzing targets include:

amounts
minimum outputs
deadlines
addresses
limits
configuration boundaries

Foundry provides fuzz testing as part of its Solidity testing workflow.

11. Invariant testing

Fuzzing tests inputs.

Invariant testing tests system properties across sequences of actions.

For example:

paused
   ↓
no trade execution

or:

unauthorized user
   ↓
cannot modify router configuration

or:

unsupported router
   ↓
never becomes executable

These are stronger than a single test case because they describe what should always remain true.

For trading infrastructure, I would define invariants before writing a large amount of contract code.

12. Integration testing

Mocks are useful.

They are not enough.

Suppose the executor calls:

Router
   ↓
Token
   ↓
Trade

A perfect mock may hide:

allowance problems
different revert behavior
unexpected return data
event differences
real token decimals

Integration tests should therefore validate contract boundaries.

For example:

TradingExecutor
      ↓
Router Mock
      ↓
ERC-20 Mock
      ↓
Assertions

The test should prove the contracts behave correctly together.

13. External protocol failures

One of the most important tests is:

Your contract
      ↓
External protocol
      ↓
REVERT

The expected result is:

external failure
      ↓
transaction reverts
      ↓
no partial state

A mock router can simulate this.

function testProtocolFailureReverts() public {
    mockRouter.setShouldRevert(true);

    vm.prank(owner);

    vm.expectRevert();

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );
}

This is one of the first failure paths I would add to a trading contract.

14. State rollback

Suppose a transaction performs several operations:

update state
   ↓
transfer
   ↓
external call
   ↓
failure

Ethereum transaction atomicity means a reverted transaction should not leave those earlier state changes committed.

A useful test should verify the state before and after.

function testFailedExecutionDoesNotChangeState() public {
    uint256 beforeValue =
        executor.someState();

    mockRouter.setShouldRevert(true);

    vm.prank(owner);

    vm.expectRevert();

    executor.executeTrade(
        OPERATION_ID,
        address(mockRouter),
        address(tokenIn),
        address(tokenOut),
        100 ether,
        95 ether,
        block.timestamp + 60,
        recipient
    );

    uint256 afterValue =
        executor.someState();

    assertEq(
        afterValue,
        beforeValue
    );
}

This verifies a property rather than only checking the revert itself.

15. Fork testing

This is where the test becomes much more realistic.

Instead of:

Your Contract
   ↓
Mock Protocol

the environment becomes:

Robinhood Chain State
       ↓
Fork
       ↓
Your Contract
       ↓
Real Protocol Contracts

Foundry supports fork testing against live chain state.

This is useful for testing:

real token behavior
real router behavior
real balances
real allowances
real contract state
real event behavior

without sending a production transaction.

16. Fork testing a trading path

A simplified example:

function testForkedExecution() public {
    vm.createSelectFork(
        vm.envString("RH_RPC_URL")
    );

    // Load actual deployed contracts.
    // Configure test accounts.
    // Provide test balances.
    // Execute the real protocol path.
    // Verify balances and events.
}

The RPC URL should come from environment configuration:

RH_RPC_URL=...

Never commit:

private keys
API keys
RPC credentials

to the repository.

Robinhood's current deployment guidance also explicitly warns against committing real private keys and recommends testnet-first deployment.

17. Pons integration testing

The same methodology applies to Pons.

Pons V2 has a distinct bonding-curve lifecycle:

Launch
   ↓
Curve
   ↓
Trading
   ↓
Graduation
   ↓
Uniswap V4

Its documented event model includes launch and curve-trading events that can be used for integration and indexing workflows.

A Pons integration test should therefore validate:

launch detection
curve state
quote inputs
trade event
actual tokens out
market transition
graduation state

The test should use the current verified ABI, not a hand-created approximation.

18. Testing the scanner and contract together

This is where the smart-contract and TypeScript layers connect.

A complete test might look like:

Pons Contract
      ↓
Event
      ↓
TypeScript Decoder
      ↓
Normalized Trade
      ↓
Database
      ↓
Position

For example:

CurveBuy
   ↓
decode
   ↓
quoteIn
tokensOut
fee
tax
   ↓
Trade Record

That prevents a common mistake:

requested amount
≠
actual execution amount

The backend should consume the actual onchain result.

19. Transaction-state testing

A trading system also needs tests outside Solidity.

For example:

CREATED
   ↓
SIGNED
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED

and:

SUBMITTED
   ↓
RPC TIMEOUT
   ↓
UNKNOWN
   ↓
RECONCILIATION

The important test is:

RPC timeout
   ↓
do NOT blindly submit another transaction

Instead:

lookup transaction
   ↓
check receipt
   ↓
check events
   ↓
update state

This is where EVM testing becomes trading-infrastructure testing.

20. Idempotency testing

Suppose the same event is delivered twice:

TradeExecuted
TradeExecuted

The database should still contain one logical event.

A good test is:

process event
   ↓
process same event again
   ↓
no duplicate record

Use:

chainId
+
transactionHash
+
logIndex

as the event identity.

This is especially important for applications that use:

WebSocket listeners
backfills
RPC retries
reconnects

21. Testing the reconciliation layer

Suppose the application believes:

BUY 100

but the onchain event says:

tokensOut = 63

The reconciliation test should prove that the final position is:

not:

The complete flow becomes:

Transaction
    ↓
Receipt
    ↓
Events
    ↓
Actual Fill
    ↓
Position
    ↓
Database Reconciliation

This is one of the strongest places to demonstrate that the project understands real trading infrastructure.

22. A practical test matrix

For a trading executor, I would start with:

Area	Test
Authorization	Valid caller
Authorization	Invalid caller
Router	Allowed router
Router	Unknown router
Token	Allowed token
Token	Unknown token
Amount	Zero amount
Slippage	Valid output
Slippage	Output below minimum
Deadline	Valid deadline
Deadline	Expired deadline
Pause	Trading enabled
Pause	Trading paused
Protocol	Successful call
Protocol	Reverted call
Events	Correct event
State	No partial state
Fuzzing	Random boundary inputs
Invariants	Security properties
Fork	Real protocol state
Integration	TypeScript decoding
Reconciliation	Correct final position

That test matrix tells a much more convincing story than simply saying:

"The contract has tests."

23. Recommended Foundry project structure

For a contract project:

contracts/
├── src/
│   ├── executors/
│   ├── adapters/
│   ├── interfaces/
│   └── libraries/
│
├── test/
│   ├── unit/
│   ├── fuzz/
│   ├── invariant/
│   ├── integration/
│   └── fork/
│
├── script/
│   └── Deploy.s.sol
│
└── foundry.toml

Then keep the TypeScript application separately:

src/
├── strategy/
├── risk/
├── execution/
├── monitoring/
├── portfolio/
└── reconciliation/

The architecture becomes:

Solidity
   ↓
  EVM
   ↓
Robinhood Chain
   ↓
TypeScript
   ↓
Trading Infrastructure

24. What I want the test suite to prove

A strong repository should make these properties obvious:

Only authorized accounts can execute.

Unsupported routers are rejected.

Unsupported tokens are rejected.

Invalid amounts are rejected.

Bad slippage is rejected.

Expired transactions are rejected.

Paused execution is blocked.

External failures revert cleanly.

Important state transitions emit events.

Events can be decoded reliably.

Duplicate events do not create duplicate state.

Actual execution results become the canonical position state.

Those are engineering properties.

They are much more valuable than a list of technologies.

25. From contract testing to client work

This is also why I am adding Solidity/EVM work to my Robinhood Chain development portfolio.

A client may need only:

Solidity contract

Another may need:

Solidity
+
TypeScript
+
EVM integration

Another may need:

Smart Contract
+
Trading Engine
+
Risk
+
Wallets
+
Database
+
Dashboard

The testing approach scales with the product.

26. Public implementation direction

My current Robinhood Chain work already covers the application side:

Pons Sniper Bot

Pons Bundler

Pons Token Scanner

Pons Trading Terminal

Stock Token Trading Bot

Stock Token Arbitrage Bot

The Solidity/EVM layer adds another dimension:

Smart Contracts
       ↓
Protocol Integration
       ↓
Trading Engine
       ↓
Execution
       ↓
Reconciliation

That makes the portfolio demonstrate more than frontend or TypeScript development.

Final Thoughts

For a trading contract, the most useful question isn't:

"Does the swap work?"

It is:

Can the wrong person execute it?

Can the wrong asset be used?

Can the wrong router be called?

What happens when the output is too low?

What happens when the transaction expires?

What happens when the external protocol reverts?

What happens when the RPC disappears?

What does the backend record?

What is the actual position afterward?

That is why I treat testing as part of the architecture.

The workflow is:

Solidity
   ↓
Unit Tests
   ↓
Fuzz / Invariants
   ↓
Integration
   ↓
Fork
   ↓
TypeScript
   ↓
Testnet
   ↓
Production

The objective is not simply to make a contract compile.

The objective is to make the contract, EVM integration, trading engine, and state-management system behave predictably under both normal and failure conditions.

That is the level of engineering I am targeting with my Robinhood Chain and Pons work.

Need Solidity / EVM trading infrastructure?

I build Solidity contracts, EVM integrations, trading executors, Pons integrations, Stock Token systems, TypeScript trading engines, and full-stack trading applications, with testing and failure handling designed into the development process.

Building a Pons Token Scanner on Robinhood Chain with TypeScript

hamssog — Wed, 30 Sep 2026 12:35:17 +0000

A token scanner is often treated as a simple script:

listen for new token
→ print address

That is enough for a demo.

It is not enough for a useful trading product.

A production Pons Token Scanner needs to turn raw blockchain activity into structured state that other systems can consume:

Robinhood Chain
      ↓
Pons Events
      ↓
Event Decoder
      ↓
Token Registry
      ↓
 Market State
      ↓
   Filters
      ↓
Opportunity State
      ↓
API / Alerts / Dashboard
      ↓
Sniper / Trading Bot

The important architectural distinction is:

The scanner discovers and understands what happened. The trading bot decides what to do.

That makes the scanner useful on its own and reusable as the data layer underneath other trading products.

Why build the scanner onchain?

The current Pons V2 documentation explicitly describes factory and curve events as the integration source of truth: indexing the factory gives you launches, while indexing each curve gives you the launch's trading history. It states that this is enough to reconstruct protocol state without depending on a Pons service.

That gives us:

Pons Contracts
      ↓
   Events
      ↓
Own Indexer
      ↓
Own Database

Instead of:

   Pons UI
      ↓
Third-Party API
      ↓ 
   Scanner

Building the indexer yourself gives control over:

data model
filtering
historical backfill
latency
alerts
APIs
downstream automation

Robinhood Chain connection

Robinhood Chain is an EVM-compatible Arbitrum Layer-2 on Ethereum. Mainnet currently uses chain ID 4663 and ETH as the native gas token. The official deployment documentation supports standard Solidity tooling and EVM libraries.

For a TypeScript scanner, a familiar stack works:

TypeScript
    ↓
  viem
    ↓
   RPC
    ↓
Robinhood Chain
    ↓
Pons Contracts

A basic client can look like:

import {
  createPublicClient,
  http,
} from "viem";

const robinhoodChain = {
  id: 4663,
  name: "Robinhood Chain",
  nativeCurrency: {
    name: "Ether",
    symbol: "ETH",
    decimals: 18,
  },
  rpcUrls: {
    default: {
      http: ["https://rpc.mainnet.chain.robinhood.com"],
    },
  },
};

const client = createPublicClient({
  chain: robinhoodChain,
  transport: http(),
});

For production infrastructure, Robinhood currently recommends using a dedicated infrastructure provider such as Alchemy rather than relying on the public RPC endpoint for everything.

Step 1: Separate Pons V1 and V2

A scanner should be version-aware from the beginning.

Pons V2 has a bonding-curve lifecycle:

Create
  ↓
Trade Curve
  ↓
Graduate
  ↓
Uniswap V4 Pool

The current V2 documentation describes the curve as the initial trading venue, with graduation occurring when the curve is bought out and the resulting liquidity moving into a permanently locked Uniswap V4 pool.

That is different from the earlier Pons launch architecture.

So I would structure the scanner like:

Pons Scanner
     ↓
Protocol Adapter
     ├── V1
     └── V2

The rest of the application should consume a normalized internal representation.

Step 2: Detect Pons V2 launches

The current V2 documentation provides the event signature:

TokenLaunched(
    token,
    curve,
    deployer,
    pairToken,
    launchConfigId,
    graduationThreshold
)

and explicitly shows using getLogs() to index every launch.

With viem:

import { parseAbiItem } from "viem";

const tokenLaunchedEvent = parseAbiItem(
  "event TokenLaunched(address indexed token, address indexed curve, address indexed deployer, address pairToken, uint256 launchConfigId, uint256 graduationThreshold)"
);

const logs = await client.getLogs({
  address: PONS_V2_FACTORY,
  event: tokenLaunchedEvent,
  fromBlock: deploymentBlock,
  toBlock: "latest",
});

The scanner has now answered:

A new Pons V2 launch exists.

But we still know very little about it.

Step 3: Normalize the launch

I would immediately convert the raw event into an application object.

type PonsVersion = "V1" | "V2";

interface PonsLaunch {
  token: `0x${string}`;
  deployer: `0x${string}`;

  version: PonsVersion;

  pairToken: `0x${string}`;

  curve?: `0x${string}`;
  pool?: `0x${string}`;

  launchConfigId: bigint;
  graduationThreshold?: bigint;

  launchBlock: bigint;
  launchTxHash: `0x${string}`;
}

Then:

Blockchain Event
      ↓
V2 Adapter
      ↓
PonsLaunch

This is important because application code should not have to understand the raw ABI of every protocol version.

Step 4: Create a canonical token ID

A ticker is not a unique blockchain identity.

The scanner should identify a token using:

chain ID
+
contract address

For example:

function tokenId(
  chainId: number,
  address: string
): string {
  return `${chainId}:${address.toLowerCase()}`;
}

Then:

4663:0x1234...

becomes the canonical application identifier.

This also prevents duplicate records caused by address casing differences.

For Pons V2 specifically, the documentation warns that token names and symbols can be copied, so the address should be treated as the actual identity.

Step 5: Enrich token metadata

After the launch event, the scanner should load the token's metadata.

For example:

interface TokenMetadata {
  address: `0x${string}`;
  name: string;
  symbol: string;
  decimals: number;
  totalSupply: bigint;

  deployer: `0x${string}`;

  description?: string;
  image?: string;

  website?: string;
  twitter?: string;
  telegram?: string;
}

The pipeline becomes:

TokenLaunched
      ↓
Token Address
      ↓
ERC-20 Metadata
      ↓
Pons-Specific Metadata
      ↓
Token Registry

Now the scanner can answer more useful questions:

What is this token?
Who launched it?
Which Pons version?
Which pair?
Which curve?
When was it launched?

Step 6: Track the market state

For V2, a new token begins on a bonding curve.

The current documentation describes the curve as the initial market, with trading continuing there until graduation and then continuing in a Uniswap V4 pool.

I would represent market state explicitly:

type MarketPhase =
  | "CURVE"
  | "GRADUATING"
  | "POOL"
  | "RESCUED"
  | "UNKNOWN";

The scanner can then maintain:

interface MarketState {
  phase: MarketPhase;

  quoteAsset: `0x${string}`;

  curve?: `0x${string}`;
  pool?: `0x${string}`;

  lastBlock: bigint;
  updatedAt: number;
}

This is much more useful than keeping only:

token = 0x...

Step 7: Index the curve

The current Pons V2 docs explicitly recommend indexing the curve for trade history.

The documented events include:

CurveBuy
CurveSell
CurveBuyRefunded
CurveCompleted

and the factory also emits LaunchSwept.

For example:

const curveBuyEvent = parseAbiItem(
  "event CurveBuy(address indexed buyer, address indexed recipient, uint256 quoteIn, uint256 tokensOut, uint256 fee, uint256 tax)"
);

const curveSellEvent = parseAbiItem(
  "event CurveSell(address indexed seller, address indexed recipient, uint256 tokensIn, uint256 quoteOut, uint256 fee, uint256 tax)"
);

const tradeLogs = await client.getLogs({
  address: curveAddress,
  events: [
    curveBuyEvent,
    curveSellEvent,
  ],
  fromBlock: launchBlock,
  toBlock: "latest",
});

Now the scanner is no longer just a launch detector.

It has become a market activity indexer.

Step 8: Store actual execution values

This is an important implementation detail.

The current Pons V2 documentation notes that a buy which finishes a curve can be partially filled. It specifically recommends reading tokensOut and quoteIn from the event rather than assuming the requested amount is what was executed.

So the scanner should store:

interface CurveTrade {
  txHash: `0x${string}`;
  logIndex: number;

  side: "BUY" | "SELL";

  trader: `0x${string}`;
  recipient: `0x${string}`;

  quoteAmount: bigint;
  tokenAmount: bigint;

  fee: bigint;
  tax: bigint;

  blockNumber: bigint;
}

Do not reconstruct the history from UI assumptions.

Use the onchain event.

Step 9: Build a token registry

Once launch and trade events are normalized, the database becomes the core of the scanner.

A simple schema:

tokens
-------------------
id
address
version
name
symbol
deployer
created_at

pons_launches
-------------------
token_id
curve_address
pool_address
pair_token
launch_config_id
launch_block
launch_tx_hash

market_states
-------------------
token_id
phase
quote_asset
last_block
updated_at

curve_trades
-------------------
token_id
tx_hash
log_index
side
trader
recipient
quote_amount
token_amount
fee
tax
block_number

The advantage is that downstream applications can query a normalized database instead of decoding raw blockchain logs themselves.

Step 10: Add event idempotency

A scanner will reconnect.

It will backfill.

It may process overlapping block ranges.

That means the same event can appear more than once.

A useful event identity is:

function eventId(
  chainId: number,
  transactionHash: string,
  logIndex: number
): string {
  return `${chainId}:${transactionHash}:${logIndex}`;
}

Then:

Event
 ↓
Already processed?
 ├── yes → ignore
 └── no  → store

The database should enforce uniqueness:

UNIQUE(chain_id, transaction_hash, log_index)

This is a small feature that prevents large state problems later.

Step 11: Real-time listener and historical backfill should be separate

There are really two jobs:

Historical Indexer
       ↓
Backfill missing blocks

and:

Live Listener
       ↓
New events

I would not combine them into one giant process.

Instead:

                 Pons Contracts
                       │
              ┌────────┴────────┐
              ↓                 ↓
         Backfill Worker    Live Worker
              ↓                 ↓
              └────────┬────────┘
                       ↓
                    Database

This makes restarts and catch-up much easier.

Robinhood's documentation currently recommends dedicated infrastructure providers for production use, while its network documentation also exposes the public RPC endpoints.

Step 12: Bounded block processing

A common indexing mistake is requesting an enormous block range in one call.

I prefer bounded chunks:

const CHUNK_SIZE = 2_000n;

async function backfill(
  startBlock: bigint,
  endBlock: bigint
) {
  for (
    let from = startBlock;
    from <= endBlock;
    from += CHUNK_SIZE
  ) {
    const to =
      from + CHUNK_SIZE - 1n > endBlock
        ? endBlock
        : from + CHUNK_SIZE - 1n;

    await indexRange(from, to);
  }
}

That gives the indexer:

smaller requests
+
retryable work
+
clear progress

instead of one enormous RPC request that can fail and force the entire operation to restart.

Step 13: Filters

Once the token registry exists, we can build a filter engine.

For example:

interface TokenFilter {
  name: string;

  check(
    token: TokenRecord
  ): Promise<FilterResult>;
}

interface FilterResult {
  passed: boolean;
  reason: string;
}

Then:

Token
  ↓
Contract Filter
  ↓
Metadata Filter
  ↓
Deployer Filter
  ↓
Market Filter
  ↓
Liquidity Filter
  ↓
Custom Rules

This is much cleaner than putting everything into:

shouldTrade(token)

with hundreds of conditions.

Step 14: Opportunity state

A scanner should distinguish detection from eligibility.

I would use something like:

type OpportunityState =
  | "DETECTED"
  | "WATCHING"
  | "ELIGIBLE"
  | "REJECTED"
  | "EXPIRED";

For example:

TokenLaunched
      ↓
DETECTED
      ↓
Filters
      ↓
WATCHING
      ↓
ELIGIBLE

Now the scanner can feed different systems.

Scanner → Sniper Bot

The Pons Sniper Bot can consume:

ELIGIBLE TOKEN

and then perform its own:

quote
↓
risk
↓
execution

So:

Pons Scanner
      ↓
Eligible Opportunity
      ↓
Pons Sniper
      ↓
Execution

This is cleaner than implementing launch discovery separately inside the sniper.

Scanner → Trading Terminal

A Pons Trading Terminal can consume the scanner's API:

New Launches
Market Phase
Recent Trades
Liquidity
Token Metadata

The frontend can then show:

NEW
WATCHING
ELIGIBLE
GRADUATED

without knowing anything about raw contract logs.

Scanner → Alerts

A simpler product might only need alerts.

For example:

Pons Token Scanner
        ↓
Filter
        ↓
Telegram / Discord

The alert can contain:

New Pons Launch

Token: XYZ
Version: V2
Pair: WETH
Curve: 0x...
Deployer: 0x...
Launch Block: 123456
Status: Watching

This can already be a useful standalone application.

Scanner → Copy Trading

The same data layer can support wallet intelligence.

For example:

New Token
   ↓
Trade Events
   ↓
Identify Active Wallets
   ↓
Track Wallet
   ↓
Generate Signal

That turns the scanner into the first stage of a copy-trading system.

Step 15: Market state and graduation

The scanner must understand when a Pons V2 launch leaves the bonding curve.

The current Pons documentation describes:

CurveBuy
     ↓
CurveCompleted
     ↓
Graduation
     ↓
PoolCreated
     ↓
Uniswap V4

and documents the relevant factory/curve events for reconstruction.

So the scanner should update:

market.phase = "POOL";

when the protocol state confirms graduation.

Do not infer this only from token balances.

Use protocol state and events.

Step 16: Reconciliation

Even a good indexer can fall behind or miss an event.

So I would build reconciliation.

For example:

Database
   ↓
Stored Market State
   ↓
Read Contract State
   ↓
Compare
   ↓
Repair

The scanner can periodically check:

launch exists
curve exists
phase
pool state
latest processed block

and detect inconsistencies.

This gives the system a recovery mechanism instead of assuming the indexer is permanently correct.

Step 17: Keep scanner state separate from trading state

This is important.

The scanner should record:

what happened

The trading engine should decide:

what to do

So:

Scanner
   ↓
Market State
   ↓
Strategy
   ↓
Risk
   ↓
Execution

The scanner itself should not secretly submit trades.

That separation makes the system much easier to reuse.

A production TypeScript structure

I would organize the project roughly like:

src/
├── config/
│   └── pons.ts
│
├── clients/
│   └── chain.ts
│
├── protocols/
│   ├── v1/
│   │   └── adapter.ts
│   └── v2/
│       └── adapter.ts
│
├── indexer/
│   ├── backfill.ts
│   ├── live.ts
│   └── decoder.ts
│
├── tokens/
│   ├── registry.ts
│   └── metadata.ts
│
├── markets/
│   └── marketState.ts
│
├── filters/
│   ├── creator.ts
│   ├── liquidity.ts
│   └── engine.ts
│
├── opportunities/
│   └── state.ts
│
├── alerts/
│   ├── telegram.ts
│   └── discord.ts
│
├── reconciliation/
│   └── reconcile.ts
│
├── api/
│   └── server.ts
│
└── index.ts

This gives every subsystem one responsibility.

Database-backed scanning

A production scanner should persist its progress.

For example:

indexer_state
-----------------
network
contract
last_block
updated_at

Then after a restart:

Database
   ↓
Last processed block
   ↓
Backfill
   ↓
Live listener

No need to start from zero.

Observability

The scanner should expose operational metrics.

I would monitor:

latest indexed block
RPC latency
RPC errors
events processed
duplicate events
tokens discovered
filters rejected
eligible tokens
backfill progress
reconciliation mismatches

For example:

Latest block:             2,145,892
Launches indexed:             8,421
Trades indexed:             91,420
Duplicate events:              117
Eligible opportunities:         38
RPC errors:                     4
Reconciliation mismatches:     0

That gives a much better view of system health than simply checking whether the process is running.

A scanner is not necessarily an automated trader

This distinction matters from a product perspective.

A scanner can be:

Token Discovery Product

without ever executing a trade.

It can provide:

alerts
API
dashboard
historical data
analytics

Or it can become the first stage of:

Scanner
   ↓
Sniper

or:

Scanner
   ↓
Trading Terminal

or:

Scanner
   ↓
Copy Trading

This makes the scanner a reusable infrastructure component.

What I would build for a client

Starter

Launch Detection
+
Metadata
+
Telegram Alerts

MVP

Launch Detection
+
Metadata
+
Filters
+
Database
+
API
+
Dashboard

Advanced

V1 + V2
+
Historical Backfill
+
Market State
+
Liquidity
+
Wallet Intelligence
+
Alerts
+
API
+
Sniper Integration

Full Trading Platform

Scanner
+
Strategy
+
Risk
+
Execution
+
Portfolio
+
Reconciliation
+
Terminal

This lets the client start with exactly the part they need.

Connecting the scanner to Solidity and EVM engineering

This is also where the scanner connects with the Solidity/EVM work I have been publishing.

The scanner is mostly an offchain data system:

RPC
+
viem
+
TypeScript
+
Database

But the data originates from:

Solidity Contracts
      ↓
EVM Events
      ↓
Indexer

So understanding the contract layer matters.

You need to know:

event signatures
indexed parameters
state-changing functions
contract addresses
protocol versions

That is one reason I see Solidity + EVM + TypeScript as one connected engineering skillset rather than three unrelated topics.

Public implementation work

The same development approach is already being applied to other Robinhood Chain products.

Pons Sniper Bot

Launch detection, V2 curve execution, risk controls, transaction monitoring, and reconciliation.

https://github.com/0xhamssog/pons-sniper-bot

Pons Bundler

Pons V2 launch-and-buy and multi-wallet execution.

https://github.com/0xhamssog/pons-bundler

Stock Token Arbitrage Bot

Reference/onchain pricing and trading infrastructure.

https://github.com/0xhamssog/robinhood-stock-token-arbitrage-bot

The scanner fits underneath these products as the discovery and market-data layer.

The bigger architecture

Eventually, several products can share the same scanner:

                         ROBINHOOD CHAIN
                                ↓
                         PONS CONTRACTS
                                ↓
                         EVENT INDEXER
                                ↓
                       NORMALIZED STATE
                                ↓
                         PONS SCANNER
                                ↓
          ┌─────────────────────┼─────────────────────┐
          ↓                     ↓                     ↓
       Alerts                API                  Analytics
          ↓                     ↓                     ↓
      Telegram             Terminal             Dashboard
                                ↓
                           Trading Engine
                                ↓
                         ┌──────┼──────┐
                         ↓      ↓      ↓
                       Sniper  Copy  Manual
                         ↓      ↓      ↓
                         └──────┼──────┘
                                ↓
                             Risk
                                ↓
                           Execution
                                ↓
                         Reconciliation

Now the scanner is not a standalone script.

It is the data foundation underneath a trading ecosystem.

Conclusion

A Pons Token Scanner may begin with one event:

TokenLaunched

But a useful production implementation becomes:

Onchain Events
      ↓
Protocol Version
      ↓
Token Registry
      ↓
Metadata
      ↓
Market State
      ↓
Trade History
      ↓
Filtering
      ↓
Opportunity State
      ↓
Alerts / API / Dashboard
      ↓
Trading Automation

That is the difference between an event listener and a real discovery system.

The scanner can power a standalone application.

It can feed a Pons Sniper Bot.

It can become the market-data layer of a Trading Terminal.

It can support wallet intelligence and copy trading.

And because it is built directly from EVM events, it becomes reusable infrastructure rather than a one-off script.

That is the type of Robinhood Chain engineering I want to demonstrate: Solidity/EVM understanding underneath, TypeScript infrastructure in the middle, and real trading products on top.

Need a custom Pons token scanner?

I build custom Pons token scanners, launch monitors, event indexers, APIs, dashboards, sniper integrations, and trading infrastructure on Robinhood Chain.

Building a Trading Executor in Solidity for Robinhood Chain

hamssog — Tue, 29 Sep 2026 12:48:50 +0000

A trading bot can be written almost entirely in TypeScript.

For a simple application, that can be enough:

Strategy
   ↓
TypeScript
   ↓
Router
   ↓
Robinhood Chain

But as the system becomes more complex, there is another engineering layer worth designing deliberately:

the Solidity execution layer.

A custom smart contract can provide an onchain boundary for authorized execution, token handling, protocol adapters, validation, and event emission.

The application above it can still handle:

market data
strategy
risk
wallet orchestration
monitoring
reconciliation

That gives us a complete architecture:

Trading Strategy
       ↓
Risk Engine
       ↓
TypeScript Backend
       ↓
Solidity Executor
       ↓
EVM
       ↓
Robinhood Chain

Robinhood Chain is fully EVM-compatible. Its current documentation states that Solidity and Vyper contracts can be deployed using standard Ethereum tooling, including Foundry and Hardhat. Robinhood Chain mainnet currently uses chain ID 4663.

This article focuses on how I would build the Solidity layer for a trading system.

Why put part of a trading system onchain?

Not every trading bot needs a custom contract.

For some systems:

TypeScript
   ↓
Existing Protocol Contract

is perfectly reasonable.

A custom Solidity layer becomes more interesting when the application needs an explicit execution boundary.

For example:

TypeScript
   ↓
Trade Intent
   ↓
Solidity Executor
   ↓
Protocol

The Solidity contract can enforce rules such as:

authorized executor
allowed assets
allowed routers
maximum trade amount
minimum output
deadline
pause state

Meanwhile, the application layer handles:

market discovery
strategy
pricing
risk scoring
wallet management
transaction monitoring

The contract is therefore not the trading strategy.

It is the onchain enforcement and execution layer.

The architecture

A production-oriented implementation can be split into:

                    TRADING APPLICATION
                           |
            +--------------+--------------+
            |                             |
        Strategy                       Risk Engine
            |                             |
            +--------------+--------------+
                           |
                      Trade Intent
                           |
                    TypeScript Backend
                           |
                      Solidity Executor
                           |
                    Protocol Adapter
                           |
                         EVM
                           |
                   Robinhood Chain

After the transaction:

Robinhood Chain
       ↓
Events / Receipt
       ↓
Transaction Monitor
       ↓
Reconciliation
       ↓
Position State

This creates a complete round trip.

Start with a constrained executor

I would avoid designing a contract that accepts arbitrary calldata from an untrusted caller.

A better starting point is a constrained executor.

For example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

interface IERC20 {
    function transferFrom(
        address from,
        address to,
        uint256 amount
    ) external returns (bool);
}

interface IRouter {
    function swap(
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 minAmountOut,
        address recipient
    ) external returns (uint256 amountOut);
}

contract TradingExecutor {
    address public immutable owner;

    mapping(address => bool) public allowedRouter;
    mapping(address => bool) public allowedToken;

    bool public paused;

    error Unauthorized();
    error Paused();
    error RouterNotAllowed();
    error TokenNotAllowed();
    error InvalidAmount();
    error SlippageExceeded();

    event RouterUpdated(address indexed router, bool allowed);
    event TokenUpdated(address indexed token, bool allowed);
    event Paused(bool value);

    event TradeExecuted(
        bytes32 indexed operationId,
        address indexed router,
        address indexed tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 amountOut
    );

    modifier onlyOwner() {
        if (msg.sender != owner) revert Unauthorized();
        _;
    }

    constructor(address initialOwner) {
        owner = initialOwner;
    }

    function setRouter(
        address router,
        bool allowed
    ) external onlyOwner {
        allowedRouter[router] = allowed;
        emit RouterUpdated(router, allowed);
    }

    function setToken(
        address token,
        bool allowed
    ) external onlyOwner {
        allowedToken[token] = allowed;
        emit TokenUpdated(token, allowed);
    }

    function setPaused(
        bool value
    ) external onlyOwner {
        paused = value;
        emit Paused(value);
    }

    function executeTrade(
        bytes32 operationId,
        address router,
        address tokenIn,
        address tokenOut,
        uint256 amountIn,
        uint256 minAmountOut,
        address recipient
    ) external onlyOwner returns (uint256 amountOut) {
        if (paused) revert Paused();
        if (!allowedRouter[router]) revert RouterNotAllowed();
        if (!allowedToken[tokenIn]) revert TokenNotAllowed();
        if (!allowedToken[tokenOut]) revert TokenNotAllowed();
        if (amountIn == 0) revert InvalidAmount();

        IERC20(tokenIn).transferFrom(
            msg.sender,
            address(this),
            amountIn
        );

        IERC20(tokenIn).approve(
            router,
            amountIn
        );

        amountOut = IRouter(router).swap(
            tokenIn,
            tokenOut,
            amountIn,
            minAmountOut,
            recipient
        );

        if (amountOut < minAmountOut) {
            revert SlippageExceeded();
        }

        emit TradeExecuted(
            operationId,
            router,
            tokenIn,
            tokenOut,
            amountIn,
            amountOut
        );
    }
}

This is still only a simplified example.

The important design principle is the constraint:

Caller
 ↓
Authorization
 ↓
Allowed Router
 ↓
Allowed Token
 ↓
Trade Parameters
 ↓
Execution
 ↓
Event

The contract does not accept unlimited arbitrary execution.

Access control comes first

Trading contracts can potentially move valuable assets.

So the first question should be:

Who is allowed to call the execution function?

The simplest model is:

Owner
   ↓
Executor
   ↓
Trade

But larger systems may need:

Admin
   ↓
Configuration

Operator
   ↓
Trading Execution

Guardian
   ↓
Emergency Pause

The right model depends on custody and product requirements.

A multi-wallet system will usually need a different signer architecture from a single-wallet application.

The contract should validate what matters onchain

Some rules belong in TypeScript.

Some rules are safer when enforced directly by Solidity.

For example, market scanning belongs naturally offchain:

price feeds
technical indicators
historical analysis
strategy logic

But an onchain executor can enforce:

allowed router
allowed token
maximum amount
minimum output
authorized caller
deadline
pause state

This gives:

Offchain Strategy
       ↓
Onchain Enforcement

rather than trying to put the entire trading strategy inside a contract.

Slippage should be explicit

Suppose a strategy wants to buy a token.

The application can calculate:

Expected Output = 1,250

but the contract should not simply accept whatever comes back.

Instead:

Expected Output
       ↓
Minimum Acceptable Output
       ↓
Solidity
       ↓
Execute

For example:

uint256 amountOut = router.swap(
    tokenIn,
    tokenOut,
    amountIn,
    minAmountOut,
    recipient
);

if (amountOut < minAmountOut) {
    revert SlippageExceeded();
}

The exact router interface will depend on the protocol being integrated.

The important concept is that the acceptable execution boundary is explicit.

Deadlines are another useful boundary

A transaction that was valid when a strategy generated it may no longer be desirable several minutes later.

The TypeScript layer can calculate a deadline:

signal generated
      ↓
quote generated
      ↓
deadline = now + 15 seconds

The contract can then reject execution after the deadline.

Conceptually:

error DeadlineExpired();

if (block.timestamp > deadline) {
    revert DeadlineExpired();
}

This is especially useful for trading systems where quotes can become stale quickly.

Token approvals need careful handling

A common EVM interaction looks like:

Token
 ↓
approve
 ↓
Router
 ↓
swap

But approvals are part of the security model.

A trading contract should avoid giving an arbitrary address unlimited approval.

A better architecture is:

Approved Router
      ↓
Token Approval
      ↓
Specific Execution

The allowed router list can be controlled by the contract administrator.

For sensitive applications, token approvals should also be considered part of the deployment and operational review.

Events connect Solidity to the backend

The smart contract should emit structured events.

For example:

event TradeExecuted(
    bytes32 indexed operationId,
    address indexed router,
    address indexed tokenIn,
    address tokenOut,
    uint256 amountIn,
    uint256 amountOut
);

The TypeScript backend can then consume:

TradeExecuted
      ↓
Event Decoder
      ↓
Trade Record
      ↓
Position Engine
      ↓
Portfolio

This gives the backend a reliable link between the requested operation and the onchain result.

Operation IDs

I like giving each trade a deterministic application-level operation ID.

For example:

strategy
+
wallet
+
nonce
+
timestamp

can produce:

operationId

The contract records it in the event:

TradeExecuted(operationId, ...)

The backend can then connect:

Strategy Signal
      ↓
Trade Intent
      ↓
operationId
      ↓
Transaction
      ↓
Event
      ↓
Position

This becomes extremely useful when debugging execution.

Idempotent event processing

A blockchain indexer can receive the same event again.

For example:

RPC connection
    ↓
disconnect
    ↓
reconnect
    ↓
event replay

If the backend simply processes every event as a new trade, the position may be doubled.

So I would construct an event identity from:

chainId
+
transactionHash
+
logIndex

For example:

const eventId =
  `${chainId}:${transactionHash}:${logIndex}`;

Then store that value with a database uniqueness constraint.

The logic becomes:

Event
 ↓
Already processed?
 ├── yes → ignore
 └── no  → process

This is a small implementation detail with a large operational impact.

Transaction state still belongs in TypeScript

The Solidity contract can emit the final execution event.

The application still needs to track transaction state before that event exists.

I would use something like:

type TransactionState =
  | "CREATED"
  | "SIGNED"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "FAILED"
  | "UNKNOWN";

Normal execution:

CREATED
   ↓
SIGNED
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED

Failure path:

SUBMITTED
   ↓
RPC TIMEOUT
   ↓
UNKNOWN
   ↓
RECONCILIATION

This is where smart-contract engineering meets backend engineering.

Never equate RPC failure with transaction failure

Consider:

Application
   ↓
broadcast transaction
   ↓
RPC timeout

The timeout only tells us that the application did not receive the expected response.

It does not necessarily tell us:

transaction failed

The transaction may already exist onchain.

So the correct flow is:

UNKNOWN
   ↓
Find transaction
   ↓
Check receipt
   ↓
Check events
   ↓
Update state

Only then should the application decide what to do next.

Reconciliation

Suppose the application expected:

BUY 100 tokens

The transaction completes.

The contract emits:

amountOut = 63

The position engine must record:

not:

The reconciliation system can compare:

Database
   ↓
Transaction Receipt
   ↓
Trade Events
   ↓
Token Balance
   ↓
Canonical Position

That gives the system a recovery mechanism after:

RPC failures
missed events
process crashes
partial execution
delayed confirmations

Pons is a good example of why protocol adapters matter

The same architecture applies to Pons, but the protocol adapter needs to understand which Pons version is being used.

The current Pons documentation describes V2 as:

Create
  ↓
Bonding Curve
  ↓
Trade
  ↓
Graduate
  ↓
Uniswap V4 Pool

Pons V2 also has protocol-specific launch and trading behavior such as its bonding-curve reserves, snipe-tax rules, and launch lifecycle.

That means a trading executor should not bury Pons-specific assumptions everywhere.

Instead:

Trading Engine
      ↓
Pons Adapter
      ↓
Pons Contract

This keeps protocol-specific logic isolated.

Stock Tokens show another side of EVM integration

Robinhood's current documentation describes Stock Tokens as standard ERC-20 contracts with 18 decimals and onchain Chainlink price feeds. (docs.robinhood.com)

That means the same application architecture can be reused:

Stock Token
     ↓
ERC-20 Adapter
     ↓
Trading Executor
     ↓
Portfolio

The strategy can remain separate from the contract implementation.

That allows the same backend to support:

arbitrage
momentum
rebalancing
signal-based trading

without rebuilding the entire execution layer.

Contract testing with Foundry

A contract that compiles is not proof that it is safe.

I would test at multiple levels.

Unit Tests
    ↓
Integration Tests
    ↓
Fork Tests
    ↓
Testnet
    ↓
Mainnet

For a trading executor, the minimum test surface should include:

authorized caller
unauthorized caller
allowed router
blocked router
allowed token
blocked token
zero amount
slippage failure
deadline failure
paused state
successful execution
event emission

For example:

function testRejectsUnauthorizedCaller() public {
    vm.prank(attacker);

    vm.expectRevert(
        TradingExecutor.Unauthorized.selector
    );

    executor.executeTrade(
        operationId,
        router,
        tokenIn,
        tokenOut,
        amountIn,
        minAmountOut,
        recipient
    );
}

The exact test setup will depend on the project.

The principle is more important:

test the rejection paths, not only the happy path.

Robinhood's current deployment guide recommends testing on testnet before deploying to mainnet.

Fork testing

Fork tests are particularly useful for protocol integrations.

Instead of mocking every dependency, a fork can reproduce a realistic EVM environment.

Conceptually:

Robinhood Chain State
        ↓
Fork
        ↓
Your Contract
        ↓
Real Protocol Contracts
        ↓
Test Execution

This is useful when validating:

router behavior
token behavior
balances
allowances
events
execution paths

before sending transactions against the live network.

Gas optimization

Gas matters.

But I would optimize in this order:

1. Correctness
2. Security
3. Test coverage
4. Observability
5. Gas optimization

Useful optimization techniques may include:

custom errors
efficient storage
avoiding unnecessary storage reads
careful calldata usage
efficient event design

But I would never sacrifice a clear security boundary just to save a small amount of gas.

Contract structure

A larger project could separate the Solidity code like this:

contracts/
├── executors/
│   └── TradingExecutor.sol
│
├── adapters/
│   ├── TokenAdapter.sol
│   ├── PonsAdapter.sol
│   └── RouterAdapter.sol
│
├── interfaces/
│   ├── IERC20.sol
│   └── IRouter.sol
│
├── libraries/
│   ├── Validation.sol
│   └── Types.sol
│
└── mocks/

The TypeScript application can then sit beside it:

src/
├── strategy/
├── risk/
├── execution/
├── monitoring/
├── portfolio/
├── reconciliation/
└── api/

This gives:

contracts/
     +
TypeScript
     =
Trading Infrastructure

Multi-wallet systems

Multi-wallet trading adds another layer.

Imagine:

Wallet A
Wallet B
Wallet C
Wallet D

The backend might coordinate all four.

But the contract should have an explicit authorization model.

For example:

Admin
  ↓
Authorized Executor
  ↓
Allowed Operation
  ↓
Protocol

The exact architecture depends on whether the wallets are:

user-owned
operator-owned
custodial
non-custodial

That decision should happen before contract design.

Emergency controls

Trading infrastructure can benefit from a pause mechanism.

For example:

function setPaused(
    bool value
) external onlyOwner {
    paused = value;
    emit Paused(value);
}

Then:

Normal
 ↓
Trading Enabled

Emergency
 ↓
Pause

Investigation
 ↓
Reconciliation

Recovery
 ↓
Unpause

A pause mechanism is not a replacement for security.

It is an additional operational control.

The complete execution lifecycle

Putting everything together:

MARKET DATA
     ↓
STRATEGY
     ↓
TRADE INTENT
     ↓
RISK ENGINE
     ↓
QUOTE
     ↓
TYPE SCRIPT
     ↓
SOLIDITY EXECUTOR
     ↓
PROTOCOL
     ↓
ROBINHOOD CHAIN
     ↓
TRANSACTION
     ↓
EVENTS
     ↓
RECONCILIATION
     ↓
POSITION
     ↓
PORTFOLIO

This is the architecture I want to demonstrate when I say I build trading systems.

The smart contract is one layer.

The TypeScript engine is another.

The important part is how the two work together.

Where this fits into Pons and Stock Token products

The same engineering model can support:

Pons Sniper Bot
Pons Bundler
Pons Copy Trading Bot
Pons Trading Terminal
Stock Token Trading Bot
Stock Token Arbitrage Bot
Multi-Wallet Trading
Custom Execution Infrastructure

For example:

Pons Sniper
    ↓
Launch Detection
    ↓
Strategy
    ↓
Risk
    ↓
Pons Adapter
    ↓
Execution

or:

Stock Token Arbitrage
    ↓
Price Normalization
    ↓
Opportunity
    ↓
Risk
    ↓
Execution Contract
    ↓
Onchain Trade

The application changes.

The underlying engineering principles stay similar.

My preferred development stack

For Robinhood Chain trading systems, the stack can look like:

Solidity
    ↓
Foundry
    ↓
EVM
    ↓
Robinhood Chain
    ↓
viem
    ↓
TypeScript
    ↓
PostgreSQL
    ↓
API / Dashboard

That allows work across several levels:

Smart Contract
      ↓
Protocol Integration
      ↓
Trading Engine
      ↓
Backend
      ↓
Frontend

This is the engineering surface I want my public projects to demonstrate.

Public implementation proof

I already work with this broader architecture across Pons and Stock Token projects.

Pons Sniper Bot

Pons V2 launch detection, curve execution, risk controls, transaction monitoring, and reconciliation.

GitHub: github.com/0xhamssog/pons-sniper-bot

Pons Bundler

Pons V2 launch-and-buy and multi-wallet execution.

GitHub: github.com/0xhamssog/pons-bundler

Stock Token Arbitrage Bot

Stock Token pricing, opportunity detection, and automated trading infrastructure.

GitHub: github.com/0xhamssog/robinhood-stock-token-arbitrage-bot

These projects provide a practical foundation for adding more protocol integrations and custom execution modules.

Smart Contract Development

Custom Solidity contracts, adapters, execution contracts, access control, events, and testing.

Trading Bot Development

Strategy engines, risk systems, execution, transaction monitoring, and reconciliation.

Pons Development

Sniper bots, bundlers, copy trading, wallet tracking, launch monitoring, and trading terminals.

Stock Token Development

Trading bots, arbitrage systems, portfolio tools, and automated execution.

Full Trading Applications

Frontend + API + trading engine + Solidity + wallet infrastructure + monitoring.

The starting point does not have to be a complete platform.

It can be one contract, one execution module, or one trading strategy.

Final Thoughts

A trading bot is often described as:

API
+
Strategy
+
Transaction

But a more complete system is:

Strategy
     ↓
Risk
     ↓
Execution
     ↓
Solidity
     ↓
    EVM
     ↓
Transaction
     ↓
Events
     ↓
Reconciliation
     ↓
Position

That is why I am expanding my Robinhood Chain work beyond application-level bots.

I want the public work to demonstrate the full engineering stack:

Solidity.

EVM.

TypeScript.

Protocol integration.

Trading infrastructure.

Risk management.

Transaction state.

Reconciliation.

For clients building on Robinhood Chain and Pons, that means I can work not only on the bot interface, but on the smart-contract and execution infrastructure underneath it.

Need a custom Robinhood Chain trading system?

I build custom Solidity/EVM contracts, Pons integrations, Stock Token trading bots, execution engines, multi-wallet systems, trading terminals, and full-stack trading applications.

Robinhood Chain Development with TypeScript: Building Pons Trading Systems

hamssog — Mon, 28 Sep 2026 09:37:06 +0000

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

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

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

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

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

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

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

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()

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

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

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:

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.

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


plaintext

The important part is:



```text
detected transaction ≠ automatic copy

A client may want:

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

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

The architecture becomes:

             WEB TERMINAL
                  ↓
                 API
                  ↓
            TRADING ENGINE
                  ↓
             RISK ENGINE
                  ↓
              EXECUTOR
                  ↓
           ROBINHOOD CHAIN

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

The development pattern is similar:

Asset Registry
      ↓
Price Layer
      ↓
Strategy
      ↓
   Risk
      ↓
Execution
      ↓
Position
      ↓
Reconciliation

Stock Token pricing is not just one number

Robinhood's current Stock Token APIs expose:

/assets
/prices/{symbol}
/corporate-actions

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;
}

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

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

A strategy produces:

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

The risk engine produces:

interface RiskDecision {
  approved: boolean;
  reason?: string;
}

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";

Normal flow:

CREATED
   ↓
SIGNED
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED

Failure/recovery flow:

SUBMITTED
   ↓
RPC TIMEOUT
   ↓
UNKNOWN
   ↓
RECONCILE
   ↓
CONFIRMED / FAILED / PENDING

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

Suppose local state says:

BUY 100

but only 63 tokens were actually received.

The final position must become:

Reconciliation protects the application from:

missed events
RPC failures
application restarts
partial fills
delayed confirmations

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

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

Production bot

Multiple assets
Persistent state
Transaction monitoring
Reconciliation
Alerts
Monitoring

Complete product

Frontend
API
Trading Engine
Wallet Management
Risk
Portfolio
Analytics
Monitoring

Advanced infrastructure

Multi-wallet
Multiple strategies
Backtesting
Historical data
Custom APIs
Advanced risk
Execution orchestration

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"

and searching for:

"Pons sniper bot developer"

"Pons bundler"

"Pons copy trading bot"

"Pons trading terminal"

"Stock Token trading bot"

"Robinhood Chain trading bot"

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

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

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

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.

Building a Stock Token Trading Bot on Robinhood Chain with TypeScript

hamssog — Sun, 27 Sep 2026 05:46:46 +0000

A Stock Token trading bot can start as a simple price-monitoring script.

But turning it into a useful automated trading system requires much more than detecting a price.

The bot has to understand:

Asset
→ Price
→ Strategy
→ Risk
→ Execution
→ Transaction State
→ Position
→ Reconciliation

That is the architecture I would use for building automated Stock Token trading on Robinhood Chain.

Robinhood Chain is EVM-compatible and currently uses chain ID 4663. Stock Tokens are ERC-20 tokens with 18 decimals, and Robinhood provides onchain Chainlink price feeds for them.

1. The architecture

Instead of putting everything into one trading loop, I would separate the system into services or modules:

                    STOCK TOKEN DATA
                           ↓
                  ┌────────────────┐
                  │ Asset Registry │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │  Price Layer   │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │ Strategy Engine│
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │   Risk Engine  │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │    Executor    │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │ Tx State       │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │ Position State │
                  └───────┬────────┘
                          ↓
                  ┌────────────────┐
                  │ Reconciliation │
                  └────────────────┘

This separation gives each component a clear job.

2. Asset discovery

The first step is knowing what Stock Tokens are available.

Robinhood's current /assets API exposes metadata including:

tokenSymbol
tokenName
deployments
chainId
currentMultiplier
pendingMultiplier
tradingCapabilities
status

The API also exposes the canonical contract deployment for Robinhood Chain.

I would normalize that into an internal TypeScript type:

interface StockTokenAsset {
  symbol: string;
  contractAddress: string;
  chainId: number;

  currentMultiplier: string;

  status: "ACTIVE" | "INACTIVE";

  tradingCapabilities: unknown;
}

The asset registry can then become the source of truth for the rest of the application.

API
 ↓
Asset Registry
 ↓
Trading System

Instead of every strategy trying to rediscover the asset independently.

3. Price ingestion

Robinhood provides a REST price endpoint:

GET /rhj/prices/{symbol}

The current API documentation says this endpoint is cached for 15 seconds and rate-limited to 60 requests/second. The response includes bid, ask, generated timestamp, trading-halt information, and other fields.

That means a bot should retain quote metadata instead of treating the returned number as timeless.

interface ReferenceQuote {
  symbol: string;
  bid: number;
  ask: number;
  generatedAt: number;
  isTradingHalt: boolean;
}

Then:

function isFresh(
  quote: ReferenceQuote,
  maxAgeMs: number
): boolean {
  return Date.now() - quote.generatedAt <= maxAgeMs;
}

A trading strategy should be able to reject stale data before it generates a trade intent.

4. Price normalization

This is one of the most important implementation details.

Robinhood documents that the REST /prices endpoint returns the raw underlying-equity bid/ask and is not multiplier-adjusted.

The onchain Chainlink price is multiplier-adjusted.

When combining those surfaces, the application needs to apply currentMultiplier appropriately.

So I would make normalization explicit:

interface PricePoint {
  symbol: string;
  source: "REST" | "CHAINLINK" | "DEX";
  priceUsd: number;
  timestamp: number;
  multiplierAdjusted: boolean;
}

Then the price adapter handles the transformation:

REST
 ↓
Raw underlying price
 ↓
Multiplier
 ↓
Normalized value

while:

Chainlink
 ↓
Already multiplier-adjusted
 ↓
Normalized value

The strategy receives normalized values rather than worrying about where they came from.

5. Corporate actions

The multiplier is not just a technical field.

It is part of the economic representation of the Stock Token.

Robinhood's API exposes currentMultiplier, pendingMultiplier, and a corporate-actions endpoint. The documentation describes events including forward splits, reverse splits, dividends, mergers, spin-offs, redemptions, and other actions.

That means the system can model:

Corporate Action
       ↓
Multiplier Change
       ↓
Price Normalization
       ↓
Portfolio Valuation
       ↓
Strategy Calculation

This should be handled at the asset/data layer instead of hidden inside individual strategies.

6. Strategy engine

The strategy should not know how to send transactions.

It should answer:

Given the current market state, should I create a trade intent?

For example:

interface TradeIntent {
  symbol: string;
  side: "BUY" | "SELL";
  quantity: bigint;

  maxSlippageBps: number;
  strategyId: string;

  createdAt: number;
}

A strategy might generate:

return {
  symbol: "AAPL",
  side: "BUY",
  quantity: 10n,
  maxSlippageBps: 50,
  strategyId: "mean-reversion-v1",
  createdAt: Date.now()
};

The strategy has now expressed what it wants.

It has not executed anything.

7. Different strategies can use the same infrastructure

That separation becomes valuable quickly.

The execution system can support:

Momentum
Mean reversion
Arbitrage
Scheduled trading
Rebalancing
Signal-based trading

without creating a completely different transaction stack for every strategy.

Conceptually:

                  ┌─ Momentum
                  │
Strategies ───────┼─ Arbitrage
                  │
                  ├─ Mean Reversion
                  │
                  └─ Rebalancing
                         ↓
                    Risk Engine
                         ↓
                    Execution

The strategy changes.

The execution infrastructure does not have to.

8. Risk engine

Before anything is signed, the trade should pass through a separate risk layer.

Typical rules include:

max trade size
max position size
max exposure
min expected edge
max slippage
max gas cost
max quote age
max concurrent positions

For example:

interface RiskLimits {
  maxTradeUsd: number;
  maxPositionUsd: number;
  minEdgeBps: number;
  maxSlippageBps: number;
  maxQuoteAgeMs: number;
}

Then:

interface RiskDecision {
  approved: boolean;
  reason?: string;
}

A rejected trade should be treated as a normal state of the system, not an exception.

For example:

TRADE_INTENT
     ↓
RISK_CHECK
     ↓
REJECTED

with a reason such as:

Position limit exceeded

9. Arbitrage is a strategy, not the entire architecture

A Stock Token arbitrage strategy might compare:

Reference Price
        ↓
Normalized
        ↓
Onchain / DEX Price

The naive calculation is:

grossSpread = sellPrice - buyPrice;

But a more useful model is:

Gross Spread
- Trading Fees
- Slippage
- Gas
- Execution Costs
- Safety Buffer
-----------------
Expected Net Edge

Then:

if (expectedNetEdgeBps < limits.minEdgeBps) {
  return reject("Insufficient edge");
}

This distinction is important because a visible spread does not necessarily represent an executable profit opportunity.

10. Liquidity checks

The bot also needs to consider trade size.

Suppose:

Quoted spread = 1.2%

That does not mean a $1,000 trade and a $100,000 trade can both execute at the same effective price.

The strategy should request an executable quote:

interface ExecutionQuote {
  amountIn: bigint;
  expectedAmountOut: bigint;
  minimumAmountOut: bigint;
  priceImpactBps: number;
}

Then risk can evaluate:

Requested amount
      ↓
Liquidity
      ↓
Price impact
      ↓
Expected output
      ↓
Minimum output

This is much closer to an actual trading decision.

11. Trading capabilities

Trading availability also belongs in the decision process.

The current Stock Token asset API exposes tradingCapabilities, while Robinhood's documentation notes that different assets can have different availability across market, extended, and overnight sessions. Developers should check the asset's capabilities before execution.

The execution gate therefore becomes:

ASSET ACTIVE
     ↓
SESSION ALLOWED
     ↓
TRADE ALLOWED
     ↓
QUOTE FRESH
     ↓
LIQUIDITY OK
     ↓
RISK APPROVED
     ↓
EXECUTE

That is much safer than assuming every asset is always tradable.

12. Transaction execution

Once a trade passes risk checks, the executor builds the transaction.

But execution should also be stateful.

I would define:

type TransactionState =
  | "CREATED"
  | "SIGNED"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "FAILED"
  | "UNKNOWN";

The happy path is:

CREATED
   ↓
SIGNED
   ↓
SUBMITTED
   ↓
PENDING
   ↓
CONFIRMED

But production systems need another branch.

SUBMITTED
   ↓
RPC TIMEOUT
   ↓
UNKNOWN
   ↓
RECONCILIATION

An RPC timeout is not equivalent to a failed transaction.

The transaction may already have been broadcast or confirmed.

13. Never blindly retry an unknown transaction

This is one of the most important rules in automated execution.

Consider:

Bot submits transaction
        ↓
RPC request times out
        ↓
Bot assumes failure
        ↓
Bot submits another transaction

Now there may be two transactions.

Instead:

SUBMITTED
   ↓
UNKNOWN
   ↓
Find transaction
   ↓
Check receipt
   ↓
Check state

Only after reconciliation should the system determine whether another action is necessary.

This is why transaction state should be part of the architecture from day one.

14. Persistent state

Important trading state should not live only in memory.

I would persist:

trade intent
transaction hash
asset
side
requested quantity
filled quantity
execution price
status
timestamps
strategy ID

For example:

interface TradeRecord {
  id: string;
  symbol: string;
  side: "BUY" | "SELL";

  requestedQuantity: string;
  filledQuantity: string;

  txHash?: string;

  executionPrice?: string;

  status: TransactionState;

  createdAt: Date;
  updatedAt: Date;
}

A PostgreSQL database is a reasonable choice for this state layer.

15. Position management

Trade state and position state are related, but they are not the same thing.

A position might be:

interface Position {
  symbol: string;
  quantity: bigint;
  averageEntryPrice: number;
  realizedPnl: number;
  unrealizedPnl: number;
}

Then:

Trades
  ↓
Fills
  ↓
Position Engine
  ↓
Portfolio

This allows multiple executions to contribute to the same position.

16. Reconciliation

The blockchain ultimately determines what happened.

Suppose the local database records:

BUY 100

but the onchain result is:

63 tokens received

The portfolio should eventually reflect:

Reconciliation can compare:

              DATABASE
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
   Tx Receipt  Balances  Events
        └─────────┼─────────┘
                  ↓
          Canonical State

This process can run periodically and after important execution events.

It provides recovery from:

RPC errors
missed events
application crashes
partial execution
delayed transaction updates

17. Recommended TypeScript project structure

I would organize the project roughly like this:

src/
├── assets/
│   ├── assetRegistry.ts
│   └── capabilities.ts
│
├── market-data/
│   ├── robinhoodApi.ts
│   ├── chainlink.ts
│   └── dex.ts
│
├── pricing/
│   ├── normalize.ts
│   ├── quotes.ts
│   └── liquidity.ts
│
├── strategies/
│   ├── arbitrage.ts
│   ├── momentum.ts
│   └── index.ts
│
├── risk/
│   └── riskEngine.ts
│
├── execution/
│   ├── executor.ts
│   ├── transaction.ts
│   └── stateMachine.ts
│
├── portfolio/
│   ├── positions.ts
│   └── pnl.ts
│
├── reconciliation/
│   └── reconcile.ts
│
└── index.ts

The benefit is that every layer can be tested independently.

18. Dry-run mode

Before enabling live execution, I would make dry-run a first-class feature.

DRY RUN
   ↓
Market Data
   ↓
Strategy
   ↓
Risk
   ↓
Simulated Execution
   ↓
Trade Journal

No transaction is broadcast.

For example:

{
  "symbol": "AAPL",
  "side": "BUY",
  "quantity": "10",
  "expectedEdgeBps": 42,
  "slippageBps": 18,
  "riskApproved": true,
  "execution": "SIMULATED"
}

This gives the operator visibility into what the bot would do before connecting a funded wallet.

19. Monitoring

The dashboard should expose more than P&L.

Useful metrics include:

signals detected
signals rejected
risk rejection rate
average expected edge
executed trades
failed transactions
unknown transactions
transaction latency
stale quotes
reconciliation mismatches
current exposure
realized P&L

For example:

Signals                    1,482
Risk Approved                 87
Executed                      36
Confirmed                     34
Failed                         1
Unknown                        1

That makes the trading system observable.

20. Extending the bot into a complete product

The same infrastructure can support several different product scopes.

MVP

single wallet
single strategy
price monitoring
basic risk
automated execution
trade history

Multi-strategy bot

multiple strategies
strategy configuration
portfolio limits
persistent state
reconciliation

Trading application

web dashboard
wallet management
portfolio
P&L
alerts
execution history
API
monitoring

Larger trading infrastructure

multi-wallet execution
multiple strategies
historical data
backtesting
strategy APIs
advanced risk
analytics

The core execution engine can remain reusable across these versions.

21. Robinhood Chain gives the system an EVM-based foundation

One reason this architecture is practical is that Robinhood Chain is EVM-compatible.

Robinhood's current documentation supports standard Ethereum tooling for smart-contract development, including Foundry and Hardhat, and provides both mainnet and testnet environments. Mainnet uses chain ID 4663, while testnet uses 46630.

That means a TypeScript application can use the normal EVM ecosystem for:

wallets
RPC
viem
ethers
contract calls
transaction signing
event processing

rather than requiring an entirely different application architecture.

22. Onchain data can also become more real-time

For applications that require faster market-data reactions, Robinhood's current documentation also provides Chainlink Data Streams support on Robinhood Chain.

The documentation describes Data Streams as a pull-based oracle system designed for high-frequency applications, with TypeScript SDK support and sub-second data delivery.

This creates an interesting progression:

Basic Bot
    ↓
REST API
    ↓
Onchain Oracle
    ↓
Event Monitoring
    ↓
Real-Time Data Streams

The appropriate data architecture depends on the strategy's actual latency requirements.

23. My implementation approach

I have been working with a TypeScript implementation around this type of architecture for Robinhood Chain Stock Tokens.

The important objective is not just:

detect price

but:

DATA
 ↓
STRATEGY
 ↓
RISK
 ↓
EXECUTION
 ↓
STATE
 ↓
RECONCILIATION

That architecture can then be reused for other trading products.

GitHub:

https://github.com/0xhamssog/robinhood-stock-token-arbitrage-bot

The public project is listed as a Robinhood Chain Stock Token arbitrage bot using Uniswap, Chainlink, and REST data sources.

24. What can be built on top of it?

Once the core system is working, the same infrastructure can support:

Stock Token Trading Bot

Automated trading based on configurable strategies.

Stock Token Arbitrage Bot

Compare normalized external/reference prices with executable onchain prices.

Stock Token Portfolio Tracker

Track balances, positions, exposure, and P&L.

Robinhood Chain Trading Terminal

Provide market discovery, wallet management, charts, orders, and portfolio views.

Multi-Wallet Trading System

Coordinate multiple execution wallets under centralized strategy and risk controls.

Trading API

Expose the execution engine to external applications.

The bot becomes the foundation rather than the final product.

Conclusion

Building a Stock Token trading bot is not primarily a matter of writing a buy() function.

The harder problems are:

How fresh is the data?

Is the price normalized?

Is the asset currently tradable?

Is there enough liquidity?

What does the strategy actually want to do?

Does the trade pass risk?

What was submitted?

What actually happened?

What is the resulting position?

A robust architecture answers those questions independently.

The resulting system looks like:

Stock Token Data
      ↓
Price Normalization
      ↓
  Strategy
      ↓
     Risk
      ↓
Execution
      ↓
Transaction State
      ↓
  Position
      ↓
Reconciliation

That same foundation can grow from a small trading-bot MVP into a multi-wallet automated trading platform.

That is the type of trading infrastructure I build on Robinhood Chain: strategy-specific automation with real execution, risk controls, persistent state, and reconciliation-not just a script that watches prices.

Need a custom Stock Token trading bot?

I build custom Robinhood Chain trading systems ranging from focused trading-bot MVPs to larger automated trading applications.

GitHub:
https://github.com/0xhamssog/robinhood-stock-token-arbitrage-bot

Building a Stock Token Arbitrage Bot on Robinhood Chain with TypeScript

hamssog — Sat, 26 Sep 2026 06:52:02 +0000

A useful arbitrage bot is not just:

if (priceA < priceB) {
  buy();
}

That logic can detect a price difference.

It cannot tell you whether the trade is actually executable.

A production Stock Token arbitrage bot on Robinhood Chain needs to solve several problems at the same time:

reference pricing
onchain pricing
corporate-action multipliers
liquidity
trading availability
fees
gas
slippage
stale data
transaction state
partial execution
reconciliation

The important engineering question is therefore not:

"Is there a spread?"

It is:

"Is there a tradeable spread after every relevant cost and constraint?"

This article shows how I would structure that system in TypeScript.

1. What the arbitrage bot actually does

The basic system is:

Stock Token Asset Data
        ↓
Reference Price
        ↓
Onchain / DEX Price
        ↓
Price Normalization
        ↓
Spread Calculation
        ↓
Liquidity Check
        ↓
Risk Engine
        ↓
Execution
        ↓
Transaction Monitoring
        ↓
Position State
        ↓
Reconciliation

Each layer has one responsibility.

The arbitrage scanner discovers possible opportunities.

The risk engine decides whether the opportunity is acceptable.

The execution engine turns the opportunity into a transaction.

The reconciliation layer determines what actually happened.

That separation becomes important as soon as the bot starts handling real transactions.

2. Stock Tokens give us several pricing surfaces

Robinhood Chain documentation exposes Stock Token metadata and market information through read-only REST APIs.

The /assets endpoint provides asset metadata, deployments, the current corporate-action multiplier, and trading capabilities.

The /prices/{symbol} endpoint provides bid/ask information.

There is also onchain price information through Chainlink feeds. Robinhood notes that the REST price is the raw underlying-equity bid/ask and is not multiplier-adjusted, while the onchain Chainlink value incorporates the multiplier.

That means a pricing engine should never blindly compare two raw numbers from different sources.

Instead, create a normalized internal representation.

type PriceSource =
  | "reference"
  | "chainlink"
  | "dex";

interface NormalizedPrice {
  symbol: string;
  source: PriceSource;
  priceUsd: number;
  timestamp: number;
  multiplier: number;
}

Now every downstream component receives a predictable data structure.

3. Start with the Stock Token asset registry

A useful first step is loading /assets.

Conceptually:

interface StockTokenAsset {
  id: string;
  tokenSymbol: string;
  tokenName: string;
  currentMultiplier: string;
  deployments: Array<{
    contractAddress: string;
    chainId: number;
  }>;
  tradingCapabilities?: unknown;
}

The important fields for an arbitrage system are:

tokenSymbol
contractAddress
chainId
currentMultiplier
tradingCapabilities

The contract address matters because a matching ticker or name alone is not sufficient to identify the canonical Stock Token. Robinhood's contract documentation explicitly points developers to the canonical deployed contract addresses.

I would store the registry locally:

PostgreSQL
    ↓
asset symbol
    ↓
canonical contract
    ↓
multiplier
    ↓
trading capabilities

The bot should not repeatedly discover the same asset metadata during every trading decision.

4. Normalize the multiplier before looking for arbitrage

This is one of the easiest places to build an incorrect arbitrage engine.

Suppose the data layer receives:

Reference price = 100
Multiplier      = 0.25

If another pricing source already reflects the multiplier, directly comparing the two values can produce a false spread.

The internal pricing layer should therefore explicitly track whether a source is adjusted.

For example:

interface RawPrice {
  symbol: string;
  value: number;
  multiplierAdjusted: boolean;
  timestamp: number;
}

Then normalize:

function normalizePrice(
  price: RawPrice,
  multiplier: number
): number {
  if (price.multiplierAdjusted) {
    return price.value;
  }

  return price.value * multiplier;
}

The exact transformation depends on what economic unit your strategy is using, but the important design principle is:

Never let the spread engine guess how a price was produced.

The pricing adapter should make that explicit.

Robinhood also exposes corporate-action information separately, allowing applications to reconcile multiplier changes with events such as forward or reverse splits.

5. The spread is not the profit

A naive calculation is:

const spread = sellPrice - buyPrice;

A useful arbitrage engine needs to calculate something closer to:

Gross Spread
- DEX fee
- execution slippage
- gas
- protocol costs
- expected execution loss
- safety buffer
= Expected Net Edge

For example:

interface Opportunity {
  symbol: string;
  buyPrice: number;
  sellPrice: number;
  quantity: number;
  grossSpreadUsd: number;
  estimatedFeesUsd: number;
  estimatedGasUsd: number;
  expectedSlippageUsd: number;
  netEdgeUsd: number;
}

Then:

function calculateNetEdge(
  grossSpreadUsd: number,
  feesUsd: number,
  gasUsd: number,
  slippageUsd: number
): number {
  return (
    grossSpreadUsd -
    feesUsd -
    gasUsd -
    slippageUsd
  );
}

This changes the bot's decision from:

spread > 0

to:

netEdge > minimumEdge

That is a much more useful trading rule.

6. Liquidity changes the answer

A price difference is meaningless if the available liquidity cannot support the intended trade size.

For a small trade:

quoted price = executable price

For a larger trade:

quoted price ≠ actual execution price

The arbitrage engine should therefore calculate the opportunity for the actual order size.

A simple structure:

interface LiquidityCheck {
  requestedSize: bigint;
  estimatedOutput: bigint;
  priceImpactBps: number;
  sufficientLiquidity: boolean;
}

The scanner can then reject opportunities such as:

Spread:             1.10%
Expected slippage:  0.85%
Fees:               0.20%
Gas:                0.15%
--------------------------------
Net edge:          -0.10%

A scanner that reports only the first line would incorrectly call this an opportunity.

7. Trading availability needs to be part of the strategy

Another common mistake is treating every Stock Token as continuously tradable in exactly the same way.

Robinhood documents per-asset trading capabilities for market, extended, and overnight sessions. Applications are expected to check those capabilities before execution.

So the arbitrage engine should have a gate:

function canTrade(asset: StockTokenAsset): boolean {
  // Evaluate the current session against
  // the asset's trading capabilities.
  return true;
}

In a production system I would make this more explicit:

ASSET_ACTIVE
      ↓
SESSION_ALLOWED
      ↓
TRADE_ALLOWED
      ↓
OPPORTUNITY_VALID
      ↓
EXECUTION_ALLOWED

This prevents the bot from treating a data discrepancy as an executable opportunity.

8. Separate scanning from execution

I prefer a strict separation between these components:

Market Data
    ↓
Opportunity Scanner
    ↓
Risk Engine
    ↓
Execution Engine

The scanner should never directly submit transactions.

Instead:

interface TradeIntent {
  symbol: string;
  side: "BUY" | "SELL";
  amount: bigint;
  maxSlippageBps: number;
  minNetEdgeBps: number;
  createdAt: number;
}

The scanner produces the intent.

The risk engine validates it.

Only then does the executor receive it.

9. A simple risk engine

A useful risk engine can enforce:

maximum trade size
maximum position size
maximum daily loss
maximum gas cost
minimum net edge
maximum slippage
stale-data threshold
maximum concurrent trades

Example:

interface RiskLimits {
  maxTradeUsd: number;
  maxPositionUsd: number;
  minNetEdgeBps: number;
  maxSlippageBps: number;
  maxDataAgeMs: number;
}

And:

function validateOpportunity(
  opportunity: Opportunity,
  limits: RiskLimits,
  now: number,
  dataTimestamp: number
): boolean {
  const stale = now - dataTimestamp > limits.maxDataAgeMs;

  if (stale) return false;
  if (opportunity.netEdgeUsd <= 0) return false;

  const edgeBps =
    (opportunity.netEdgeUsd /
      Math.max(opportunity.buyPrice * opportunity.quantity, 1)) *
    10_000;

  if (edgeBps < limits.minNetEdgeBps) return false;

  return true;
}

The important part is that risk is a separate component.

This makes the strategy easier to test and modify.

10. Transaction execution needs states

This is where trading bots often become unreliable.

A transaction is not simply:

submit()
→ success

Real execution can look like:

SIGNAL
  ↓
RISK_APPROVED
  ↓
TX_PREPARED
  ↓
TX_SUBMITTED
  ↓
PENDING
  ↓
CONFIRMED
  ↓
POSITION_UPDATED

But there is another branch:

TX_SUBMITTED
      ↓
RPC TIMEOUT
      ↓
UNKNOWN
      ↓
RECONCILE
      ↓
CONFIRMED / FAILED / STILL_PENDING

That UNKNOWN state is important.

If an RPC request times out after the transaction was broadcast, submitting another transaction blindly can create a duplicate execution.

A basic state machine might look like:

type TxState =
  | "CREATED"
  | "SIGNED"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "FAILED"
  | "UNKNOWN";

Then the executor can transition states explicitly.

11. Position tracking should not depend only on local memory

A restart-safe bot needs durable state.

I would store something like:

trade_intent
transaction_hash
symbol
side
requested_amount
filled_amount
average_execution_price
status
created_at
updated_at

The bot can reconstruct the state after a restart:

Database
   ↓
Open transactions
   ↓
Chain verification
   ↓
Actual balances
   ↓
Actual positions
   ↓
Recovered state

This is much safer than keeping the position state only inside a running Node.js process.

12. Reconciliation is part of execution

Suppose the bot believes:

BUY 100 units

But the chain shows:

BUY 63 units

The bot's local position must eventually become:

filledAmount = 63

not:

filledAmount = 100

The reconciliation loop can periodically compare:

Local Trade State
        │
        ├── transaction receipt
        │
        ├── wallet balance
        │
        ├── token balance
        │
        └── onchain events
        │
        ▼
Canonical Position State

That gives the system a recovery path after crashes, delayed RPC responses, missed events, or partial execution.

13. Data freshness matters more than most people expect

Robinhood's Stock Token API is cached and rate-limited. The current documentation states a 60 requests/second limit across the APIs and a 15-second cache for /prices/{symbol}.

That means a bot should not interpret every API response as an instantaneous market tick.

Store the timestamp:

interface Quote {
  symbol: string;
  bid: number;
  ask: number;
  generatedAt: number;
}

Then reject stale data:

const age = Date.now() - quote.generatedAt;

if (age > MAX_QUOTE_AGE_MS) {
  return;
}

This becomes especially important when the expected arbitrage margin is small.

A stale quote can turn a theoretical edge into a real loss.

14. Project structure

For a TypeScript implementation, I would keep the system modular:

src/
├── assets/
│   ├── assetRegistry.ts
│   └── tradingCapabilities.ts
│
├── market-data/
│   ├── robinhoodApi.ts
│   ├── chainlink.ts
│   └── dex.ts
│
├── pricing/
│   ├── normalization.ts
│   ├── spread.ts
│   └── liquidity.ts
│
├── strategy/
│   └── arbitrage.ts
│
├── risk/
│   └── riskEngine.ts
│
├── execution/
│   ├── executor.ts
│   ├── transactions.ts
│   └── stateMachine.ts
│
├── portfolio/
│   └── positions.ts
│
├── reconciliation/
│   └── reconcile.ts
│
└── index.ts

This lets me test each section independently.

For example:

pricing tests
risk tests
quote tests
execution tests
reconciliation tests

before connecting everything into the live system.

15. Dry-run mode is essential

Before live execution, the bot should support:

DRY_RUN=true

In dry-run mode:

detect opportunity
        ↓
calculate executable price
        ↓
calculate expected edge
        ↓
run risk checks
        ↓
simulate transaction
        ↓
record result

But:

do not broadcast

A useful dry-run record might be:

{
  "symbol": "AAPL",
  "buyPrice": 100.12,
  "sellPrice": 101.01,
  "grossEdgeBps": 88.9,
  "estimatedCostBps": 43.2,
  "expectedNetEdgeBps": 45.7,
  "approved": true
}

This gives you something measurable before introducing execution risk.

16. Monitoring

Once the bot runs continuously, the most useful metrics are not only P&L.

I would monitor:

opportunities detected
opportunities rejected
risk rejection rate
average spread
average net edge
execution success rate
transaction latency
stale quote count
RPC errors
unknown transactions
reconciliation mismatches
realized P&L

For example:

Detected opportunities       1,284
Risk approved                   91
Executed                        37
Confirmed                       34
Unknown                          2
Failed                           1

That gives much more insight than simply looking at the wallet balance.

17. Where I would take this next

A basic Stock Token arbitrage bot can start as:

Price Scanner
      ↓
Spread Calculator
      ↓
Risk Engine
      ↓
Execution

A production system becomes:

                ┌─────────────────────┐
                │   Stock Token Data  │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Price Normalization │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Opportunity Engine  │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │    Risk Engine      │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Execution Engine    │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Transaction Monitor │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Position Engine     │
                └──────────┬──────────┘
                           ↓
                ┌─────────────────────┐
                │ Reconciliation      │
                └─────────────────────┘

That architecture can then be extended into:

multi-wallet arbitrage
automated portfolio rebalancing
opportunity dashboards
Telegram or Discord alerts
execution APIs
configurable trading strategies
historical opportunity backtesting
automated position management

18. My implementation

I built a TypeScript Stock Token arbitrage bot around this architecture for Robinhood Chain.

The implementation focuses on comparing onchain and external pricing sources, normalizing the data, evaluating executable spreads, and keeping execution separate from opportunity detection.

Repository:

[0xhamssog/robinhood-stock-token-arbitrage-bot](https://github.com/0xhamssog/robinhood-stock-token-arbitrage-bot)

The repository is also a useful starting point for extending the system into a larger trading application.

19. Building a custom Stock Token arbitrage bot

The same architecture can be scaled depending on what the project actually needs.

A small build could be:

single strategy
single wallet
basic scanner
basic execution

A medium build could add:

multiple assets
persistent state
risk management
dashboard
alerts
reconciliation

A larger system could include:

multi-wallet execution
multiple strategies
historical data
backtesting
advanced monitoring
API access
portfolio management
custom execution logic

The important part is that the trading logic should be designed around the client's actual execution requirements instead of starting with a generic "bot."

Conclusion

A Stock Token arbitrage bot is easy to describe and much harder to engineer correctly.

The price comparison is only the beginning.

The real system has to answer:

Is the data fresh?

Is the price normalized?

Is the asset tradable?

Is there enough liquidity?

Is the spread still positive after costs?

Does the trade pass risk checks?

What exactly was submitted?

What actually happened onchain?

What is the resulting position?

That is the difference between an arbitrage script and trading infrastructure.

For Robinhood Chain applications, I would treat pricing, risk, execution, state management, and reconciliation as separate engineering problems and connect them through explicit interfaces.

That makes the system easier to test, operate, and extend into a larger Stock Token trading product.

Building a Pons Trading Terminal with TypeScript: Multi-Wallet Trading and Live Execution

hamssog — Fri, 25 Sep 2026 12:48:40 +0000

A Pons trading terminal should do more than display token prices.

The useful version is an interface where a trader can manage wallets, inspect market data, preview a trade, control risk, execute transactions, monitor their status, and see the resulting position.

The goal of this article is not to repeat the architecture from my earlier Pons Trading Terminal article.

Instead, this is the implementation side:

TOKEN
  ↓
MARKET DATA
  ↓
WALLET SELECTION
  ↓
TRADE PREVIEW
  ↓
RISK CHECK
  ↓
EXECUTION
  ↓
TRANSACTION STATE
  ↓
POSITION

The current Pons documentation provides the contract and market-data integration surface for applications on Robinhood Chain, which uses chain ID 4663.

What the Terminal Needs to Solve

A trader should be able to open a token and answer three questions quickly:

What is happening?

What can I trade?

What will happen if I execute?

That means a useful terminal needs more than:

Price
Buy
Sell

A practical version should also expose:

Wallets
Balances
Liquidity
Recent trades
Quote
Slippage
Risk
Transaction status
Positions
Portfolio

The UI is the visible part.

The trading backend is responsible for making those values reliable.

1. Start With the Trading Workspace

The main trading screen can combine the most important information into one workspace:

┌──────────────────────────────────────────────┐
│ Token / Market                               │
│ Price · Liquidity · Volume                   │
├──────────────────────────┬───────────────────┤
│ Chart / Activity         │ Trade Panel       │
│                          │                   │
│                          │ Wallets           │
│                          │ Amount            │
│                          │ Slippage          │
│                          │ Risk              │
│                          │ Review            │
└──────────────────────────┴───────────────────┘

The user shouldn't need to switch between five pages just to make one trade.

2. Keep the Browser Out of the Execution Logic

The frontend should not become the blockchain execution engine.

A better structure is:

React / Next.js
       ↓
Trading API
       ↓
Execution Service
       ↓
Pons Integration
       ↓
Robinhood Chain

This keeps:

wallet state
quotes
risk
transactions
reconciliation

in the backend where they can be shared by the terminal, sniper, copy-trading system, and other automation.

This is also consistent with the architecture in my earlier Pons terminal work, where the frontend is treated as a consumer of backend trading state.

3. Wallet Selection

Multi-wallet support changes the terminal substantially.

Instead of:

Wallet
↓
Trade

the interface can provide:

☑ Wallet A
☑ Wallet B
☐ Wallet C
☑ Wallet D

and show:

Selected wallets: 3
Available balance: ...

A backend representation could be:

type TradingWallet = {
  id: string;
  address: `0x${string}`;
  enabled: boolean;
  balanceAtomic: bigint;
};

The frontend should never receive private keys.

It only receives wallet metadata and the information needed for the current workflow.

4. Select the Token

The terminal needs a clean token-selection flow.

For example:

Search token
      ↓
Resolve token
      ↓
Load market state
      ↓
Open trading workspace

The market view can show:

Symbol
Price
Liquidity
Volume
Pool / market
Recent trades
Launch information

For current Pons v1 markets, the official documentation describes token-specific pools and provides the integration data needed to resolve pool and token state. Pons v2 is a separate bonding-curve architecture and should be handled as a different execution mode.

That distinction matters when building the terminal backend.

5. Build a Trade Preview

Before a transaction is sent, the user should be able to see what the system intends to do.

Example:

TRADE PREVIEW

Token:
MEMESTOCK

Wallets:
A, B, D

Side:
BUY

Total input:
0.09 ETH

Expected tokens:
...

Minimum tokens:
...

Slippage:
1%

Estimated gas:
...

Risk:
PASS

The user then clicks:

REVIEW TRADE

and only after that:

CONFIRM

This gives the terminal a human-readable execution checkpoint.

6. Quote and Risk Are Different

The quote answers:

What do I approximately receive?

The risk engine answers:

Am I allowed to do this?

For example:

Quote
$800

but:

Maximum trade
$500

The trade should be reduced or rejected.

The same applies to:

maximum position
portfolio exposure
slippage
price impact
available balance

A useful separation is:

Trade Request
     ↓
Quote
     ↓
Risk Decision
     ↓
Execution

The UI can then show:

Quote       ✓
Balance     ✓
Position    ✓
Slippage    ✓
Risk        APPROVED

7. Keep Units Explicit

Trading terminals have to deal with multiple units.

I would keep them separate in TypeScript:

type TokenAmount = bigint;
type QuoteAmount = bigint;
type BasisPoints = bigint;

For example:

type TradePreview = {
  tokenAmount: TokenAmount;
  quoteAmount: QuoteAmount;
  slippageBps: BasisPoints;
};

This prevents a common class of mistakes where blockchain atomic units are accidentally mixed with human-readable dollar values.

The UI can convert values for display.

The backend should keep exact values internally.

8. Multi-Wallet Execution

Suppose the user selects:

Wallet A → 0.02 ETH
Wallet B → 0.02 ETH
Wallet D → 0.05 ETH

The terminal should create separate execution records.

Wallet A
   ↓
Transaction A

Wallet B
   ↓
Transaction B

Wallet D
   ↓
Transaction D

The terminal should not assume that these transactions are one atomic operation.

This distinction is especially important when the terminal is later connected to the Pons bundler workflow, where the launch transaction and additional wallet transactions have different execution characteristics.

9. Track Every Transaction Separately

The UI should show live state:

Wallet A     ✓ Confirmed
Wallet B     ● Pending
Wallet D     ✕ Failed

A useful backend model:

type ExecutionStatus =
  | "CREATED"
  | "PREVIEWED"
  | "SUBMITTED"
  | "PENDING"
  | "CONFIRMED"
  | "FAILED"
  | "UNKNOWN";

Then the frontend simply subscribes to execution state.

This is much more useful than returning only:

{
  "success": true
}

10. Transaction State Should Survive Refreshes

Suppose the user closes the browser immediately after clicking Buy.

When they return, the terminal should still know:

Order:
0x1234...

Status:
PENDING

The browser should not be the source of transaction state.

The backend should persist it.

Transaction
    ↓
Database
    ↓
API
    ↓
Frontend

This is one of the reasons I prefer treating execution as a service rather than a React component.

11. RPC Timeouts Need Their Own State

An RPC timeout should not automatically be rendered as:

FAILED

A transaction may already have been submitted.

The terminal should be able to show:

UNKNOWN

and then reconcile.

RPC timeout
     ↓
UNKNOWN
     ↓
Check transaction
     ↓
Confirmed / Failed

This makes the interface more truthful and reduces the risk of users or automation resubmitting the same trade unnecessarily.

12. Position Updates Come After Execution

The terminal should not update the position merely because the user clicked Confirm.

The actual position flow is:

Trade request
     ↓
Transaction
     ↓
Receipt / onchain result
     ↓
Position update

For example:

Requested:
100,000 TOKEN

Actual result:
96,420 TOKEN

Position:
96,420 TOKEN

The terminal should display the actual state.

13. Portfolio State

Once positions are available, the terminal can aggregate them.

Example:

Portfolio

MEMESTOCK       $4,320
TOKEN X         $2,145
TOKEN Y         $1,890
WETH            $3,210
-----------------------
Total          $11,565

Then:

Wallet A    $4,100
Wallet B    $3,700
Wallet D    $3,765

This lets the same product function as both a trading interface and portfolio dashboard.

14. Transaction History

The terminal should retain a complete execution history:

Time
Wallet
Token
Side
Amount
Status
Transaction

Example:

09:42
Wallet A
MEMESTOCK
BUY
0.02 ETH
Confirmed

09:43
Wallet B
MEMESTOCK
BUY
0.02 ETH
Pending

Clicking the transaction should expose the onchain transaction reference.

This gives the user an audit trail.

15. Live Data

The trading interface should not require a manual browser refresh after every event.

A useful setup is:

Blockchain
    ↓
Indexer
    ↓
Backend State
    ↓
WebSocket / SSE
    ↓
Trading Terminal

The terminal can then update:

price
trades
wallet activity
transaction status
positions

in near real time.

The earlier Pons Launch Monitor article already established this data layer as a reusable source for the trading terminal, sniper, copy trading, and analytics.

That is why the terminal should consume the data layer rather than rebuild it.

16. Manual Trading and Automated Trading

One useful design choice is allowing the same execution infrastructure to support different entry points.

Manual:

User
 ↓
Trade Panel
 ↓
Risk
 ↓
Execution

Copy trading:

Wallet Signal
 ↓
Copy Strategy
 ↓
Risk
 ↓
Execution

Sniper:

Launch Signal
 ↓
Sniper Strategy
 ↓
Risk
 ↓
Execution

All three can update:

Transactions
Positions
Portfolio
Alerts

The terminal becomes the control surface.

17. Alerts

A terminal should notify users about meaningful state changes.

For example:

Trade confirmed
Transaction failed
Position changed
Wallet activity detected
Risk limit reached

The notification layer can support:

Web
Telegram
Discord
Webhook
Email

The same service can later be reused by the Pons wallet tracker and copy-trading system.

18. Risk Controls in the UI

Risk settings should be visible and configurable.

For example:

Maximum trade:
$1,000

Maximum position:
$5,000

Maximum slippage:
1%

Maximum price impact:
3%

Daily allocation:
$10,000

The terminal can show:

Risk Status

Trade size       ✓
Balance          ✓
Position         ✓
Slippage         ✓

READY

This makes risk understandable to users who aren't reading backend logs.

19. A Better Terminal for Different Clients

Not every client needs the same product.

Simple terminal

Wallet
Token
Buy
Sell
Positions

Multi-wallet terminal

Wallet groups
Bulk trading
Allocation
Execution monitoring
Portfolio

Sniper terminal

Launch feed
Token filters
Entry controls
Automated execution

Copy-trading terminal

Tracked wallets
Copy settings
Signals
Risk
Execution

Full trading platform

Markets
Trading
Wallets
Strategies
Risk
Positions
Portfolio
Analytics
Alerts

The same engineering foundation can support all of these.

20. From MVP to Full Product

A client does not have to build everything on day one.

A practical MVP:

Wallets
Token Search
Token Page
Buy / Sell
Transaction History
Positions
Portfolio

Then add:

Multi-wallet
Risk Controls
Alerts
Automation
Copy Trading
Sniper
Analytics

This lets a project start with a smaller scope and grow as requirements become clearer.

21. Suggested Backend Structure

A reusable backend can separate:

src/
├── market/
├── wallets/
├── quotes/
├── risk/
├── execution/
├── transactions/
├── positions/
├── portfolio/
├── alerts/
└── api/

The frontend can then remain focused on:

routes
components
state
charts
forms
tables

rather than protocol-specific transaction logic.

22. Connecting the Terminal to the Existing Pons Stack

This is where the earlier articles become useful.

Your current Pons content already covers:

Launch Monitor → data

Wallet Tracker → wallet activity

Copy Trading → strategy

Sniper → launch strategy

Bundler → multi-wallet execution

The terminal can become the interface connecting those capabilities:

Pons Data
   ↓
Trading Terminal
   ├── Manual Trading
   ├── Sniper
   ├── Copy Trading
   ├── Bundler
   └── Portfolio

That creates a much stronger product story than treating every article as a standalone project.

23. The Development Opportunity

A client may already have:

A trading bot

but no interface.

Or:

A dashboard

but no reliable execution backend.

Or:

An MVP

but no multi-wallet support.

Or:

A strategy

but no portfolio/reconciliation layer.

The terminal can be built around whichever part is missing.

That means a custom project doesn't always need to start from zero.

24. What I Would Build

For a full Pons terminal, I would aim for:

Market Discovery
+
Wallet Management
+
Trade Preview
+
Risk Controls
+
Execution
+
Transaction Monitoring
+
Positions
+
Portfolio
+
Alerts

Then connect optional strategy modules:

Sniper
Copy Trading
Bundler
Automation

This provides one interface while keeping the underlying systems modular.

Final Takeaway

A Pons trading terminal should be more than a dashboard.

It should be the interface through which a user can:

Discover
Trade
Manage Wallets
Control Risk
Monitor Transactions
Track Positions
Manage Portfolio

The most useful implementation pattern is to keep the terminal itself relatively thin:

Frontend
    ↓
Trading API
    ↓
Market / Risk / Execution
    ↓
  Pons
    ↓
Robinhood Chain

That lets the same backend support manual trading, sniper strategies, copy trading, bundling, and future automation.

The terminal then becomes the product layer sitting above your existing Pons infrastructure.

Custom Pons Trading Terminal Development

I build custom Pons and Robinhood Chain trading products, including:

Pons trading terminals
Multi-wallet trading interfaces
Pons sniper dashboards
Pons copy-trading platforms
Pons bundlers
Wallet analytics
Risk and execution systems
Portfolio dashboards
Trading APIs

Projects can start from an idea, an existing bot, an existing codebase, or an MVP and expand into a larger trading platform.

The objective is to build the terminal around the client's workflow—not force the client into a generic trading interface.

Pons Bundler: Building Multi-Wallet Launch Execution on Robinhood Chain with TypeScript

hamssog — Thu, 24 Sep 2026 08:19:11 +0000

A Pons bundler is easy to misunderstand.

It is not an ERC-4337 UserOperation bundler.

For Pons v2, the practical meaning is a launch-automation tool that creates a token, performs the opening buy, and coordinates additional wallet buys during the launch's early curve-trading window.

I built a TypeScript implementation around that workflow:

GitHub:
0xhamssog/pons-bundler

The repository targets Pons v2 on Robinhood Chain, using launchAndBuy for the launch plus initial buy and separate bonding-curve buy() transactions for additional wallets. The repository currently supports wallet generation and funding, dry runs, launching, buying, selling, and sweeping.

The interesting engineering problem is not "how do I send several transactions?"

It is:

How do I coordinate several wallets while the same bonding curve is changing underneath them?

What Makes a Pons Bundler Different?

The basic Pons v2 lifecycle is:

TOKEN CONFIG
     ↓
  LAUNCH
     ↓
OPENING BUY
     ↓
ADDITIONAL WALLET BUYS
     ↓
POSITION STATE

The important detail is that these operations are not all one atomic transaction.

The current repository documents the model clearly:

```text id="db02"
Master wallet
↓
launchAndBuy()
↓
Token + curve created
↓
Buyer A → buy()
Buyer B → buy()
Buyer C → buy()




Robinhood Chain is treated as FCFS, and there is no atomic multi-signer transaction across the additional wallets.

That changes how the implementation needs to be designed.

---

## Pons v2 Starts on a Bonding Curve

Pons v2 starts with curve trading and later graduates into Uniswap v4.



```plaintext
CREATE
  ↓
BONDING CURVE
  ↓
TRADING
  ↓
CURVE COMPLETION
  ↓
UNISWAP V4

That means the opening buys are curve transactions, not normal post-graduation swaps.

The Pons documentation also makes the launch phase explicit, so a bundler should treat the curve phase and post-graduation phase as different states.

1. Configure the Launch

A launch needs structured parameters.

For example:

type LaunchConfig = {
  name: string;
  symbol: string;
  pairToken: `0x${string}`;

  launchConfigId: bigint;

  masterBuy: bigint;
  eachWalletBuy: bigint;

  creatorFeeRecipient: `0x${string}`;
  creatorTaxBps: bigint;
};

Keeping these values together makes the launch process easier to validate before the first transaction is sent.

The repository also keeps the master wallet separate from the generated buyer wallets.

2. Prepare the Buyer Wallets

A multi-wallet workflow needs explicit wallet management.

The reference implementation supports:

npm run pons -- wallets generate \
  --count 8 \
  --out wallets.json

and funding:

npm run pons -- wallets fund \
  --file wallets.json \
  --each 0.02

The repository supports up to 32 additional wallets as Pons v2 snipe-tax exemptions. wallets.json contains private keys and is gitignored.

For a real deployment, private keys should be treated as sensitive infrastructure rather than ordinary application configuration.

3. Why `launchAndBuy` Matters

The first important protocol operation is launchAndBuy.

Without it:

Launch
   ↓
Wait
   ↓
Opening buy

There is a window between the two transactions.

With launchAndBuy:

launchAndBuy
      ↓
CREATE + INITIAL BUY
      ↓
ONE TRANSACTION

The current Pons v2 documentation describes launchAndBuy as a separate router operation that creates the launch and performs the first buy in a single call. This closes the gap between launch creation and the creator's initial purchase.

That is the first major piece of the bundler.

4. Additional Wallets Are Still Separate Transactions

This is the part that makes the word "bundler" potentially confusing.

The master wallet can launch and buy atomically.

Additional wallets cannot all be included as signers in that same transaction.

Instead:

launchAndBuy()
       ↓
Buyer A → buy()
Buyer B → buy()
Buyer C → buy()
Buyer D → buy()

Those are separate transactions.

The repository explicitly documents this behavior and describes the additional buys as parallel curve transactions.

So the application is coordinating transaction submission.

It is not creating atomic multi-wallet execution.

5. Opening Snipe-Tax Exemptions

Pons v2 applies an opening buy tax that starts very high and decays quickly.

The current protocol documentation says the tax starts at 99% and decays toward zero over the first five seconds. The launching address and creator fee recipient are automatically exempt, and additional exemption addresses can be specified when the launch is created.

For a team launch, the flow can therefore be:

Launch
   ↓
snipeTaxExemptions
   ↓
Buyer A
Buyer B
Buyer C
...

The exemption list is fixed when the launch is created and can contain up to 32 extra addresses.

That is an important implementation detail because the wallets need to be known before the launch transaction is constructed.

6. Build the Launch Transaction

Conceptually, the router call looks like:

const hash = await wallet.writeContract({
  address: launchAndBuyRouter,
  abi: routerAbi,
  functionName: "launchAndBuy",

  args: [
    tokenParams,
    launchConfigId,
    pairToken,
    quoteIn,
    minTokensOut,
    recipient,
    buyerWallets,
  ],

  value: launchValue,
});

The key arguments are:

tokenParams
launchConfig
pair asset
initial buy
minimum output
recipient
extra exemptions

The recipient is important because Pons v2's opening-tax logic is wallet-specific.

The Pons documentation also notes that creatorFeeRecipient needs to be explicit for launchAndBuy.

7. `minTokensOut` Still Matters

The launch transaction is only the first step.

The initial buy needs an expected output and minimum acceptable output.

Conceptually:

Curve State
    ↓
  Quote
    ↓
Expected Tokens
    ↓
Slippage
    ↓
minTokensOut

The Pons bundler repository calculates minTokensOut using the curve's official pricing state and applies configurable slippage.

That means the launch cannot simply say:

buy 0.1 ETH

and accept whatever number of tokens comes back.

The transaction should protect the expected output.

8. Quote the Curve, Not a Generic DEX

Pons v2 uses a bonding curve.

The quote needs the curve's pricing reserves and fee state.

The repository describes its quote logic as using:

getReserves()
+
fees
+
slippage

rather than relying on a generic router quote.

A useful internal type is:

type CurveQuote = {
  quoteIn: bigint;
  expectedTokensOut: bigint;
  minTokensOut: bigint;
  slippageBps: bigint;
};

This keeps quote generation separate from transaction construction.

9. The Curve Changes Between Wallets

This is one of the most interesting implementation problems.

Suppose:

Wallet A → 0.02 ETH
Wallet B → 0.02 ETH
Wallet C → 0.02 ETH
Wallet D → 0.02 ETH

They all target the same launch curve.

But each successful buy changes the curve state.

So:

Curve State T0
    ↓
Wallet A trade
    ↓
Curve State T1
    ↓
Wallet B trade
    ↓
Curve State T2
    ↓
Wallet C trade

The bundler therefore has to consider:

quote
+
slippage
+
transaction ordering
+
changing curve state

The repository documents this directly: parallel buys move the curve, so each transaction is protected by a configurable slippage limit.

This is one of the main reasons a multi-wallet launch tool is more complicated than a loop around sendTransaction().

10. Run a Launch in Dry-Run Mode

The bundler supports dry-run execution.

For example:

npm run pons -- launch \
  --name "Example" \
  --symbol EXMPL \
  --master-buy 0.1 \
  --file wallets.json \
  --each-buy 0.02 \
  --dry-run

The dry-run path lets the application validate the launch without broadcasting it.

That creates a useful workflow:

Configuration
    ↓
Wallet validation
    ↓
Launch checks
    ↓
  Quote
    ↓
Simulation
    ↓
  Review

For automated trading infrastructure, dry-run should be a real execution mode rather than a logging shortcut.

11. Check the Launch Gate

Public launching on Pons v2 can be gated.

The current repository checks canLaunch before spending gas. The project documentation explicitly recommends reading that value on every run rather than assuming the public launch gate remains open.

The flow is simple:

Launch requested
       ↓
   canLaunch?
    /      \
   NO      YES
   ↓        ↓
Stop     Continue

This is a good example of querying current contract state immediately before execution.

12. The Additional Buys

After the master transaction creates the launch, the buyer wallets can execute their own purchases.

Conceptually:

for (const wallet of buyerWallets) {
  await submitBuy(wallet, {
    token,
    quoteIn: wallet.buyAmount,
    minTokensOut: wallet.minTokensOut,
    recipient: wallet.address,
  });
}

The production implementation should not treat this simple loop as the final design.

The important concerns are:

per-wallet nonce
quote freshness
gas balance
transaction status
failure handling
retry policy

The repository submits the additional curve buys separately and supports them in parallel.

13. Track State Per Wallet

Because the additional transactions are independent, state should also be tracked independently.

For example:

Wallet A
  submitted
  confirmed

Wallet B
  submitted
  confirmed

Wallet C
  submitted
  failed

Wallet D
  pending

One aggregate status is not enough.

A useful execution record:

type WalletExecution = {
  wallet: `0x${string}`;

  status:
    | "CREATED"
    | "SUBMITTED"
    | "CONFIRMED"
    | "FAILED"
    | "UNKNOWN";

  txHash?: `0x${string}`;

  requestedAmount: bigint;
  executedAmount?: bigint;
};

This lets the application answer:

Which wallets actually completed their buys?

14. Don't Treat Parallel Transactions as Atomic

A multi-wallet launch can produce mixed outcomes.

For example:

Launch TX       CONFIRMED

Buyer A TX      CONFIRMED
Buyer B TX      CONFIRMED
Buyer C TX      FAILED
Buyer D TX      PENDING

The application must represent that state honestly.

There is no single rollback that undoes the successful transactions.

So:

Coordination
≠
Atomicity

This is an important product-level distinction when describing a Pons bundler to users or clients.

15. Nonces Need Per-Wallet Coordination

Every buyer wallet has its own nonce sequence.

That means nonce management can be isolated:

Wallet A
  nonce 10
  nonce 11

Wallet B
  nonce 4
  nonce 5

Wallet C
  nonce 28
  nonce 29

A single global nonce lock would be the wrong abstraction.

Use one transaction queue or nonce manager per wallet.

That also makes retries easier to reason about.

16. Monitor Transaction Results

After submission, the transaction manager should track:

Created
↓
Submitted
↓
Pending
↓
Confirmed / Failed

Do not immediately assume that:

writeContract()

means the desired position exists.

The actual transaction receipt and resulting wallet state should be checked afterward.

17. Handle Partial Curve Fills

The final curve buy can behave differently from a normal buy when the launch is approaching completion.

If the requested purchase exceeds the remaining curve capacity:

Requested:
1 ETH

Remaining:
0.6 ETH

the result can be:

Partial fill
+
Refund

The position manager therefore needs to use the actual transaction result rather than blindly storing the requested amount.

This is another reason transaction state and portfolio state should remain separate.

18. Reconciliation

After the transactions settle, the application should inspect the actual wallet state.

For each buyer:

Requested buy
      ↓
Transaction
      ↓
Receipt / events
      ↓
Actual token balance
      ↓
Reconciled position

This can answer:

Did the wallet buy?
How much did it receive?
How much ETH remains?
Did the transaction fail?
Is the local state correct?

For a multi-wallet product, this becomes one of the most important operational features.

19. Buy, Sell, and Sweep

The reference implementation is not limited to launch creation.

It also provides:

npm run pons -- buy \
  --token 0x... \
  --file wallets.json \
  --each-buy 0.02

Selling:

npm run pons -- sell \
  --token 0x... \
  --file wallets.json \
  --percent 100

And sweeping:

npm run pons -- wallets sweep \
  --file wallets.json

That gives the CLI a larger lifecycle:

Prepare
  ↓
Launch
  ↓
Buy
  ↓
Manage
  ↓
Sell
  ↓
Sweep

20. Security

Multi-wallet automation increases the security surface.

At minimum:

Private keys
    ↓
Encrypted / protected storage
    ↓
Transaction signer

The repository keeps wallets.json gitignored and warns against committing it. It also recommends a configured RPC endpoint instead of relying on the rate-limited public RPC for production use.

For a larger client deployment, I would also separate:

Development secrets
Production secrets
Signing infrastructure
Application configuration
Audit logs

The bundler should never log private keys.

21. Reference Implementation

The complete implementation is available here:

Pons Bundler — TypeScript

Open the GitHub repository

The current repository contains:

Pons v2 support
launchAndBuy
Up to 32 extra exemption wallets
Wallet generation
Wallet funding
Dry-run launch
Parallel wallet buys
Buy / sell commands
Wallet sweeping
Curve quotes
Slippage protection
Transaction handling

It is specifically a Pons v2 launch bundler, not an ERC-4337 bundler.

22. Bundler vs Sniper

These products should remain separate in your codebase and marketing.

Bundler

YOUR LAUNCH
    ↓
YOUR WALLETS
    ↓
COORDINATED BUYS

Sniper

OTHER LAUNCH
    ↓
DETECTION
    ↓
FILTER
    ↓
QUOTE
    ↓
   RISK
    ↓
   BUY

The two systems can share:

Wallet handling
Curve quote logic
Transaction manager
Risk controls
Reconciliation

But the product objectives are different.

23. Where This Can Go Next

The CLI can become the backend for a larger Pons application.

For example:

Pons Bundler
      ↓
Wallet Management
      ↓
Launch Templates
      ↓
Allocation Engine
      ↓
Execution Monitor
      ↓
Portfolio

A web product could then expose:

Launch configuration
Wallet groups
Per-wallet allocation
Dry-run preview
Live execution
Transaction status
Position tracking
Sell rules
Sweep
Audit history

The underlying transaction infrastructure can remain the same.

Final Takeaway

The main engineering challenge in a Pons bundler is not sending many transactions.

It is coordinating a launch workflow where:

Launch creation
      ↓
Initial buy
      ↓
Multiple separate buys
      ↓
Changing curve state
      ↓
Different transaction outcomes
      ↓
Reconciliation

The most important technical distinctions are:

launchAndBuy gives the master wallet an atomic launch + initial buy.

Additional buyer wallets are separate transactions.

Snipe-tax exemptions are configured at launch creation.

Parallel purchases interact with a changing bonding curve.

And each wallet needs independent transaction state.

That is what makes a Pons bundler a real multi-wallet execution system rather than just a script that loops through addresses.

Custom Pons Development

I build custom Pons and Robinhood Chain infrastructure, including Pons bundlers, sniper bots, copy-trading systems, wallet trackers, launch monitors, trading terminals, token scanners, risk engines, and automated execution systems.

Existing implementations can be extended with dashboards, wallet groups, custom allocation rules, execution monitoring, automated exits, APIs, and client-specific strategy logic.

Reference implementation:
0xhamssog/pons-bundler