A PUBLIC FLEET, BUILT TO SURVIVE

Hamstrade is a hosted platform for deploying autonomous trading agents onto Solana memecoin markets. You configure an agent, fund a wallet that belongs to it alone, and it trades without you watching.

What it does. An agent reads every new token as it launches, runs it through a tiered set of safety checks called the Gate, and refuses almost everything it sees. The few candidates that survive are sized against a fixed risk budget, entered, and then guarded by rules fixed before entry. When a position closes at a loss, the loss is analysed and written down.

How it works. Discovery, refusal, sizing, execution, exit, and post-mortem are separate components with a fixed order of authority between them (§4). The component that wants to buy is the only one that can open a position, and it is subordinate to the two that can refuse. That ordering is structural, not a setting.

What makes it different. Three things, each of which costs us something:

• Refusal is the product. Finding tokens was never hard; turning almost all of them away is. Every refusal is published with its reason (§10), which makes the filter's quality inspectable rather than asserted.
• The fleet is ranked on survival, not profit. A profit leaderboard rewards whoever took the largest risk and got lucky, and teaches everyone watching to copy that bet. We don't publish one, and we're not going to (§10).
• No language model is anywhere near a trading decision. Models run only after a position has closed, over the record of what already happened (§9). Live decisions are fixed rules with logged inputs.

The name is the argument compressed: a hamster's cheeks are finite, so the question is never whether a token looks good but whether it's worth one of the few slots there are — and a hoard is judged by whether it lasted the winter, not by how fast it was gathered. The failure mode has a name too. An agent that trades constantly and ends the month flat has been on the wheel.

The market never sleeps, and it moves in minutes. New tokens launch at every hour with no pattern. By the time one is posted in a call channel, the move that made it worth calling has usually already happened.

A large share of launches are traps built on purpose. Tokens you can buy but never sell, tokens whose creator can freeze your wallet, token extensions that let a creator drain holders after the fact, supply split across linked wallets to fake demand, liquidity pulled the moment it's profitable.

A bot that misjudges once misjudges a hundred times. A person who gets one token wrong loses one trade. A bot with the wrong settings repeats that judgment on the next hundred launches before anyone notices. This is the specific reason risk management is given authority over entry in the architecture rather than sitting beside it as a feature (§4, §8).

Risk management is the part nobody ships. Entry logic is what gets demonstrated; position sizing, loss limits, and circuit breakers are what decide whether an account still exists in a year. The industry's incentives point the other way — bot products show their best trades, competitions rank by returns, and both push toward maximum risk, because maximum risk is what tops a leaderboard. Nobody screenshots a steady account.

1. Refuse by default. A token must actively pass every check that applies to it. A check that can't get an answer is a failure, never a pass.
2. Fix the rules before entry. Position size, stop, and target are locked at the moment of entry and enforced from there without further input.
3. Limits are hard limits. No retry, restart, or partial failure may exceed the position size, the concurrency cap, or the daily loss limit.
4. Paper first, live is opt-in. Every agent starts in simulation. Trading real size is a separate, deliberate act.
5. No model in the loop. Language models run only after a trade closes. Every live decision is a fixed rule with logged inputs.
6. Everything is logged, including every refusal, with its reason and the on-chain data behind it.
7. Rank on survival, never on profit. Every published figure is chosen so that copying it is good advice.
8. No performance promises. We publish mechanisms and measurements, never projections.

Discovery combines a low-latency launch stream with a slower feed carrying real market data. The fast stream tells you a token exists; the slower one arrives already carrying holder concentration, deployer history, and honeypot signals. Both reach the same tokens seconds apart, so the default is to trade only on the informed feed and accept the delay. An operator can enable the fast path and take the weaker checks knowingly (Appendix A).

                    THE FIELD: Solana mint & pool stream
                                    │
                      ┌─────────────▼─────────────┐
                      │   THE GATE                │  tiered refusal
                      │   T0 → T1 → T2            │  (§5)
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   FORAGER                 │  the only component
                      │   entry decision          │  that opens a position
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   WINTER                  │  sizing, risk budget,
                      │   session authority       │  circuit breaker
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   EXECUTION               │  quote → confirm →
                      │   Jupiter                 │  record (§7)
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   BURROW                  │  guards the open
                      │   exit authority          │  position (§8)
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   POST-MORTEM             │  after the fact,
                      │   analysis                │  never in the loop (§9)
                      └─────────────┬─────────────┘
                                    │
                      ┌─────────────▼─────────────┐
                      │   THE FLEET               │  public survival
                      │   public record           │  record (§10)
                      └───────────────────────────┘

Two properties of this order matter more than any single component.

Safety precedes strategy. A token whose creator can still freeze wallets is discarded before anything evaluates whether it's worth buying. Nothing downstream can reach a candidate the Gate refused.

The deepest checks never block entry. The Gate's slowest tier runs alongside the entry decision rather than in front of it, because its latency is incompatible with the window a new token gives you. An agent acts on the fast tiers and lets the slow one land when it lands.

One consequence is worth stating rather than leaving to be discovered: because every agent watches the same stream and receives the same verdict, they all see the same candidates at the same instant. Agents converging on one token is structural, not accidental, and §10 addresses it directly.

The Gate is the set of checks every token must pass, ordered from cheapest to deepest. Speed and thoroughness are not simultaneously available, so the Gate is explicitly tiered rather than pretending otherwise. Exact thresholds are in Appendix A.

Tier 0 — read from the launch data itself. No extra lookups.

• Mint authority must be revoked, or the creator can print supply at will.
• Freeze authority must be revoked, or the creator can stop you selling.
• Token-2022 extensions: a transfer hook, a permanent delegate, or a non-transferable flag is refused outright. A transfer fee above threshold is refused, and so is a live fee authority — a low fee today means nothing if the creator can still raise it after you buy.

Tier 1 — direct chain lookups.

• Pool liquidity against a minimum floor, and a sanity check that reserves match reported supply.
• Whether LP tokens are burned or locked, recording the unlock timestamp where one exists.
• Top-10 holder concentration, and how much supply the creator kept.
• A simulated sell, executed from the agent's own wallet at the exact size it intends to buy. This is the single most valuable check in the system: it catches tokens you can buy but cannot sell. It runs from the agent's real wallet specifically because some tokens allow or block wallets by name.
• Round-trip cost: fees plus price impact to enter and immediately exit at that size.

Tier 2 — deep checks, asynchronous.

• Deployer history: what the creator launched before, and what share of it rugged.
• Insider concentration: supply held by wallets whose funding traces to one connected group.
• Bundling: a large share acquired in a coordinated pattern rather than organically.

These three signals and the honeypot flags are sourced from GMGN's API rather than computed here; Hamstrade's contribution is fixed conservative thresholds and a refusal on anything crossing them (Appendix A).

If the Gate cannot get an answer, it refuses. A timed-out request, an unreadable account, or an unrecognised token extension is treated as a failure. An extension we don't know how to evaluate is treated as dangerous, not waved through.

Every agent runs three components. One wants to act; two exist to refuse it.

The Forager — entry. The only component that can ever open a position. It acts on Tier 0 and Tier 1 results, because nothing slower fits the entry window.

The Winter — session authority. Sizes every trade against the risk budget, enforces every configured limit, and ends the day's trading when the daily loss limit is reached. When it calls the day, the day is over.

The Burrow — position authority. Never opens a trade. Once a position is meaningfully in profit it locks a no-worse-than-breakeven floor; as momentum fades it tightens the exit; it closes on a stall, a drawdown, or a crash.

When they disagree, the Winter and the Burrow win. This is the order the code runs in, not a preference. An operator controls how aggressive the Forager is permitted to be. Neither of the other two can be turned off.

Routing. Trades go through Jupiter, which aggregates Solana's exchanges. A quote is taken first, and a position is recorded only after the swap confirms on-chain, keyed by the transaction's own signature. A failed attempt can therefore never create a ledger entry for a trade that didn't happen. If no route exists, the token is skipped.

Slippage. A hard ceiling on how much worse than quoted a fill may be, derived from the agent's stop distance — a fill worse than your stop is a fill you didn't want.

Front-running. No private bundles, no builder tips. At these position sizes a tip large enough to matter costs more than the front-running it avoids. This would need revisiting at larger size.

Fee reserve. Failed transactions still cost SOL. Each agent holds a reserve for fees and stops trading rather than draining it.

Never guess a transaction's fate. The most dangerous bug in a system like this is the naive retry: a swap lands on-chain, the confirmation is never seen, the system tries again, and the operator now holds two positions and has silently exceeded their own size limit. Hamstrade does not retry automatically. A swap either lands, fails cleanly, or is unresolved — and unresolved is never treated as either outcome. Resolution comes from reading the agent's actual on-chain balance, and where the database and the chain disagree, the chain wins and the database is corrected. Restart follows the same rule: every position still marked open is reconciled against the agent's actual on-chain balance before trading resumes, and a balance that cannot be read leaves the position open for the next cycle rather than being guessed at.

This is the part the architecture is built around, and the reason entry is subordinate rather than central.

Position sizing. Every trade is sized in absolute SOL, not as a percentage of balance. Depositing more into an agent's wallet does not silently make each of its trades larger.

Concurrency and exposure. A cap on simultaneous open positions and a cap on total deployed size, both enforced at entry by the Winter.

Daily loss limit. A circuit breaker that ends the session when reached. It does not ask, and it does not require a restart to take effect.

Loss-streak breaker and cooldown. Consecutive losses pause trading; a closed loss imposes a cooldown before any new entry.

Exits are rules, not orders. There is no such thing as a stop order on an AMM — the kind of exchange these tokens trade on has no order book, only a pool you trade against. What we call a stop-loss is the Burrow watching price and submitting a sell once a threshold is crossed. That makes exits rule-based and best-effort, subject to network congestion, liquidity conditions, and price gaps. They are never a guaranteed floor under your losses, and we will not describe them as one. §12 states what that actually costs you.

     trade closes at a loss
              ↓
     the loss is packaged
     (fills, timing, risk budget, gate verdict)
              ↓
     analysis names a proximate cause
              ↓
     a concrete config change is proposed
              ↓
     the operator accepts or declines

No model has any say in whether, when, or how a trade happens. Getting an answer from a language model takes seconds; entry decisions take milliseconds. The two speeds are incompatible, and any product implying a model makes live calls is describing something that cannot physically work at that speed. We would rather state this exact boundary than lean on "powered by AI" — the specific claim is both more accurate and easier to believe.

Models run only after a position has closed, over the record of what already happened. Proposals touch the operator's own exit-related settings and nothing else; they have no path to a Gate rule, and nothing is ever applied silently. Every post-mortem is retained in full and exportable.

The loop's own failure modes — small samples that look like patterns, confident and wrong explanations, and the absence of a repetition threshold — are in §12 rather than buried here.

Every deployed agent joins one public directory.

Public: every refusal, with its reason and the tier that caught it; each agent's name, age, and survival record; its post-mortems where the operator allows; paper agents' full trade history.

Not public: who owns an agent, what its wallet holds, and the exact values of its settings.

There is no profit leaderboard, and there will not be one. Ranking by return rewards whoever took the largest risk and survived it, and instructs everyone watching to copy that bet. The fleet is ordered on whether an agent is still running.

Agents do not coordinate, and this is a commitment rather than a current limitation. No agent sees another's parameters, and no feature will exist whose effect is to move many agents into one token together. Because every agent shares a verdict stream, convergence already happens structurally (§4); the answer is to publish that honestly, not to build tooling that amplifies it.

The refusal feed is the fleet's most useful surface, because it's where the filter can be judged rather than believed:

17:04:12  T0  Sisyphus     refused  4Hq2…  freeze authority active
17:04:12  T0  Little Boat  refused  4Hq2…  freeze authority active
17:04:19  T1  Sisyphus     refused  9Kp7…  top-10 holds 61%
17:04:23  T1  Driftwood    refused  Bn3x…  sell simulation failed
17:04:31  T2  Little Boat  refused  Cw8m…  deployer: 4 prior rugs

Each agent trades from an isolated wallet of its own. Deploying an agent generates that wallet; you fund it with only what you intend to trade. Agent keys are encrypted at rest and isolated per agent.

Your own wallet is never exposed to Hamstrade. It is used to prove ownership and nothing else. Your seed phrase and private key are never requested, never transmitted, and never held — not in the app, not by message, not under any excuse. Anything that asks for them is not us.

The bound on your loss is what you deposited. Hamstrade has no signing power over your wallet at all. You can withdraw an agent's balance to any address, and export its private key, at any time.

What that model does not give you, stated plainly: Hamstrade holds the agent wallet's encrypted key, and a held key can technically sign anything. Nothing in the code prevents that the way an on-chain constraint would. This is us choosing not to, not us being unable to, and any claim that funds in an agent wallet "cannot be taken" would be false.

The long-term architecture is a constrained on-chain vault that permits an agent to call specific swap functions and makes it structurally impossible to send funds anywhere except back to the owner's wallet. Under that design a full compromise of our infrastructure would buy an attacker bad trades, not stolen funds. Progress is in §14. Until it lands, agent keys are encrypted at rest with AES-256-GCM under a key held in the process environment rather than the database, so database access alone cannot unlock one, and keys are isolated per agent so exposure of one does not generalise to the fleet.

Operational commitments: documented restart behaviour, alerts on any outage or automatic halt, a public status page, incident disclosure within ⟦FILL: window not yet set⟧, and published uptime. Our one official domain is ⟦FILL: domain not yet published⟧; no other domain is affiliated with us. Audit status: ⟦FILL: not yet audited⟧.

This section exists so the rest of the document can be read in present tense. Everything below is either a real limit of the approach or a gap between what is described and what currently runs.

Not solvable, at any level of engineering.

• Single-block liquidity removal takes the whole position. Detection is not escape.
• Chain congestion makes exits fail exactly when they matter most. Fee escalation helps; it does not solve it.
• Price gaps jump straight past a stop between one check and the next, with no trade at the level in between.

Built, but weaker than it sounds.

• Sell simulation is a snapshot. It is true at the instant it runs. A time-delayed honeypot — selling works, passes at entry, is switched off later — is not caught by anything running today, because the simulation is not rerun on open positions. Entry simulation passing is the only assurance you have.
• Exits act on a single price read. Averaging over slots and requiring a move to hold before firing are designed but not built, which leaves the fleet exposed to a coordinated stop-hunt hitting every agent sharing that price feed at once.
• Paper results are systematically optimistic. Paper mode models zero slippage and zero price impact, so it fills at an observed price rather than a price your own order would have moved. It cannot simulate block position, fee competition, partial fills, or failed transactions. Paper profit and loss should not be read as live performance. One early cohort makes the point: a single trade set to take profit at +30% closed in simulation at 8.59x, because price ran past the target inside one check interval and paper filled at the next observed price. That one trade accounted for the entire batch's apparent profit, and removing it left the batch slightly negative.

Described but not yet running. Continuous re-verification of open positions beyond price rules; a repetition threshold before a post-mortem cause becomes a proposal; full state reconstruction on restart; agent-name uniqueness and lookalike detection; the $HMSTR holding requirement that gates deployment (§13.1). Each is itemised in Appendix H.

Outside the threat model entirely. A compromise of your own device or login, a market-wide crash, Solana itself halting, and an adversary able to reorder blocks at will. Anything not named in this section should be assumed undefended.

Unproven. Whether accepting post-mortem proposals measurably improves outcomes is an open question we cannot yet answer, and how we will measure it is ⟦FILL: not yet decided⟧.

• Paper trading is free.
• Deploying an agent requires holding $HMSTR, and nothing else. No fee is charged, no subscription is billed, and no SOL is taken at deployment or at the switch to live. Hold the token and the Deploy page is open to you. That is the entire access condition (§13.1).
• Holding is not spending. The tokens stay yours. You are not paying us, you are holding an asset you can sell whenever you choose, which also means you carry its price risk and that selling below the threshold should be expected to cost you access (§13.1).
• No recurring subscription. Nothing is billed monthly, and nothing is billed at all. What keeps us honest is reputation: public refusals, public post-mortems, survival ranking. You are entitled to treat that as the softer guarantee it is.
• Trading costs are borne by the agent: priority fees, failed-transaction fees, slippage, and rent for token accounts.
• No guaranteed returns. With no deployment charge to earn back, what decides the outcome is the per-trade edge after costs, and round-trip cost is subtracted on every trade regardless of how it goes. Real values for win rate, average win, average loss, and cost require measured live trading: ⟦FILL: not yet measured⟧. Any worked example built on assumed values would be a projection, and §3 rules those out.

13.1 The $HMSTR Token

Hamstrade is launching a token, $HMSTR, as a fair launch on pump.fun.

Fair launch means the same curve for everyone, from the first block. No presale, no allowlist, no private allocation, and no supply set aside for the team, for insiders, or for anyone who was early. There is no round you missed, because there is no round. Whether anyone connected to Hamstrade buys on the open market after launch, and how that gets disclosed, is ⟦FILL: not decided⟧.

Until a contract address appears in this table, there is no $HMSTR token, and anything trading under that name is a scam. The address will be published here and on the Deploy page when it exists, and nowhere else first.

What the token does: it opens agent deployment, and that is all it does. Holding $HMSTR is the only requirement to deploy an agent. There is no fee to pay alongside it, no allowlist to get onto, and no other qualification. Beyond that access right the token carries no ownership of the operating entity, no claim on fee revenue, no governance over the Gate, and no entitlement to any agent's profits. Whether it ever carries more is ⟦FILL: undecided⟧.

None of this is enforced today, and cannot be. The token does not exist yet, so no wallet can hold it and nothing checks for it. The Deploy page currently asks for a connected wallet and a name, and turns nobody away. This section states the intended access model; it is not a description of running code, and the gap is tracked in Appendix H rather than left for you to discover.

Three parts of that model are still undecided. Stating them vaguely would be worse than listing them:

The third question is the one that matters most to anyone holding a live position, and we would rather publish it unanswered than answer it now and change it later.

We are launching on the venue our own agents refuse most often. pump.fun strips mint and freeze authority from every token it hosts, which is exactly why those two checks tell an agent almost nothing there (§5). Run through the Gate, $HMSTR would be judged on liquidity, concentration, deployer history, and sell simulation like any other launch, with no exemption for being ours. We are not claiming it would pass.

This is an unresolved conflict of interest. The people who set the Gate's thresholds and the people who benefit if $HMSTR trades well are the same people. Whether any agent may trade it is ⟦FILL: policy not yet decided⟧ and is a launch blocker in Appendix H, not an afterthought.

We don't put dates on these. A missed date costs more credibility than never having published one.

Shipped. The tiered Gate; shared verdicts across the fleet at fixed cost per token; idempotent execution with chain-wins reconciliation; restart recovery; the post-mortem loop with operator approval; the public refusal feed; the survival-ranked fleet.

Next: measurement. Real numbers on what the Gate refuses and why, the measured gap between paper and live, real trading costs, and how fill quality changes as the fleet grows. This is what converts this document from a description of intent into evidence, and it is the highest-value work remaining.

The custody upgrade. Moving from a held encrypted key to the constrained on-chain vault in §11. This is the largest gap between what this document stands for and what runs today. Two intermediate steps come first: moving key material behind a narrowly-scoped signing service, and an independent tamper-proof log of every signature request.

Hardening. Continuous re-verification of open positions, stop-hunt resistance on exits, wider trap coverage, an external review of the Gate, and ⟦FILL: a security audit, not yet scheduled⟧.

The $HMSTR launch. Ticker, venue, and what the token does are settled: holding it is what opens agent deployment. The date, the contract address, the size of the holding required, and whether agents may trade it are not (§13.1).

Expanding to Base. The natural second chain: closest launch culture and market structure to Solana's. It needs an entirely new Gate — EVM chains work differently enough (upgradeable contracts, blacklists, transfer restrictions, fake renounced-ownership theatre) that no Solana check carries over directly.

Hamstrade is software, provided as-is, with no warranty. It is not investment advice, not portfolio management, and not a licensed financial service. We make no claim that using it will be profitable or help you avoid losses.

Trading memecoins is extremely risky and you can lose all of your capital. Past performance, real or simulated, does not indicate future results. Paper results are simulated and do not reflect real execution (§12).

Automatic exits are best-effort and are not guaranteed. They can fail during an outage, network congestion, single-block liquidity removal, or a price gap (§8, §12). Nothing in this system puts a floor under how much you can lose.

Fleet statistics describe what agents have already done. They are not a performance ranking, not a recommendation of any agent or configuration, and not a prediction. Listing is not endorsement.

$HMSTR is not an investment, and nothing here is an offer to sell it or a solicitation to buy it. It carries no ownership, revenue share, governance right, or claim on any agent or balance (§13.1). It has not launched; until a contract address is published in §13.1, any token using that name is not ours. A memecoin launched on pump.fun can go to zero, and most do.

You alone are responsible for complying with the laws that apply to you, including securities, commodities, tax, and money-transmission law. This service being reachable from where you are does not make it legal for you to use there.

We accept no liability for losses arising from using this software, or from being unable to use it.

Operating entity: ⟦FILL: legal entity and jurisdiction, not yet decided⟧. We deliberately do not name the individuals behind Hamstrade: nothing you need in order to judge this platform depends on who wrote the code, and an impressive-sounding team would only tempt you to trust people instead of evidence. The legal entity is a different matter and is not optional — a service holding signing power over your funds owes you an identifiable counterparty, which is why that field stays marked rather than deleted.

Legal review of this document is outstanding. Three things specifically need it: operating a hosted service that executes trades for paying users; the custody model in §11; and publicly displaying trading outcomes, which touches performance-advertising rules in most jurisdictions.

Two tables, deliberately. Presenting a target as though it were built is the specific dishonesty this appendix exists to prevent.

A.1 Running today

Sizes are absolute SOL, not percentages of balance: an agent wallet holds only what you deposited, which is not a stand-in for your net worth.

A.2 Target, not yet enforced

Real gaps, listed rather than hidden.

Blockers before launch

Required before any specific claim

Described but not built

Site copy requiring correction

Agent. One deployed bot, with its own name, settings, wallet, and memory.

The Fleet. Every deployed agent, taken together.

Operator. The person who owns an agent and the capital it trades.

The Gate. The tiered set of safety checks every token must pass (§5).

Forager / Winter / Burrow. An agent's entry, session, and position components (§6).

Stopped. An agent switched off by its operator, or paused by its own circuit breaker. It opens nothing new but keeps watching and exiting what it already holds.

AMM. Automated market maker — an exchange with no order book, only a pool traded against. The reason stop orders do not exist here (§8).

$HMSTR. Hamstrade's own token, not yet launched. Holding it is the only requirement to deploy an agent (§13.1).

⟦FILL⟧. A value not yet measured, decided, or reviewed. Every one is tracked in Appendix H.