Whitepaper

The meme token market has no shortage of venues. What it lacks is a complete path that carries a user from attention to settlement — and that path should not require surrendering a private key.

This page is a thesis, not a status report. What is actually shipping is on What is live and Limitations.

1. Market Structure

Since 2024, the cost of issuing a meme token has fallen to near zero. A single individual can create a liquid, tradeable asset with a price curve in under a minute. The direct consequence is that the supply of assets now grows faster than anyone’s attention.

The market has split into three categories of tooling, each addressing one segment of the lifecycle:

Category	Solves	Does not solve
Launchpads	How to create a token	What happens after creation
Trading terminals	How to buy and sell	How to create, how to exit
Bots	How to be fast	Whose keys provide the speed

All three categories serve the same users. A participant who launches a token today, snipes tomorrow, and receives a group-chat pitch the day after must move between three to five interfaces, each with its own wallet, its own balances, and its own history. No single surface can answer: “Am I net positive on memes this month?”

This fragmentation is not a product problem; it is a market structure problem. It will persist until someone connects the four segments.

2. The Four Segments

Discovery  ──►  Issuance  ──►  Automation  ──►  Exit

Discovery. A tweet, a new pool, a wallet’s movement. Value exists only in the first few dozen seconds; after that, it is public information.

Issuance. From an idea to a tradeable asset. Competition has shifted from “whether it can be done” to how precisely an issuer can set taxes, distributions, deflation, and liquidity seeding.

Automation. Conditional buys, laddered sells, activity-sustaining volume. The least mature segment: available solutions are either hard-coded scripts or require handing over a private key.

Exit. Selling, claiming creator fees, settlement. The most neglected segment, and the only one that actually determines profit and loss.

A product that covers only one segment is capped by that segment. A product that connects all four is capped by the total time users spend on memes.

3. Custody as the Dividing Line

There is an apparently unavoidable tension between automation and custody: to trade while the user is absent, someone must be able to sign while the user is absent.

The industry’s prevailing answer is to let servers hold decryptable keys. That answer works, and the experience advantage it buys is real.

We chose the other answer, and we consider its cost acceptable:

• The server schedules; it does not sign. The server determines what an automation task should do now; the user’s browser determines whether to do it and how.
• The cost is that tasks require an open page. We do not obscure this: if a client stops polling beyond a threshold, the task marks itself stalled rather than silently doing nothing.
• What this buys is a verifiable property: even if all of our servers were compromised, an attacker could not move user assets, because no material capable of signing exists on the servers.

This is not a claim of moral superiority. It is a trade-off. Custodial tools currently process far more volume. Non-custody is a reason we survive longer, not a weapon for beating competitors.

4. The Truth About Speed

“Fast” is over-mythologized in this market. Broken down, the latency of a snipe consists of four components:

Component	Who can optimize it	Headroom
Information arrival	Data sources and subscription methods	Large
User decision	Interface and shortcuts	Large
Transaction construction	Local computation	Small
On-chain landing	Submission path and bidding	Medium

The real gap is in the first two, not the third. Shaving milliseconds off construction is meaningless when pressing a button takes hundreds of milliseconds.

That understanding decides where engineering effort goes: getting the signal onto the screen, and making the next action obvious — not celebrating serialization micro-benchmarks.

5. Correctness as a Product Feature

Failure modes in meme trading tools rarely look like “an error was thrown.” More often:

• A transaction is submitted but fails silently on-chain because the accounts are wrong
• A sell is missing a field, and every sell fails to deserialize
• The user’s node lags; a transaction that has already landed is reported as failed, and the user double-submits
• A fee is deducted in the interface and never transferred

None of these produce a clean error. Their symptoms are “occasionally doesn’t go through” and “something feels off.”

The response we hold ourselves to:

• Instruction encoding is checked against real mainnet transactions, not against marketing docs
• Structures that cannot be verified are not reported as numbers
• Assertions are compared against independent sources, not against constants copied from the code under test
• A missing number is acceptable; a wrong number is not
• A transaction has three outcomes — confirmed, failed, indeterminate — and the last is never sold as the second

This section usually stays out of marketing material because it does not sell. It is included because “does not break” is itself the product.

6. What We Do Not Do

• No asset management, no investment advice. We provide tools, not judgment.
• No promised returns. No form of return projection will appear in our materials.
• No custodial unattended trading. This directly conflicts with Section 3.
• No security capabilities in paid tiers. Honest confirmation and slippage bounds belong to correctness. Paid tiers may only sell speed and convenience.

7. Status

Of the capabilities this thesis describes, those already on screen and working are listed under What is live; those that are not are listed under Limitations.

We do not use “coming soon” for anything that has no code. We also do not describe a disabled form as a live launch.