DEV Community

Cover image for Pons Bundler: Building Multi-Wallet Launch Execution on Robinhood Chain with TypeScript
hamssog
hamssog

Posted on Originally published at hamssog.substack.com

Pons Bundler: Building Multi-Wallet Launch Execution on Robinhood Chain with TypeScript

#typescript #blockchain #robinhood #tradingbot

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

and funding:

npm run pons -- wallets fund \
  --file wallets.json \
  --each 0.02
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

There is a window between the two transactions.

With launchAndBuy:

launchAndBuy
      ↓
CREATE + INITIAL BUY
      ↓
ONE TRANSACTION
Enter fullscreen mode Exit fullscreen mode

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()
Enter fullscreen mode Exit fullscreen mode

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
...
Enter fullscreen mode Exit fullscreen mode

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,
});
Enter fullscreen mode Exit fullscreen mode

The key arguments are:

tokenParams
launchConfig
pair asset
initial buy
minimum output
recipient
extra exemptions
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

rather than relying on a generic router quote.

A useful internal type is:

type CurveQuote = {
  quoteIn: bigint;
  expectedTokensOut: bigint;
  minTokensOut: bigint;
  slippageBps: bigint;
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The bundler therefore has to consider:

quote
+
slippage
+
transaction ordering
+
changing curve state
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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,
  });
}
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
};
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

The application must represent that state honestly.

There is no single rollback that undoes the successful transactions.

So:

Coordination
≠
Atomicity
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Do not immediately assume that:

writeContract()
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

the result can be:

Partial fill
+
Refund
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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?
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Selling:

npm run pons -- sell \
  --token 0x... \
  --file wallets.json \
  --percent 100
Enter fullscreen mode Exit fullscreen mode

And sweeping:

npm run pons -- wallets sweep \
  --file wallets.json
Enter fullscreen mode Exit fullscreen mode

That gives the CLI a larger lifecycle:

Prepare
  ↓
Launch
  ↓
Buy
  ↓
Manage
  ↓
Sell
  ↓
Sweep
Enter fullscreen mode Exit fullscreen mode

20. Security

Multi-wallet automation increases the security surface.

At minimum:

Private keys
    ↓
Encrypted / protected storage
    ↓
Transaction signer
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Sniper 

OTHER LAUNCH
    ↓
DETECTION
    ↓
FILTER
    ↓
QUOTE
    ↓
   RISK
    ↓
   BUY
Enter fullscreen mode Exit fullscreen mode

The two systems can share:

Wallet handling
Curve quote logic
Transaction manager
Risk controls
Reconciliation
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)