TRANSPARENT BY DESIGN

Every result has a history.

SWARM’s portfolio is built from stored observations and decisions. Download its public ledger to check how each result was reached.

One active agent

SWARM follows tracked wallet trades on Robinhood Chain. Its portfolio and results are virtual; no transactions are sent to the blockchain. SURGE, ECHO and CHAOS are retired, with their previous records preserved in the archive.

Sources and selection

Only paid, verified buys from tracked wallets; transfers and flagged records are excluded. Minimum liquidity is $50,000 and FDV is capped at $5M. Confirmation requires three prices from the same provider and pool, with no gaps over 45 seconds, a maximum 5% range, up to 2% drawdown from the peak, and retention of at least 90% of the liquidity observed in that period.

Tokens are discovered from wallet trades, with quotes maintained for open positions. If a recent price is unavailable, the last valuation and its timestamp are retained; no execution is invented.

DEX Screener is the primary price source. When a recent quote is missing, we query GeckoTerminal for that contract. Each price retains its original source and timestamp; an API error does not turn an old quote into a new one.

Cadence and timestamps

There is no fixed wait between trades. A shared refresh aims to query sources every 15 seconds. Each new observation can produce a SWARM decision; repeating the same observation cannot. SWARM can hold several positions. Buys require a quote after the decision; exit plans use prices after they are armed.

The page requests updates while visible and resumes when reopened or reconnected. The GitHub Actions pilot is scheduled every five minutes and polls in windows of up to 290 seconds. GitHub may delay or skip starts; the 15-second target is not guaranteed. Without an active pilot or visitors, SWARM does not advance. Gaps remain visible and unobserved trades are not reconstructed.

pit-v1 used a 15-minute minimum interval; pit-v1.1 used three minutes; pit-v1.2 used one minute. From pit-v1.3, the engine evaluates new observations without that minimum. The ledger preserves each change and its timestamp without recalculating previous results. Exports identify all four rule versions.

SWARM’s strategy

SWARM v12: at least one wallet, $500 in net buying and 75% buy flow over the last three minutes. It waits for three prices observed after the wallet buy, over 30–90 seconds, confirming a steady 0.2–3% rise. Flat prices, declines, sharp spikes and withdrawing liquidity do not qualify. Each entry is capped at $50 or 0.5% of equity, whichever is lower, before costs; more wallets do not increase the size.

For new v12 positions: 4% stop, 12% target and a 30-minute maximum hold. After reaching an estimated 4% net gain, it exits on a 2% decline from the peak or a return to net cost. From ten minutes onward, it closes if estimated net liquidation value does not exceed the investment. It also exits on net selling by the sole source wallet, or by two source wallets when there were several. Earlier positions retain their plans.

Up to three positions, 1.5% total exposure and 98.5% cash. New buys pause for one hour after three consecutive losing closes or a 10% loss on one position. A 0.25% equity decline from the start of the 24-hour window also pauses buys until the next window. Exits stay active. A 30-minute cooldown per token follows execution; open positions are not increased.

A buy waits for another quote and rechecks confirmation, wallet flow and costs. Price response age must be at most 15 seconds; execution tolerance is ±1% from the decision, without moving the stop or target. The source buy must still be within three minutes. Estimated net reward must be at least 1.5 times risk, using a 0.3% fee, $0.10 gas and liquidity-based impact. Exits use a price actually observed after activation; a stop does not cap the maximum loss. Response age does not prove the provider’s last trade time. Pending orders remain private.

SWARM v10: entries and exits

v10 widens entry tolerance to +2% / −3% while retaining the minimum net reward, evidence and risk limits. Exit plans are armed when a position opens; for existing positions, on the first v10 observation. A pending buy does not block position management. Each exit uses a price observed after arming; time-based and wallet-selling exits also require a quote after that event. A fill is never simulated at a stop price that the market has skipped.

Capital, positions and the previous ledger are preserved. The page records equity and activation time for v10 to measure changes from that point, including inherited positions. Each resolved attempt saves the decision quote when available, the evaluated quote, source and pool, waiting time, and risk and cost checks. Old records are not backfilled with invented prices. Both sizing-comparison portfolios continue with v9.

Radar, signals and coverage

PIT calculates its own overlaps and filters (pit-direct-v1). It reads events and receipts through Robinhood Chain RPC. The reference public endpoint is documented at Robinhood Chain, red 4663. La conexión de producción usa Alchemy Free: su índice de transferencias localiza recibos candidatos, y PIT comprueba después los recibos y bloques. Se leen hasta dos páginas de 1.000 transferencias por dirección del router. Si hay más páginas, se recorta la ventana al tramo completo de ambas direcciones y se muestran sus horas reales. No se importan señales ni puntuaciones de Alchemy. Wallet selection and aliases start with the roster from FomoRadar · Follow / active; refresh is attempted every thirty minutes while PIT is active. Esta selección no prueba rentabilidad ni independencia entre wallets.

Manual additions requested for PIT: horseimnot. They remain tracked even when absent from Follow / active; their buys and sells go through the same checks.

Initial coverage observes transfers between those wallets and router 0xb92fe925dc43a0ecde6c8b1a2709c170ec4fff4f. The successful receipt and its block are checked. Operations batched through EntryPoint 0x4337084d9e255ff0702461cf8895ce9e3b5ff108 are separated by successful UserOperationEvent, whose account sender must match the wallet. A relayer may send the transaction and is not treated as the buyer. Multi-token wallet operations that cannot be priced separately are omitted.

Amounts are approximate: the largest USDG leg in the relevant router direction is used within each operation, without summing route hops, assuming 1 USDG = USD 1. This does not exactly reconstruct fees, taxes or execution. Without that leg, the amount is unavailable and the operation is excluded from overlaps. Deliveries through other intermediaries appear as receipts without confirmed buying intent only when the receipt has a single outgoing token and recipient from the router; they do not generate early candidates. Each event includes transaction and block hashes, and an operation hash when available, with explorer links to the receipt. A transfer alone does not guarantee a valid economic trade or token identity.

A shared reading is attempted every 15 seconds during radar visits and PIT runner windows: up to 9,001 recent blocks, 20 blocks behind the head, and at most 40 transactions per reading. Actual coverage times are shown, with a maximum 15-minute window. Blocks are provisional and may reorganize; they are reread at each refresh. Missing receipts or reaching the limit trigger a warning and suspend early candidates. Not all traders, routers or Robinhood Chain launches are covered.

Overlaps require at least two wallets with net flow of USD 50 or more each in the displayed direction. Early candidates require attribution to a successful operation of the wallet's own account, at least USD 250 in combined purchases, at least 65% buy share and a buy within three minutes. Filters require FDV up to USD 1M, pool reserves of at least USD 10,000, pool age up to 24 hours and a quote up to three minutes old. Change limits are −5% to +15% over five minutes, −15% to +40% over one hour and −30% to +100% over 24 hours. Since the first detection of the continuing overlap, price must stay between −10% and +15%. Missing required data excludes a candidate. These thresholds are experimental hypotheses, not a proven profitable strategy.

Prices, FDV, reserves and creation dates come primarily from DEX Screener. GeckoTerminal is a fallback for contracts without a recent quote. Se exige la misma red y el mismo token base y se identifica ese proveedor en la tarjeta. Las monedas de las señales se descubren a partir del archivo de wallets, sin depender de listados de pools new. FDV significa valoración totalmente diluida, no capitalización verificada. La edad de un pool no demuestra la edad del token: una migración puede crear otro pool. El precio de detección es una cotización observada, no un precio de ejecución. Las curvas de PonsFamily are identified when the source reports pons-v2 or pons-v2-dex; their reserves may include virtual liquidity.

SWARM buys tokens based on followed wallets. Price providers do not create signals. Your My signals selection does not change SWARM’s shared roster. Pending orders never feed the radar.

Wallet archive and profiles

The public RH Trenches tape returns up to 500 movements per query. PIT keeps detected activity in its own database, deduplicates by transaction, wallet, token and direction, and uses recent hashes as hints to query receipts in Alchemy. Those hashes alone are not evidence of a purchase. Early overlaps still use only the covered interval of the direct reading.

The leaderboard displays index statistics for the requested seven-day window, with date and source; PIT does not present them as audited results. Each profile's book calculates net quantities and average cost from observed history, checking up to 30 observed contracts with balanceOf and decimals at a recent block. Eighteen decimals are never assumed. If balance and book disagree, cost and PnL are hidden. Unarchived contracts are not discovered, so this is not a complete portfolio. Balance cache refreshes every two minutes per profile and remains valid for five minutes; additional prices come directly from DEX Screener. Earlier history or gaps may be missing. If sales exceed observed buys, amounts are missing or a buy has external or unknown funding, cost and PnL for that token are hidden. Remaining PnL estimates observed trades, not the wallet's full return. Valuations require prices under three minutes old. The calculation is limited to 10,000 movements per profile and indicates when reached.

Signals by token and history

The radar groups buys or sells from every wallet in the current roster using PIT's archive, across fifteen-minute, one-hour, six-hour or 24-hour windows. The default is 24 hours, at least one wallet and USD 50 per trade, ordered by latest buy. A GeckoTerminal quote, new pool or early-filter qualification is not required. Wallet count comes from the roster and can change.

Includes account-attributed operations with compatible receipts and RH Trenches indexed trades with an identified cash leg; indexed buys require self-funding. External payments, third-party recipients, quote assets and flagged records are excluded. A checked receipt alone does not prove buying intent. “On-chain attribution only” requires a checked account operation and retains the historical verification time.

Each contract is grouped by address even if another token shares its symbol. Each wallet counts once per token; trades are summed without duplicating transaction, account, contract and direction. Amount and evidence filters apply before wallet counts. Participant search selects their tokens and retains the other participants in those tokens. Trade view orders each event chronologically. “Oldest first” sorts tokens by their first trade in the window; “Newest first” by their last.

Amounts reflect approximate gross buys or sells in the period, not current positions, net flow or returns. Missing amounts remain unpriced. Queries use up to the 20,000 most recent records in the period and disclose when the limit is reached. The archive depends on radar and runner readings: the external tape returns its latest 500 movements and gaps may exist. A 24-hour window does not guarantee complete coverage. Historical signals are independent of SWARM's recent criteria and early candidates.

SWARM · virtual consensus

PIT follows FomoRadar’s Follow / active roster plus the manual additions listed above, matched by address. Other indexes may enrich these wallets but never expand the selection. If the roster cannot be refreshed, the last verified selection and its timestamp are retained. Excluded wallets stop feeding the radar, alerts, My signals and SWARM; their earlier archive is preserved. FomoRadar provides addresses and aliases, not signals, scores or returns. Buys and sells are obtained from the index and checked against the chain.

Position size comparison: $50 and $100

This forward test starts two independent virtual portfolios with $10,000 on the same date. It only uses signals observed after the start. SWARM keeps its main portfolio and history; earlier gains are not attributed to the experiment.

The reference uses a base entry of 0.5% of capital and the variant uses 1%. With two buying wallets, both use up to 1.5%; with three or more, up to 3%. They share the swarm-v9 engine, radar reading, entry and exit conditions and risk limits. Each portfolio recalculates its costs and waits for a later quote to execute; greater impact may reduce the amount or reject an entry. Trades and results may diverge.

Both portfolios advance together and keep a public ledger of executions and valuations. Pending orders remain private. Net results use a common starting capital of $10,000 and include estimated costs; open positions do not deduct future exit costs. A buy and its sales count as one closed trade. The downloadable ledger is paginated: nextAfter gives the value to pass as after to continue. The comparison retains its unchanged v9 engine when the main SWARM is updated, so rules are not mixed and the experiment is not restarted.

Chart detail

Charts retain every observation in the last 24 hours, one sample per ten-minute interval for earlier dates and the starting point. Standings, costs and maximum drawdown use every observation. The downloadable ledger retains the full ungrouped history.

Publishing decisions

Orders are privately recorded before execution is attempted. Their asset, direction, amount and explanation become public once executed or rejected. Pending orders are not sent to browsers or exposed in the public API.

SWARM’s public ledger contains observations and resolved executions. Pending order targets remain private. Archives of earlier stages retain their original format.

Verifiable ledger

Each observation contains prices, decisions, executions, the previous hash and its own SHA-256 hash. Downloads preserve the exact content used to calculate each hash.

hash = SHA256(previous_hash + newline + payload)

This detects changes or gaps relative to a copy you kept. The ledger is stored in PIT's database, not anchored on-chain or independently timestamped. An operator with enough access could rewrite the entire chain; retaining exports lets you compare them.

What the model does not reproduce

Exact routes, concentrated liquidity distribution, dynamic fees or changes to token rules.
Sandwich attacks, actual congestion, wallet latency and transaction failures.
Taxes, transfer restrictions, regional eligibility or tokenized asset issuer terms.
Guaranteed stop execution or a guaranteed full-portfolio liquidation price.

SWARM’s gas and price impact are published estimates. The simulation does not reproduce every condition of a real trade.

The signal we are looking for

We want to see whether people return, follow wallets and check their trades. No invented follower counts or usage metrics are published.

Download SWARM’s ledger →

Back to the rules →