DogeX Migration Client

DogeX (DOGEX) (0xf57f...a111) was a highly anticipated and successful meme token project on Binance Smart Chain that launched in late 2021. I was brought on as a third-party developer to create and execute the migration process (backend and frontend). This was my first time working as a crypto developer -- and the very first time I had ever coded in or learnt JavaScript, which was a couple minutes speedrun.

The token went through three generations. The main developer was responsible for producing the smart contracts, which featured mechanics that would cause honeypot characteristics under certain circumstances -- necessitating each migration:

• V1 -- The original launch token. Liquidity was eventually locked due to contract limitations.
• V2 -- A successor contract deployed to address V1's issues. Its liquidity was later locked as well.
• V3 -- The final token contract, still the current version. Required a full migration from V1 and V2 holders.

I handled the migration infrastructure for each transition. This repository is the final iteration of the migration service -- the culmination of every phase, handling both V1 to V3 and V2 to V3 swaps in a single unified system.

Because the old token liquidity was locked in their respective contracts, a traditional smart contract swap wasn't possible. Instead, this system uses an off-chain migration flow: holders send their legacy tokens to the project wallet, and a backend daemon dispatches the equivalent V3 tokens automatically.

This project represents the first coding work I ever did professionally.

How It Works

A 3-step migration flow that securely swaps legacy V1/V2 DogeX tokens for V3 tokens:

1. Eligibility Check -- User connects their wallet; the system verifies they hold legacy tokens via a Moralis snapshot.
2. Send Legacy Tokens -- User transfers their old V1/V2 tokens to the DogeX owner wallet. The amount is capped at their snapshot balance.
3. Receive V3 Tokens -- A backend daemon automatically dispatches V3 tokens at the determined conversion rate.

Setup

Frontend

npm install
npm start

Node.js Server

cd server && npm install
npm run server

Python Services

Each Python service (rest_api/, autosend/, autoswap/, form_examiner/) follows the same pattern:

cd <service>
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python3 <script>.py

Environment Variables

Copy .env.example to .env and fill in the required values. See the example file for all configuration options.

Architecture

User Browser (React + Web3Modal)
     |
     |-- POST /api/eligibility
     |-- POST /api/submit_migration
     v
Node.js Server (Express)
     |
     |-- Moralis API (snapshot/current balance)
     |-- Python Flask API (migration records)
     v
MySQL Database
     |
     |-- autosend (daemon: sends V3 tokens)
     |-- autoswap (daemon: sells received V1/V2 on PancakeSwap)
     |-- form_examiner (daemon: processes Google Form responses)

Component	Tech	Description
src/	React, Chakra UI, Web3.js	Frontend migration interface
server/	Express, Axios	API middleware for eligibility and migration
rest_api/	Flask	Migration record storage REST API
autosend/	Python, Web3.py	Daemon that dispatches V3 tokens
autoswap/	Python, Uniswap SDK	Daemon that auto-sells received legacy tokens
form_examiner/	Python, Pandas	Processes Google Form migration requests
shared/	Python	Shared constants, utilities, database layer, and vendored Uniswap SDK

Migration Flow

Step 1 -- Eligibility

The holder connects their wallet and the system checks against a blockchain snapshot to verify token holdings.

Step 2 -- Token Transfer

The user sends their legacy tokens to the owner wallet. The amount is capped at their snapshot balance.

Step 3 -- V3 Dispatch

The autosend daemon reads pending migrations from the database and dispatches V3 tokens automatically.

License

MIT License. See LICENSE for details.

Author

Built by Xipz