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