DEV Community

Cover image for Building a Pons Copy-Trading System on Robinhood Chain
Casatrick | Polymrket Bot Dev
Casatrick | Polymrket Bot Dev

Posted on

Building a Pons Copy-Trading System on Robinhood Chain

#web3 #tradingbot #robinhood #defi

Copy trading sounds simple:

Find a wallet.
Watch what it does.
Do the same thing.

In practice, that's not a copy-trading system.

A useful system has to answer much harder questions:

  • What exactly did the wallet do?
  • Was it a buy or a sell?
  • What asset and pool were involved?
  • Is the activity real, complete, and recent?
  • Should this wallet actually be followed?
  • Should this particular trade be copied?
  • How much exposure is acceptable?
  • What happens when the source trade only partially executes?
  • What happens when the data is stale?
  • What happens when execution fails?
  • How do you reconcile the resulting position?

That's the part I'm interested in building.

I've already been working on the infrastructure underneath Pons on Robinhood Chain, starting with a TypeScript SDK and a historical event-indexing layer.

Now I'm taking the next step:

turning onchain wallet activity into a structured copy-trading research system.

The important distinction is that this is being designed in layers.

Onchain Events
      ↓
SDK / Indexer
      ↓
Wallet Activity
      ↓
Wallet State
      ↓
Trade Detection
      ↓
Filtering
      ↓
Risk
      ↓
Copy-Trade Signal
      ↓
Execution
Enter fullscreen mode Exit fullscreen mode

The execution layer comes last.

Why build the infrastructure first?

The obvious way to approach copy trading is to start with a bot.

Watch a wallet.

See a transaction.

Send another transaction.

That can make for a quick demo.

It is not how I want to build the system.

The foundation for this work is my Pons SDK on Robinhood Chain, which handles the contract and event layer.
I've already built the first Pons SDK layer around the actual Robinhood Chain contracts and onchain events. The foundation connects to the live network, supports Pons V1/V2 contract interaction, and decodes real TokenLaunched events.

The test baseline is currently:

30/30 unit tests
3/3 live integration tests
Enter fullscreen mode Exit fullscreen mode

That matters because the application layer should not have to reinvent the blockchain layer.

The same infrastructure should eventually support:

Pons
 ↓
SDK
 ↓
Indexer
 ↓
Market / wallet state
 ↓
Scanner
Copy trading
Analytics
Other automation
Enter fullscreen mode Exit fullscreen mode

Build the data layer once.

Reuse it everywhere.

The core architecture

The copy-trading system I'm designing has several distinct layers.

┌──────────────────────┐
│   Robinhood Chain    │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│   Pons Contracts     │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ SDK / Event Layer    │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Historical / Live    │
│       Indexer        │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│    Wallet State      │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│   Trade Detection    │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│      Filtering       │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│        Risk          │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│   Copy-Trade Signal  │
└──────────┬───────────┘
           ↓
┌──────────────────────┐
│ Execution Adapter    │
└──────────────────────┘
Enter fullscreen mode Exit fullscreen mode

Each layer has one job.

That makes the system easier to test, debug, and extend.

1. Start with wallet activity

A copy-trading system needs a reliable representation of what a wallet is doing.

At the domain level, I want something closer to:

interface WalletActivity {
  wallet: Address;
  token: Address;
  pool?: Address;

  side: "buy" | "sell";

  amountToken?: bigint;
  amountQuote?: bigint;

  blockNumber: bigint;
  transactionHash: Hash;
  logIndex: bigint;

  timestamp?: string;

  source: "pons";
}
Enter fullscreen mode Exit fullscreen mode

The important part isn't the TypeScript syntax.

It's the normalization.

Raw blockchain events shouldn't leak into every downstream component.

The rest of the system should be able to consume something simple:

wallet X bought token Y

without having to understand every ABI detail.

2. Wallet state is different from wallet activity

An event tells me:

Something happened.

Wallet state tells me:

What do I currently think is happening?

Those are different things.

For example:

Wallet A

Token X
quantity: ...
average entry: ...
recent activity: ...
Enter fullscreen mode Exit fullscreen mode

The state layer can eventually support questions such as:

  • What does this wallet currently hold?
  • When did it enter?
  • Has it recently increased exposure?
  • Is this a new position?
  • Is it reducing an existing position?

But I don't want to calculate information that the underlying data cannot support accurately.

A good data model should make uncertainty explicit instead of inventing precision.

3. Trade detection

The next layer is the TradeDetector.

Its job is deliberately narrow:

Convert normalized wallet activity into a copy-trade candidate.

Conceptually:

WalletActivity
      ↓
TradeDetector
      ↓
TradeCandidate
Enter fullscreen mode Exit fullscreen mode

For example:

interface TradeCandidate {
  wallet: Address;
  token: Address;

  side: "buy" | "sell";

  amountToken?: bigint;
  amountQuote?: bigint;

  blockNumber: bigint;
  transactionHash: Hash;
  logIndex: bigint;

  timestamp?: string;
}
Enter fullscreen mode Exit fullscreen mode

The detector should not decide whether the trade is worth copying.

That's the next layer.

Separating those decisions makes the system much easier to reason about.

4. Don't copy every trade

This is probably the most important difference between a simple script and a real copy-trading system.

A wallet can make many transactions that shouldn't be copied.

Maybe the trade is too small.

Maybe the token is excluded.

Maybe the wallet isn't on the watchlist.

Maybe the signal is stale.

Maybe your current exposure is already too large.

So the next component is a filter.

Trade Candidate
      ↓
   Filter
      ↓
Approved / Rejected
Enter fullscreen mode Exit fullscreen mode

A policy might eventually include:

interface CopyTradePolicy {
  allowedWallets?: Address[];
  excludedTokens?: Address[];

  minTradeSize?: bigint;
  maxTradeSize?: bigint;

  maxSignalAgeSeconds?: number;
}
Enter fullscreen mode Exit fullscreen mode

The important thing is that the decision should be explainable.

For example:

APPROVED

✓ wallet allowed
✓ token allowed
✓ trade size valid
✓ signal recent
Enter fullscreen mode Exit fullscreen mode

Or:

REJECTED

✗ token excluded
Enter fullscreen mode Exit fullscreen mode

That makes the system much easier to debug.

5. Risk should be a separate layer

Filtering asks:

Should I consider this trade?

Risk asks:

Even if I want to consider it, can I safely take this exposure?

Those are different questions.

The architecture becomes:

Trade
 ↓
Filter
 ↓
Risk
 ↓
Signal
Enter fullscreen mode Exit fullscreen mode

Possible risk controls include:

  • maximum position size
  • maximum token exposure
  • maximum portfolio exposure
  • maximum number of simultaneous positions
  • stale-signal protection
  • token deny lists
  • wallet-specific limits

The strategy is trying to find opportunities.

The risk engine is trying to keep the system alive.

They should not be the same component.

6. Why execution should be separate

This is where many trading-bot architectures become difficult to maintain.

The signal engine shouldn't directly send a transaction.

Instead:

CopyTradeSignal
       ↓
Execution Adapter
       ↓
Actual execution
Enter fullscreen mode Exit fullscreen mode

That separation allows the same signal engine to support:

research

paper execution

simulation

live execution

without rewriting the entire system.

For the initial implementation, I want execution disabled.

The system should be able to produce:

COPY SIGNAL

Wallet:
0x...

Token:
0x...

Side:
BUY

Reason:
Approved wallet
Valid trade
Within risk limits
Enter fullscreen mode Exit fullscreen mode

without sending anything.

That's a much safer place to start.

7. The execution problem is harder than copying

Imagine a source wallet buys 10,000 units.

A naive system says:

Buy 10,000.

But the market might have changed.

There might not be enough liquidity.

The source transaction may have executed at a very different price.

Your available capital may be different.

Your own risk limits may reject the position.

That's why I think about copy trading as:

Source Trade
      ↓
Interpretation
      ↓
Filtering
      ↓
Risk
      ↓
Your own Trade Decision
      ↓
Execution
Enter fullscreen mode Exit fullscreen mode

Copying the decision is not necessarily the same as copying the transaction.

That distinction becomes increasingly important as the system gets more sophisticated.

8. Latency matters

A copy-trading system is fundamentally time-sensitive.

There is a chain of events:

Source wallet trades
        ↓
Blockchain event
        ↓
Node observes event
        ↓
Indexer processes event
        ↓
System detects trade
        ↓
     Filter
        ↓
      Risk
        ↓
    Execution
Enter fullscreen mode Exit fullscreen mode

Every step adds latency.

That makes the event/data layer part of the trading system itself.

This is one reason I started with the SDK and indexing infrastructure instead of starting with execution.

Before optimizing the trade:

measure the pipeline.

9. Historical indexing comes before real-time copying

The architecture I'm building follows a deliberate sequence.

First:

Historical events
     ↓
Indexed state
Enter fullscreen mode Exit fullscreen mode

Then:

Historical state
     +
Live events
     ↓
Real-time state
Enter fullscreen mode Exit fullscreen mode

Then:

Real-time wallet state
     ↓
Trade detection
Enter fullscreen mode Exit fullscreen mode

Then:

Trade detection
     ↓
Copy-trade signals
Enter fullscreen mode Exit fullscreen mode

Only after those pieces work reliably does live execution become interesting.

Otherwise you're just putting a transaction sender on top of uncertain data.

10. Reconciliation is mandatory

Suppose your system decides to copy a trade.

You submit the execution.

What happened?

Maybe it filled.

Maybe it partially filled.

Maybe it failed.

Maybe it was delayed.

Maybe your local process restarted.

The system therefore needs reconciliation.

Local Position
      ↕
External State
      ↓
Reconciliation
      ↓
Correct Position State
Enter fullscreen mode Exit fullscreen mode

This matters just as much for copy trading as it does for an ordinary trading bot.

A successful API request is not automatically equivalent to a successful position change.

11. Copy trading needs observability

One question the system should always be able to answer is:

Why did I copy this trade?

For every signal, I want a trail like:

Wallet:
0x...

Source transaction:
0x...

Token:
0x...

Detected:
12:41:03.221

Filter:
APPROVED

Risk:
APPROVED

Signal:
GENERATED

Execution:
NOT ENABLED
Enter fullscreen mode Exit fullscreen mode

That turns debugging from guesswork into investigation.

And it becomes useful for analytics later.

12. The same infrastructure can power other products

This is one of the main reasons I'm building the system this way.

The underlying data layer shouldn't exist only for copy trading.

The same indexed state can support:

          Pons Data Layer
                ↓
      ┌─────────┼─────────┐
      ↓         ↓         ↓
   Scanner   Copy Trade  Analytics
      ↓         ↓         ↓
      └─────────┼─────────┘
                ↓
         Automation
Enter fullscreen mode Exit fullscreen mode

And eventually:

bundling

launch monitoring

sniping

other trading automation

The application changes.

The infrastructure underneath it doesn't have to.

13. Why start with Pons?

Pons gives me a concrete protocol to build against while exploring Robinhood Chain.

The immediate goal isn't to build a “Pons bot.”

It's to develop reusable infrastructure around a real onchain application:

Contracts
   ↓
 Events
   ↓
 State
   ↓
Applications
Enter fullscreen mode Exit fullscreen mode

If the architecture is kept modular, Pons can become the first adapter rather than the permanent boundary of the project.

That's important for the longer-term direction.

14. What I'm building now

The current progression is:

[x] Robinhood Chain connection
[x] Pons V1/V2 contract integration
[x] TokenLaunched decoding
[x] Historical launch queries
[x] SDK tests
[x] Live RPC integration tests

→ Historical indexing
→ Persistent state
→ Real-time events
→ Wallet intelligence
→ Copy-trade research
→ Paper execution
→ Live execution
Enter fullscreen mode Exit fullscreen mode

I'm intentionally keeping the execution layer at the bottom.

The data needs to be trustworthy first.

15. What I don't want to optimize prematurely

I don't want to jump directly into:

“How fast can I copy a transaction?”

before answering:

“Do I actually know what happened?”

There are several places where a system can make a wrong decision before execution ever happens:

bad data

stale state

incorrect event interpretation

wrong wallet classification

bad filtering

oversized position

unhandled failure

That is why the architecture matters more than the first bot demo.

16. The architecture I'm aiming for

The longer-term system looks something like:

                    ROBINHOOD CHAIN
                           │
                      PONS / DEX
                           │
                      Event Stream
                           │
                          SDK
                           │
                        Indexer
                           │
                      Market State
                           │
              ┌────────────┼────────────┐
              ↓            ↓            ↓
        Wallet Data     Token Data   Pool Data
              │            │            │
              └────────────┼────────────┘
                           ↓
                     Intelligence
                           │
             ┌─────────────┼─────────────┐
             ↓             ↓             ↓
          Scanner      Copy Trading   Analytics
             │             │             │
             └─────────────┼─────────────┘
                           ↓
                         Risk
                           ↓
                       Execution
                           ↓
                    Reconciliation
Enter fullscreen mode Exit fullscreen mode

The point is not to create one giant bot.

It's to create a reusable trading infrastructure layer.

17. The bigger goal

The interesting thing about copy trading isn't the copying itself.

It's the system around it.

Reliable data.

Correct state.

Decision boundaries.

Risk controls.

Execution.

Reconciliation.

That's the engineering problem I'm interested in.

The Pons SDK was the first layer.

The indexer is the next.

Copy trading is one of the first real applications that can sit on top.

And if the architecture works, the same foundation can power scanners, analytics, bundlers, sniping systems, and other Robinhood Chain automation without rebuilding the entire stack each time.

Build the infrastructure first. Then let the applications prove what it's useful for.

The implementation lives in the Pons/Robinhood Chain trading-tools repository

Top comments (0)