How all of it works.

Installation

FlipTrainer is a Manifest V3 Chrome extension. Installing takes under a minute and you sign in with Google.

Requirements

• Google Chrome 88 or later, or any Chromium-based browser
• A Google account for sign-in

Steps

First steps

Signing in for the first time sets your account up completely — there is no onboarding wizard to sit through.

What happens on first login

• A virtual trading balance is credited so you can trade immediately
• A real Solana wallet (Ed25519) is generated for your account and encrypted at rest
• A starting grant of credits is added, which pays for copy-trading actions

Making the first trade

Glossary

The trench vocabulary — the words you'll meet in every memecoin chat, chart and Telegram group, and what they actually mean.

Basics

Dangers & scams

Trading

Culture & slang

How trading works

Training mode mirrors real trading mechanics closely enough that the results mean something. Prices are live, fills are simulated against real program logic, and the market's costs are deducted.

Price data

Prices stream from a Solana validator over gRPC (Yellowstone / Geyser). Pump.fun and Pump AMM activity is decoded on the backend and every token is priced from its on-chain bonding-curve or pool reserves — the same marginal price your terminal shows, with no polling delay.

How a fill is computed

Your trade is executed against the real pump.fun or Pump AMM program bytecode running inside an in-process Solana VM, with the pool's mainnet state cloned in. The fill price is read out of the trade event the program emits — not estimated from a formula.

A useful consequence: price impact is inherent, not bolted on — a large order walks the curve as it fills.

If the VM is unavailable the system falls back to constant-product math, where the average fill is derived from the pool's SOL reserve: a buy fills at spot × (1 + amount / R), a sell at spot / (1 + amount / R).

P&L

P&L = (exitPrice − entryPrice) × positionSize − commission

All money math uses high-precision decimals, so nothing drifts through rounding.

Live updates

While a position is open the panel receives price updates over a persistent event stream and your unrealized P&L updates on its own. Update frequency follows on-chain activity — a quiet token ticks less often than a busy one.

Migration

When a bonding curve completes and the token migrates to the AMM, open positions are re-keyed to the new pool automatically.

Opening positions

Find a token, pick a size, confirm. The entry price is captured at the moment you confirm.

Closing positions

Close whenever you like. The exit is priced at the live on-chain price at that moment.

Three ways to close

• One position — the Close button on that row.
• Everything — the close-all control in the positions header.
• Part of it — sell 10%, 50%, 90% or 100% to take profit or trim risk while keeping the rest open.

Afterwards

• Proceeds land back in your balance
• The trade moves to history with full entry and exit detail
• The realized P&L and win-rate cards update

Commission

Simulated trades are charged what a real trade would have cost. Without that, every strategy looks better on paper than it performs on-chain — which defeats the point of practising.

In training mode

Both are deducted on entry and on exit, exactly like the real thing.

Worked example

Open position:    10.000 SOL
Open commission:  -0.090 SOL   (0.9%)
Effective entry:   9.910 SOL

Token price +20%
Close value:      11.892 SOL
Close commission: -0.107 SOL   (0.9%)
Net received:     11.785 SOL

Net P&L:          +1.785 SOL   (+17.85%)

On-chain trades

Rates are stored in the on-chain program's config account. The client sends only a route identifier — it cannot declare a rate. The fee base is your side of the trade: on a buy it is the SOL amount you submit (taken out of it before the swap — you spend exactly what you entered), on a sell it is the SOL you actually receive after the swap. The program transfers the fee straight to a platform wallet.

On-chain mode

The mode toggle at the top of the Trade tab switches the same interface from virtual SOL to real SOL. Orders are signed by your FlipTrainer wallet and executed on Solana.

What changes

• Amounts are real SOL, taken from your primary wallet
• Positions and history come from a separate on-chain ledger — the two are never mixed
• Trades your wallet made outside the extension still show up, because positions are rebuilt from chain events rather than from what the app remembers doing
• There is no simulation: fills are whatever the network gives you

Limits

• Manual buy size is capped per transaction as a safety rail
• Trading requests are rate-limited per account
• USDC-quoted pools are supported for trading; some reporting features convert them via the live SOL/USD rate

Watching wallets

Add any Solana address on the Copy tab, give it a tag, and every matching transaction it makes lands in your activity feed within a moment of hitting the chain.

Managing the list

• Search across addresses and tags
• Pause a single wallet with the eye toggle, or pause all of them at once
• Import up to 200 wallets in one request — the format is Axiom's own tracked-wallet export, so an existing list transfers as-is
• Export back out in the same format

Your terminal

One terminal is active for your whole account — Axiom, GMGN or Padre — chosen in the extension popup. Every link the app opens for you, from alerts to activity rows, points at that terminal.

Events & filters

Each watched wallet has its own configuration: which events to react to, how to filter them, and what should happen when one fires.

Event types

All four are available on every account.

Filters

Filters are set per event type, and a trade has to pass all of them:

Market caps are entered in thousands of dollars.

What an event can do

• Log it — always on, free.
• Open the token in your terminal the moment it fires.
• Trade on it — one direct action per event, Buy or Sell; see Trading on events.
• Run a blueprint — start your strategy graph on the caught token (on-chain mode only).

Trading on events

Watching a wallet tells you what it did. A trade action lets the event act on its own: attach Buy or Sell to any event type, and the moment it fires the trade goes through on your side. One action per event — picking Buy clears Sell and the other way round.

Buy sizing

• Specify amount — every buy uses the same size you set.
• Mirror wallet amount — match the wallet one-to-one, copying the SOL size it traded.

Sell sizing

• Specify percent — sell that share of your remaining position.
• Mirror wallet amount — sell the same SOL value the wallet cashed out. Nothing to sell (no position yet) is a normal skip, not an error.

Buy times

On the token-purchase event you can wait for the wallet's N-th matching buy of a token before acting: from that buy onwards every further buy triggers the action (enable Trigger once to act a single time). The condition gates the whole event, so a blueprint bound to it waits for the same signal.

Which mode it runs in

The global TRAINING / ON-CHAIN switch is stamped into the wallet when you press SAVE: training trades are virtual and land in your normal trade history, on-chain trades are signed with your own wallet. Flipping the switch later does not change saved wallets — re-save to move one.

Launching a token

The Deploy tab launches a pump.fun token from inside the extension, signed by the wallet you choose.

The form

Name and ticker limits are measured in bytes, so non-Latin characters and emoji are counted correctly.

Options

• Mayhem mode — launch into the pump.fun Mayhem arena.
• Cashback — enable trading cashback on the coin.
• Pair with USDC — a USDC-quoted curve instead of SOL. This forces the dev buy to zero.

Vamp, archive & batch

Vamp

Vamping means launching a copy of a coin that's currently pumping — same name, same ticker — to siphon off its buyers and attention. FlipTrainer puts a pair of bat buttons on every card in the live feed of a supported terminal and on token headers:

• Clone into Deploy — scrapes the name, ticker, image and socials and pre-fills a draft, so you can edit before you launch.
• Instant deploy — one click, no confirmation, real SOL: metadata upload through to mint.

What that click does is set by the Vamp switch in the injected settings panel, Manual or Blueprint. Manual takes a buy size — zero means create only — and the wallet that mints; leave the wallet on Main (auto) to use your primary. Blueprint hands the launch to a strategy graph instead: its deploy node creates the token and decides the buy size and the minting wallet, so neither field applies. The selector lists deploy-type blueprints only. Pick a graph before you click — on Blueprint with none selected the button refuses rather than quietly minting a bare token.

Your browser never downloads the source image. The server fetches it from an allowlist of CDN hosts, validates the real file type from its bytes rather than its claimed type, and caches it — trending tokens get vamped repeatedly.

Archive

Draft pages survive panel closes and tab switches, but not a browser restart. The archive button stores a draft permanently instead, with the image, every field, both option sets, the dev buy, the wallet and the blueprint. Archived tokens are listed newest first with their age; deploy straight from the record or delete it.

The point is preparation: build a shelf of finished tokens while you're calm, and launch one the moment a narrative appears.

Batch

The tab bar holds up to eight draft pages, each a complete token. Click to open one; Ctrl+click to mark it active. Deploying with several active launches them in sequence, showing progress as it goes and finishing on a summary that lists each ticker with its result.

Mints & bundling

Vanity mint addresses

Launches draw from a pool of pre-generated keypairs whose address ends in pump, so your token carries the authentic suffix. Each key is claimed atomically and used once. If the pool is ever empty the launch falls back to a random address rather than failing.

Metadata

Images and the metadata JSON are hosted on our own storage and served from our own CDN, not through a third-party IPFS gateway. Keys are content-addressed, so re-uploading the same image doesn't create a second copy.

The image is written first and the metadata second — an orphaned image is harmless, metadata pointing at a missing image is not. Both are then verified over the public URL, because a successful write doesn't prove a successful public read. A background health check runs continuously; if storage is unhealthy the launch is refused rather than shipping a URI that will 404 forever.

Atomic create + snipe

Through a blueprint's deploy node, the launch and its snipes ship as a single bundle:

• tx0 — the creator's transaction: create the token, plus the dev buy.
• tx1…N — snipe buys from up to three more wallets, built against a curve that doesn't exist yet. Because the accounts are derived locally, these legs cost no network round-trips to construct.

The bundle executes in order, so the snipes see the curve tx0 just created, and the whole thing lands atomically or not at all. Four wallets total, every leg must buy something, and duplicate wallets are rejected. Retries use a fresh blockhash each attempt.

Launch history

The history toggle on the Deploy page lists past strategy runs with the P&L of each launch: invested SOL, realized SOL, total and percentage.

How it's calculated

• Attribution is structural — only the legs the graph actually executed are counted, using the real fills the trades reported.
• Sells you made elsewhere count too. If you dumped from Phantom while the run was live, the launch's P&L still knows about it.
• Only finished runs appear. The remaining position is valued at the last price seen when the run ended, and the number is frozen there.
• Network and platform fees are excluded from the figure.

Honest gaps

Unknown values render as a dash rather than a fake zero, and two situations are flagged explicitly: contaminated when more tokens were sold than the graph bought, and missing fills when a leg's amounts never came back. USDC-quoted launches report no P&L at all, because the fill data for them doesn't carry a SOL figure to compute one from.

How a blueprint run works

A blueprint is a graph you draw in the builder. Saving it compiles the canvas into a strategy definition; running it hands that definition to a service that executes it against live chain data. Every trade a blueprint makes is a real on-chain trade.

Blueprint types

Every blueprint has a type, picked in the builder's top-right corner. Deploy graphs start from the Deploy page or a Vamp click and must contain a deploy node — it lives only in this type. Trade graphs run manually on a token from the floating window. Copy graphs start from wallet-event bindings on the Snipe page; to clone a launch, a copy graph fires a Spawn node that starts a separate deploy blueprint while the graph itself keeps trading the whale's token. Each picker lists only blueprints of its own type, and the server refuses a mismatched start.

It doesn't need your browser

The run's position in the graph and its working memory are written to the database at every pause, so closing the tab changes nothing and a service restart resumes exactly where it stopped. If the service went down in the middle of sending trades, the run stops and reports that — it will not blindly re-fire them.

Branches run side by side

A Parallel node splits the run into independent branches: each carries its own position and its own clock, so one can sit on a price or PnL watch while another keeps trading. The node continues once every branch has finished. Branches can reach into each other — a watcher wired into a loop's break input stops that loop from the outside.

Skipped is not failed

A leg with nothing to sell, or a share that rounds to zero, is skipped: no transaction is sent, the reason is recorded, and the graph continues. This makes a useful idiom safe — sell 100% → delay → sell 100% is a retry, because sell is a percentage of what's actually left. The second one either finishes the job or does nothing at all.

Failure handling

Trade nodes have two exec outputs, success and fail. Wire the fail output and the run follows it and stays alive. Leave it unwired inside a loop and the run moves to the next iteration. Leave it unwired outside a loop and the run ends as failed.

Triggers

• Manual — run a saved trade blueprint on the current token from the floating window's Blueprints list.
• On launch — attach a deploy blueprint on the Deploy page. The graph's own deploy node mints the token, binds to the pool the moment it exists, and trades from there.
• On wallet events — bind a copy blueprint to a watched wallet's events on the Snipe page; the graph starts on the token the event was about.

Watching a run

The instances panel polls every few seconds and shows status, the legs executed with their signatures, the addresses of any throwaway wallets the run created, and a cancel button.

Limits

Wallets & pins

Wallet nodes aren't part of the execution flow. You wire them into a trade node's wallet pins, and the amount for each wallet lives on the edge you drew — so one Buy node can trade from several wallets at once, each with its own size.

One Wallet node can hold a whole list of wallets, managed in its Settings panel. Every edge you draw from it then acts for each wallet in the list: a node with two or more wallets plugged into the bundle pin is a valid bundle by itself, and on the deploy pin the first wallet of the list is the creator.

The two wallet pins on Buy and Sell

Both pins run concurrently; neither waits for the other.

The copy pin (copy graphs only)

The two pins on Deploy

Exec outputs

• 🟢 Success — taken when the node's legs executed. Skipped legs count as success.
• 🔴 Fail — taken when a leg fails.
• ▶ Path — one per branch on a Parallel node; every wired path starts its own branch.

Throwaway wallets

A Create Wallet node generates a fresh keypair every time the graph runs. It exists only inside that run, it doesn't consume one of your saved wallet slots, and there's no key export for it — so the graph itself has to sweep the funds back to a real wallet before it finishes. Fund it with a Send node, trade from it, sweep it home.

Node reference

Every node in the palette, and what it does. Select a node on the canvas and the same description appears in the builder's sidebar.

Where alerts arrive

FlipTrainer can reach you in three places. The activity log inside the side panel and browser push notifications work from the start; Telegram is opt-in and has to be connected once.

Connecting Telegram

1. Open the extension, go to your profile and press the Telegram icon in the LINKS row.
2. Our bot opens in Telegram — press START.
3. The icon in the profile turns blue: the chat is linked.

The blueprint builder has the same link: select a Notify node and press Connect Telegram in the description panel on the left.

The link is per account, and one Telegram chat belongs to one FlipTrainer account. To disconnect, send /unlink to the bot or press the icon in the profile again. Blocking the bot in Telegram disconnects it too.

What we can send to Telegram

A message from a Notify node carries the name of the graph, the text you typed into the node, and a link to the token in your terminal — whichever of Axiom, GMGN or Padre you picked in the profile.

Your wallet

Every account gets a real Solana wallet, created silently the first time you sign in. It pays for on-chain trades, launches, credits and tips.

Multiple wallets

You can hold a main wallet plus up to ten more. Import an existing key or create new ones from the wallet page — nothing is ever replaced or deleted, so a new wallet is always an addition.

Mark any wallet as primary with the star. The primary wallet signs manual on-chain trades, shop payments and withdrawals, and its address is your deposit address. The activity toggle on each row controls whether its balance counts toward the total at the top — it's a display preference, stored locally.

What you can do per wallet

• Rename it inline
• Export its private key
• Open it on Solscan
• Withdraw from it to any address, including a MAX mode that drains it exactly, network fee accounted for

Rewards

The Rewards tab of the side panel collects everything your wallets have earned in one click: pump.fun creator fees from tokens you launched, cashback, and the rent still locked in empty token accounts left behind after selling. It sweeps every wallet on the account and returns the SOL to whichever wallet earned it; accounts that can't be safely closed are left alone.

Funding your wallet

You need real SOL to trade on-chain, launch tokens, buy credits or tip.

Security

FlipTrainer wallets are custodial. The server holds your private key encrypted and signs on your behalf — which is why trading, paying and launching never interrupt you with a wallet popup. This page explains exactly what that means, because it's the most important trade-off in the product.

Why custodial?

FlipTrainer started self-custodial — the key lived on your device and the client signed everything. We moved custody to the server because the features this product is actually about are impossible any other way:

• Blueprints run without you. A graph keeps trading with your tab closed and your computer off. A key that only exists on your device can't sign a trade at 4am while you sleep.
• Copy trading is a race. Reacting to a whale's trade is worth doing only within milliseconds. A round-trip to your device — let alone a wallet popup — loses that race every time.
• Atomic bundles need every signature at once. A multi-wallet Jito bundle is built and signed as one unit, in one place, against one blockhash. That place has to be the server.
• No popups, ever. Manual trades, payments and launches go through without a confirmation dialog interrupting the moment.

The honest cost of that speed is custody, and the rest of this page spells it out — including the export path below that keeps you free to leave at any moment.

How the key is protected

keyMaterial   = HMAC-SHA256(serverPepper, userID)
encryptionKey = HKDF(SHA-256, keyMaterial, randomSalt, "fliptrainer-wallet-v1")
              → 32-byte AES-256-GCM key

The encrypted key, its IV and its salt are stored in the database. The serverPepper is a secret held only in the server's environment and never written to the database.

What that buys you

The trade-off, stated plainly

Because the server can decrypt your key, the operator is technically capable of signing with it. There is no cryptographic guarantee against that — only the fact that it isn't done. If that isn't acceptable to you, don't leave meaningful balances here.

Account security

• Sign-in is Google OAuth, verified server-side against Google before any session is issued
• Sessions use short-lived access tokens plus a refresh token that rotates on every use — an old refresh token stops working the moment it's used once
• Signing out revokes the session server-side, not just in your browser

Credits

Credits are the internal currency, and they exist for one part of the product: the copy-trading actions that cost us work to run for you. There are no subscription tiers, no auto-renewal and nothing to cancel — every purchase is one-time.

What costs credits

New accounts start with a grant of credits, so there's nothing to buy before you can try everything.

Running out

If your balance hits zero, all watched wallets pause rather than silently dropping events. Top up and they come back within a minute.

Trading balance top-ups

The trading balance tile converts credits into virtual SOL, delivered instantly with no on-chain transaction involved.

Paying with SOL

Packs are priced in dollars and paid on-chain in SOL from your FlipTrainer wallet, at the rate quoted when you buy. No cards, no payment processor.

Price movement

The SOL price is pinned when you're quoted. If the market moves more than a few percent before you confirm, you're re-quoted rather than charged the stale amount. Money that has already been sent is never rejected over a small wiggle.

If something is interrupted

The payment is recorded before it is broadcast, so a crash can never leave a sent transaction unaccounted for. Anything left unfinished is picked up by a background reconciler with a 24-hour window, and the extension resumes a pending purchase on its own after a restart. Retrying a purchase is safe — each one carries an idempotency key, so you can't be charged twice.

Tips & support

The Tip tile supports development with a SOL donation, and doubles as the contact form. Either way the message reaches the author by email with your address attached, so you get a reply.

Two ways to send

Just want to get in touch?

You don't have to donate. Choose copy address, write your message and send — the author gets your note and your email with no payment involved. Messages are short by design, up to 32 characters, so keep it to a sentence and expect the conversation to continue over email.