Skip to main content
TLDR:
  • This tutorial demonstrates an investigative approach to automate token swaps on an unverified Uniswap V2–based DEX.
  • It shows how to retrieve the router and LP addresses by decompiling the bytecode, scanning transactions, and decoding input data.
  • Once identified, a round-robin swapping script is built in Python to continuously swap among multiple tokens, including handling approvals.
  • By automating these swaps, developers can farm points and streamline their testnet usage.

Introduction

On the Sonic testnet, you can do daily tasks that include swaps of a set of the official ERC-20 tokens dispersed from the Sonic faucet. The DEX has the UI but no instructions on how to automate the swaps (obviously). The contract involved in the swap is not verified, which means we have no contract source and don’t have the contract ABI, which in turn adds another obstacle in achieving our objective. This guide is a quick & fun walkthrough on how to approach the problem, investigate it, and ultimately achieve the automatic swaps.

Get your own reliable Sonic RPC endpoint today

Deploy a reliable Sonic RPC endpoint to get started.Start for free and get your app to production levels immediately. No credit card required.You can sign up with your GitHub, X, Google, or Microsoft account.

The problem

Going to the swap, account, faucet (all in one place) page, you can see that what you can do there is:
  • Request different testnet coins (CORAL, ONYX, and so on)
  • Swap them in the interface
But you of course don’t want to do any of that manually, so let’s FAFO and try to automate the coin swapping. Will implement a round-robin approach in which can just continuously swap coins to farm points.

Investigate

Once you have requested all the coins for swapping, do a sample swap. As a reminder, here’s he swap, account, faucet. The sample swap transaction will reveal an unverified contract address for which you have no source (which is understandable — why publish it and let people farm). Here’s the address: 0x086D426f8B653b88a2d6D03051C8b4aB8783Be2b . The explorer is a paid implementation by the etherscan, a team that produces the best explorers in the world. It was very nice of the Sonic team do run an etherscan version, which is extremely convenient in everything, including a built-in decompiler. So just go ahead on the Contract tab, hit the Decompile Bytecode button. This will produce a bunch of output, including a familiar name—UniswapV2Library. So, it’s Uniswap V2 fork, which means 0x086D426f8B653b88a2d6D03051C8b4aB8783Be2b is likely the router address. And any token exchange going through the router does the actual exchange on an LP address for the token pair. And we already know the token addresses, since they are in the faucet and you can request them. And you can also look through all the exchanges going on there on the address: 0x086D426f8B653b88a2d6D03051C8b4aB8783Be2b and see that the function signature used for the swaps is 0xddba27a7. To be able to script the actual swaps, we need the LP addresses of the tokens. Here’s what we know so far:
  • Router (a modification of Uniswap V2): 0x086D426f8B653b88a2d6D03051C8b4aB8783Be2b
  • Token addresses on the faucet:
    • DIAM: 0x30BF3761147Ef0c86E2f84c3784FBD89E7954670
    • CORAL: 0xAF93888cbD250300470A1618206e036E11470149
    • FLE: 0x9Fa14D267d331c9E8BB7979bcDC212136915eCE8
    • MACH: 0x50971F8978C431D560ff658a83a8a03fdf199055
    • OBS: 0x3e6eE2F3f33766294C7148bc85c7d145E70cBD9A
    • ONYX: 0xE73c4f6A0A3B0EF8337fD080b76C08172b3eB958
  • A token swap involves at least four addresses:
    • Router
    • TokenA
    • TokenB
    • LP address Knowing that, let’s create a Python script that scan through blocks for transactions the router address and our token addresses and prints the LP address associated with each swap:
Make sure you put:
  • RPC_URL — the actual Sonic Blaze testnet endpoint URL that you can get from Chainstack.
  • START_BLOCK — go for eg 300 blocks in the past
The script will keep running until it finds the LP addresses. It will print something like this:

Implementation

Now that we have the LP addresses, and we know this is actually a modified Uniswap V2 contract, let’s implement a round-robin swap:
  1. It swaps 1 ONYX to 1 CORAL. LP Address: 0x7D5bE487743F73264D6aA4Ae202B6103078cD1a8
  2. Then it swaps 1 CORAL to 1 OBS. LP Address: 0xD7D04d8A33b6E6EB42a2e0e273e0fe1F23f818fD
  3. Then it swaps 1 OBS to 1 ONYX. LP Addresss: 0xCE1c63381b03bd5f227C1cCfa71c5E93154f336F
  4. And it starts all over again (1 ONYX to 1 CORAL and so on)
Also don’t forget that we need token approvals and token approval checks to do the actual swaps.
Make sure you put:
  • RPC_URL — the actual Sonic Blaze testnet endpoint URL that you can get from Chainstack.
  • PRVATE_KEY — the key that holds the tokens you are going to swap.
  • CYCLES — how many cycles to run. 0 for infinite.
  • AMOUNT — the amount of each token to keep swapping.
  • DELAY — if you want to add a bit of a delay there and not keep blasting the swaps like a bot (which you are).

Conclusion

And there you have it. We’ve walked you through on how to make your life easier though FAFO. And honestly the sort of people that can investigate and automate this for points are the type of people that network onboarders may want — active and capable developers.

About the author

Ake

Ake Director of Developer Experience @ Chainstack
Talk to me all things Web3
20 years in technology | 8+ years in Web3 full time years experience
Last modified on June 22, 2026