Backend and Frontend developer on Node.js/TypeScript token parser pumpfun or bonk

1. Dev Migration Logic

• If the address has had at least one migrated token, then all its subsequent tokens:

  • automatically open in the browser (Google Chrome);

  • automatically open in the Axiom terminal.

• Works for tokens with Pump.fun and Bonk.

• The condition triggers up to a certain percentage (the threshold is set by the user in the web application).

• Metric F - data is collected on how much total commission (trading fees) was paid when creating the token.

2. Community Admin

• Each token with a community has its own admin (for example, elonmask).

• For the first token of the new admin, the software collects basic metrics.

• For subsequent tokens, the data is supplemented and recalculated.

• Metrics:

  • TT - total number of tokens created by the admin;

  • ALLAM - median amount of maximum market cap across all tokens;

  • AM - median of maximum market cap for the last 5 tokens;

  • Last 5 tokens - stored with clickable names and links to Axiom (to view each token and its value 24K maximum cap);

  • F - commission paid by traders in tokens.

• After the token's death, its values are fixed and added to calculations (to be displayed in the list of the last 5).

3. Ban System

• The software remembers all admins and devs.

• Metrics are counted even for banned ones.

• The BAN button adds the admin or dev address to the blacklist (file).

• Two separate folders:

  1. Dev Migration

  2. Community Admin

• Banned ones are not displayed in the info board and are not purchased, but their data remains in the database for statistics.

4. New Pair Checker (Community Admin)

• Tracks new tokens on Pump.fun and Bonk.

• Checks if the admin has had migrations.

• If the token = LAST MIGRATION, a notification is displayed on the info board.

• Also, the token is automatically opened in Axiom (Chrome).

5. Info Board: Blocks

• DEV MIGRATION:

  • token image (new),

  • name + ticker,

  • last 5 tokens (links),

  • F (trader commission),

  • % purchase by devs,

  • % purchase by snipers.

• COMMUNITY ADMIN:

  • token image (new),

  • name + ticker,

  • admin nickname,

  • metrics: ALLAM, AM, TT, last 5 tokens and values 20K maximum market cap of the 5 tokens (links),

  • F (trader commission),

  • % purchase by devs,

  • % purchase by snipers.

• LAST COMMUNITY MIGRATION:

  • token image (new),

  • name + ticker,

  • admin nickname,

  • F from the previous migrated token.

6. Settings (web application → software)

• General parameters:

  • Dev Migration threshold (%).

  • Community limit (for example, 10–12 people).

  • Auto-opening for community admin based on market cap value (for example, 20K).

  • AM threshold (based on the last 5 tokens) at which auto-purchase is activated.

  • The BAN button works across all categories (Dev Migration, Community Admin, Last Migration).

  • Loading and playing sound notifications when auto-purchase is triggered
    
    

• Auto-purchase:

  • wallet for purchase,

  • purchase amount,

  • commission (manual input),

  • switches:

    • enable/disable Pump.fun,

    • enable/disable Bonk,

    • both enabled → work on both,

    • both disabled → do not purchase.

• Web application:

  • 4 separate applications → connected to one database;

  • each can have different wallets/settings;

  • the database of admins and devs is shared;

  • bans are local (managed manually).

7. Ready Transaction via Jito

• For each web application, it is formed in advance.

• Logic:

  • data is collected on admins: TT, ALLAM, AM, last 5 market caps, F;

  • if the new token meets the specified conditions (for example, AM ≥ 20K), then mint is inserted into the ready transaction and sent without delay.

• Goal: to reduce the delay between the appearance of the token and the purchase, to maximize the chance of being in the same block with the dev.

8. Community Size Check

• The software checks the number of people in the community.

• If the limit (for example, 10–12) is exceeded, then:

  • do not open,

  • do not purchase, even with good AM metrics.

9. Operating Modes

• AFK Mode (background):

  • checks new pairs only by Community Admin,

  • data collection: ALLAM, AM, TT, last 3 tokens,

  • without auto-purchase and auto-opening,

  • works continuously.

• START Mode (combat):

  • activated manually,

  • full functionality (auto-opening, auto-purchase, etc.),

  • uses the collected database.

• Control:

  • button to start/stop AFK mode,

  • button to start/stop START mode.

10. Additional Folders (Dashboard)

• Folder #1: admin nickname (for example, elonmask) + signature (for example, TOP ADMIN / HOLD).

• Folder #2: dev wallet migration (for example, 3bHqLAMq...pump) + signature (for example, TOP DEV / HOLD).

• For these folders, auto-purchase works regardless of metrics (every time the specified admin/dev creates a new token).
  
  I already have part of the backend code uploaded to my GitHub, I can also fully explain and show a video example of how a similar project works for a complete understanding of how this should be implemented.