Get Started

Quick Start

From signup to your first Start: light prerequisites, then follow the steps in order.

---

Prerequisites

• A block.λ account on any plan
• Capital to deploy: 1–2 SOL is usually enough to get started
• No wallet required upfront — we create one for you at signup. You can later import your own wallets and assign specific strategies to them

Setup steps

Reading your first trade

Once the strategy is live the dashboard shows real-time stats for each trade:

Field	Meaning
Detection latency	Time from shred signal to transaction construction
Broadcast time	Time until all 6 nodes confirm dispatch
Slot delta	How many Solana slots after the original trade your copy landed
Fill price	Actual on-chain execution price
Slippage	% deviation from expected fill

---

Continue in the docs

Billing

Plans & Pricing

You choose an activity — rug sniping or copy trading — and a tier. The tables below compare Discover, Sniper, and Pro for each activity. Subscription prices in SOL for every tier are on the homepage and at checkout.

---

Plan comparison

Rug sniping

Three tiers: Discover, Sniper, and Pro. All plans include the full rug sniping bot (snipe creation block 0, automatic transfer follow). Sniper and Pro add multi-location bot deployment and richer data.

Copy trading

Three tiers: Discover (Bot only), Sniper, and Pro. Sniper and Pro add global bot replication, richer analytics, backtesting, and dedicated Discord support. Pro unlocks advanced data, coaching calls, and custom strategy implementation.

You can also compare plans on the homepage or in the app when you sign up or change your subscription.

Transaction fees

A per-transaction fee applies to all copy trades and rug snipes, on top of your subscription. The rate depends on your plan tier (rug sniping and copy trading use the same tier names):

Plan	Fee (of transaction amount)
Discover	0.9%
Sniper	0.5%
Pro	0.35%

On top of the percentage above:

• Minimum $0.15 per transaction
• Does not include your Solana priority fees or Jito tips

FAQ

Can I upgrade mid-month?

Yes. Upgrades take effect immediately and are charged pro-rata for the remainder of the billing period.

What payment methods are accepted?

Plans are paid in SOL. Prices are displayed in both SOL and USD (converted at the current market rate, refreshed every second).

Copy Trading

Copy Trading

Automatically replicate on-chain trades with a consistent execution edge — powered by shred-stream access, colocated bare-metal infrastructure, and 6 geographically distributed sending nodes.

---

How copy trading works

block.λ monitors the Solana shred stream — raw transaction data gossiped by validators as they build blocks. When a buy signal from a tracked wallet appears in the stream, the system immediately:

1. Parses the incoming shred for the relevant token and amount.
2. Constructs and signs your mirrored transaction.
3. Broadcasts from all 6 geographically distributed nodes simultaneously.

This pipeline runs entirely in-memory on bare-metal servers colocated with Solana validators.

Shred Streams

Standard copy bots wait for a transaction to be confirmed on-chain before reacting — by then the market has moved. block.λ operates on raw shred data: unconfirmed fragments gossiped before a block is finalized, arriving ~200ms earlier.

What are shreds?

In Solana, a shred is a fragment of an in-progress block produced by the current slot leader. Validators gossip shreds to each other as they build the block — well before it is finalized and confirmed by the rest of the network. By connecting directly to this gossip layer, block.λ observes transaction data approximately 200ms earlier than an observer waiting for block confirmation.

Signal detection pipeline

1. Receive shreds via UDP from nearby validators.
2. Reconstruct partial block data from shred fragments.
3. Parse instructions to identify buy transactions for monitored wallets.
4. Dispatch your copy transaction immediately upon match.

The entire process from shred receipt to transaction dispatch runs in <5ms on our infrastructure.

Jito and standard nodes

block.λ broadcasts to both Jito block engines and standard Solana RPC nodes simultaneously:

• Jito — preferred when the current leader is Jito-enabled; provides MEV bundle priority and faster inclusion.
• Standard nodes — parallel path ensuring coverage when the leader is a non-Jito validator.

Multi-Geography Broadcasting

The Solana slot leader changes every ~400ms and can be located anywhere on Earth. Network latency between the submitting node and the current leader can add 50–200ms to your inclusion time — equivalent to missing one to four slot transitions.

Sending nodes

Location	Region	Primary targets
Amsterdam	Europe West	EU validators, Hetzner cluster
Frankfurt	Europe Central	DE validators, AWS eu-central
London	Europe North	UK validators, transatlantic path
Ashburn, VA	North America East	US East validators, Equinix DC10
Singapore	Asia Pacific	APAC validators
Tokyo Soon	Asia East	JP validators

Replicated execution

The bot runs independently on each of the 6 nodes. Every node detects the signal from its local shred stream connection and submits the transaction to its nearest validator peers autonomously — no cross-node coordination is needed. Whichever node is closest to the current slot leader achieves earliest inclusion, typically reducing worst-case inclusion latency by 40–60% compared to single-region execution.

Colocation & Infrastructure

block.λ infrastructure runs in the same physical data centers as most Solana validators, providing sub-millisecond signal paths. Network latency has two components: transmission delay (the speed of light over fiber) and switching/routing delay (hops through intermediate routers). By colocating in the same facility, routing delay is eliminated almost entirely.

Data center hubs

The majority of Solana stake is concentrated in a handful of facilities. block.λ operates hardware directly in these hubs:

• Equinix DA11 (Dallas) — largest single concentration of Solana stake
• Hetzner Falkenstein — largest European validator cluster
• Equinix DC10 (Ashburn) — US East transit hub
• Equinix SG1 (Singapore) — APAC validators

Bare-metal vs cloud

block.λ runs on dedicated bare-metal servers, not cloud VMs. Cloud hypervisors introduce unpredictable latency spikes (1–10ms) due to CPU scheduling and NUMA effects. Bare-metal eliminates the hypervisor entirely, giving deterministic sub-millisecond processing times even under heavy load.

Filters and controls

Parameter	Description
min_sol	Minimum SOL in the original trade to trigger a copy
max_sol	Maximum SOL to spend per copy trade
token_blocklist	Token addresses to never copy
slippage_bps	Maximum slippage in basis points

Copy Trading

Execution Statistics

Real-time and historical performance metrics for every copy trade.

---

Available metrics

Metric	Description
Detection latency	Time from shred signal to transaction construction (target: <5ms)
Broadcast time	Time until all sending nodes confirm dispatch
Inclusion slot	The Solana slot in which your transaction was confirmed
Slot delta	How many slots after the original trade your copy landed
Fill price	Actual execution price vs expected price
Slippage	Percentage deviation from expected fill
PnL	Unrealized and realized P&L including all fees

Dashboard

The Execution Stats dashboard shows a live feed of all active copy positions and a sortable history of past trades. Expand any row to see the full transaction details — including per-node broadcast response times and the confirmed Solana explorer link.

Rug Sniping

Rug Sniping

A continuously updated feed of the best-performing rugs, enriched with performance metrics, bundle detection, and dev wallet flags — ready for one-click sniping at full execution speed.

---

What is rug sniping?

On pump.fun, hundreds of tokens are created every day. Most are near-instant rugs — tokens that spike sharply and immediately fall back. A rug sniper buys in early during the spike and sells at ATH.

The challenge is identifying the right tokens fast enough. block.λ aggregates and ranks every rug of the day so you never have to manually scan for opportunities.

The rug feed

block.λ collects and analyzes every token created on pump.fun throughout the day. The feed is:

• Refreshed every 5 minutes (Pro/Expert) or every 6 hours (Simple)
• Sortable by performance (max % ATH from creation), recency, or market cap
• Enriched with bundle detection, dev wallet flags, and MR/ATH metrics

Key metrics

Column	Meaning
ATH %	All-time-high price as a % of the creation price
Performance	Max achievable TP if bought at creation and sold at ATH
Bundle	Whether the launch included bundled transactions (dev snipe signal)
Dev wallet	How many tokens the dev holds / has sold
MR	Market cap at ATH in SOL
Time to ATH	How quickly the token reached its ATH after creation

Refresh cadence by plan

Plan	Refresh	History window
Simple	Every 6 hours	Last 6 hours
Pro	Every hour	Full day (24h)
Expert	Every hour	Last 7 days

Spotting & filtering

The Rug Sniping dashboard presents rugs in a sortable, filterable table. Each row is one token created on pump.fun and includes every metric needed to decide whether to snipe it.

Dashboard overview

Click any column header to sort. Each row expands to show the full token breakdown: on-chain pool address, creation transaction, dev wallet history, and a direct snipe button.

Sorting & filtering

Useful strategies:

• Sort by Performance ↓ — find the highest-return tokens of the day first
• Sort by Time to ATH ↑ — find fast-spike tokens ideal for quick scalps
• Filter Bundle = false — exclude dev-bundled launches (higher execution risk)

Sniping best performers

When you spot a token worth trading, click Snipe on its row. The bot will fetch the current price and liquidity from the on-chain pool, construct a buy transaction using your configured wallet and SOL amount, then broadcast simultaneously from all 6 sending nodes.

One-click snipe

1. Fetch the current price and liquidity from the on-chain pool.
2. Construct a buy transaction using your configured wallet and SOL amount.
3. Broadcast simultaneously from all 6 sending nodes.

Understanding the performance metric

The Performance % column shows the maximum return achievable if you had bought at token creation and sold at ATH. It is a historical measure of how aggressively the token spiked.

High-performance tokens tend to repeat similar spike patterns from the same dev wallet. Expert plan subscribers have access to the backtracker bot, which automatically analyses a dev wallet's launch history on Solscan to identify serial high-performing launchers.

Auto-Follow Wallets

Sophisticated traders frequently rotate wallets to avoid being tracked. The auto-follow feature monitors a source wallet for outgoing SOL transfers and automatically adds the destination wallet to your copy trading watchlist.

How auto-follow works

When a tracked wallet sends SOL above the configured threshold to a new address, block.λ immediately adds that destination to your watchlist — or starts copying immediately if auto_trade is enabled. This ensures you never lose a trader just because they switched wallets.

Configuration parameters

Parameter	Description
min_transfer_sol	Minimum transfer size to trigger an auto-follow (avoids dust noise)
max_transfer_sol	Upper bound — ignores large wallet-consolidation transfers
auto_trade	Immediately copy the new wallet, or only add to watchlist for manual review

Rug Sniping

Auto-Follow Transfer System

AFTS automatically tracks SOL transfers from followed wallets and promotes receiver wallets into your watch list — so you never lose a trader who switches to a fresh burner address.

---

Why AFTS matters

Experienced ruggers and active on-chain traders routinely rotate wallets to stay ahead of trackers. When a known wallet bridges its funds to a new address, any copy strategy locked to the old wallet goes silent — just as the next token launch begins.

AFTS solves this by monitoring outgoing SOL transfers from every wallet in your watch list. When a transfer meets your configured rules, the destination wallet is immediately promoted into your active watch list, and your strategy follows the next launch without any manual intervention.

Enabling and disabling AFTS

The toggle at the top of the section switches AFTS on or off for the strategy. It is enabled by default on all new Rug Sniping strategies.

When AFTS is disabled, the bot does not add any receiver wallets to the watch list regardless of incoming transfers. The only reason to disable it is when you intentionally follow a wallet that repeatedly launches from the same fixed address — in that case the watch list is already complete and automatic additions are not needed.

Transfer amount ranges (SOL)

Ranges are the primary filter that decides which SOL transfers trigger an auto-follow. Each range has a minimum and an optional maximum expressed in SOL.

• Minimum value per range must be at least 0.001 SOL.
• Maximum is optional. Omit it to capture everything above the minimum with no upper cap.
• You can add multiple ranges. A transfer is accepted if it falls within any one of them.
• If no ranges are defined, any transfer above 0.001 SOL matches — equivalent to "all transfers".

Watchlist rotation

Below the transfer ranges — and outside the collapsible Advanced block — the form always shows Remove source after transfer and, when that option is on, Wallet always kept. These control how the watch list evolves after each successful auto-follow.

Remove source after transfer (default: on)

When enabled, the tracked wallet that sent the transfer is automatically removed from the watch list after the follow is triggered.

This is the critical mechanism for "wallet rotation" following. The logic is: if a rugger just moved all their SOL to a new address, the old address will likely never launch again. Keeping it in the list wastes a slot and adds noise. By removing the source wallet automatically, the watch list always reflects the most current operative addresses.

For mother wallets that keep distributing SOL while staying active, leave Remove source after transfer on and list those addresses under Wallet always kept (see below). Only disable remove source if you want no source ever removed — every bridge then leaves the sender on the list, which fills the watchlist quickly.

Wallet always kept

When Remove source after transfer is on (default), the strategy form shows Wallet always kept. Add addresses that must never be removed from your watchlist after they send a qualifying transfer.

This is the recommended way to track mother-wallet schemes: the main funding wallet stays on the list while AFTS still rotates disposable bridge wallets out and adds new receivers.

• Each always-kept address must also be in Wallets to Follow. The form rejects saves if an entry is missing from the followed list.
• When an always-kept wallet sends a transfer that passes your AFTS rules, the receiver is added as usual and the source is not removed. Any other followed wallet that is not in the always-kept list is removed after the follow, as usual.
• On the strategy Summary, always-kept wallets appear first in the watchlist and show a green bookmark icon (Always tracked).

Advanced filter settings

The Advanced section is collapsed by default. It exposes four parameters that fine-tune which transactions are treated as genuine bridges versus incidental sends.

Min receiver % (default: 90%)

The minimum share of the tracked wallet's net SOL outflow that a single receiver must collect to be considered the bridge target.

Net outflow is calculated as the largest send leg from the tracked wallet in the transaction, minus base transaction fees. A receiver that gets less than this percentage of that net outflow is not added to the watch list.

Min sender outflow share % (default: 50%)

This setting matters when several wallets send in one transaction. If your tracked wallet is among them but does not have a huge part of the sent outflow compared to the others, you may want to discard the transaction for adding a new wallet.

The largest native SOL outflow from the tracked wallet in the transaction must represent at least this percentage of all its native SOL outflows in that same transaction.

This also guards against cases where the tracked wallet splits SOL across many destinations in one tx: no single send leg dominates its own total outflow, so the transaction is unlikely to be a clean bridge — it looks more like a fee sweep or fan-out distribution.

Source after transfer (SOL)

An optional SOL balance range checked against the source wallet's balance after the transfer completes. The auto-follow is only triggered if the source's post-transfer balance falls within the configured min/max.

Last wallet transfer A common pattern is the last wallet transfer before a rotation: you only want to add receivers when the source is left with no meaningful SOL after the send — so the address is unlikely to “wake up” again for another launch. Setting a low max post-transfer balance (for example 0.05 SOL) targets that case: the wallet is effectively empty, so it probably will not recover meaningful activity before the next launch happens elsewhere.

Alternatively, set a min post-transfer balance (for example 1 SOL) when you only want to treat sends as follows if the source still holds reserves — useful to filter “top-ups” that are not a full hand-off to a new wallet. Leave both min and max empty to skip this check entirely.

Destination after transfer (SOL)

A SOL balance range checked against the destination wallet's balance after the transfer completes. The auto-follow is only triggered if the destination's post-transfer balance falls within the configured min/max.

Min is optional — leave it empty to skip a lower bound. Max defaults to 1,000 SOL in the strategy form and is hard-capped at 1,000 SOL: values above that cannot be saved.

Why a 1K SOL hard cap? Bridge amounts alone can look modest (1–5 SOL), but the destination wallet's total balance after the transfer is what matters. Exchange deposit wallets, omnibus addresses, and cold-storage style wallets belonging to CEXs or mixers (Binance, MEXC, and similar) typically sit on very large SOL balances. Without a max, AFTS could add those addresses to your watch list even though they will never launch a token. Capping post-transfer balance at 1,000 SOL filters those wallets while still following fresh addresses that plausibly hold launch funds.

How it reads on the strategy page

On a running strategy, the Summary card’s right column lists followed wallets (always-kept entries first, with a bookmark when applicable) and, below the divider, a compact AFTS panel: on/off, configured SOL bands, min receiver, min outflow, remove source, and any post-transfer bands you set.

Typical configurations

Limits

AFTS limits are based on your active Rug Sniping plan. They keep each strategy’s watchlist under control and protect the live transfer scanner during extreme wallet-rotation bursts. Higher tiers increase both the number of wallets you can track and the number of automatic follows AFTS can perform per hour.

Watchlist size limit

The watchlist limit is the maximum number of wallets a strategy can monitor at the same time. It includes the wallets you entered manually in Wallets to Follow and every receiver wallet AFTS has added since the strategy started.

If the watchlist is full, AFTS stops adding new receiver wallets for that strategy. To make room again, stop the strategy, remove wallets you no longer want to track, save, and restart. The current usage is shown on the strategy Summary card while the strategy is running.

Transfer rate limit

The transfer-rate limit applies only to successful auto-follows: a transfer counts when AFTS actually adds the receiver wallet to your watchlist. The count is measured over a rolling 60-minute window, not over fixed clock hours. For example, if your plan allows 1,000 follows per hour, the system always looks at the last 60 minutes from the current moment; as older follows leave that window, capacity becomes available again automatically.

This prevents a single very fast rotation chain from consuming too much shared capacity. If the strategy reaches its hourly cap, eligible transfers are skipped until enough previous follows have aged out of the rolling window. On the strategy Summary, the Transfer rate limit row shows the current count against your plan limit, for example 842 / 1,000 per hour.

When a limit is reached

When AFTS blocks a follow because one of these limits has been reached, you receive an in-app WARNING notification, and a Telegram notification too if Telegram alerts are enabled.

Only the automatic addition of new receiver wallets is paused. The strategy itself keeps running: sniping, sells, open positions, and all other settings continue to behave normally.

• Watchlist full — AFTS resumes after you stop the strategy, reduce the watchlist below your plan limit, save, and restart.
• Transfer rate exceeded — AFTS resumes automatically once the rolling 60-minute count falls back under your plan limit.

Frequently asked questions

How many wallets can AFTS add?

AFTS-added wallets use the same pool as the addresses you entered manually in Wallets to Follow. The total is capped by your plan’s watchlist size limit. With Remove source after transfer enabled, most follows replace one wallet with another, so the total usually stays stable. Transfers from a Wallet always kept address are the exception: the receiver is added and the source remains tracked.

Very fast wallet transfers: can they be missed?

The replay system exists primarily to catch very fast chains of wallet transfers: many SOL moves can land inside a tiny time window, and the live stream can surface them faster than a human could react. By replaying roughly the last 2 seconds of chain history, the bot re-evaluates that burst against your AFTS rules so rapid rotations (even dozens or hundreds of related transfers in seconds) are not missed because they slipped between stream updates.

What if a wrong wallet gets added?

Auto-followed wallets behave exactly like manually entered wallets: the strategy will copy any matching buy signal they emit. If a false follow adds a wallet you do not want to track, stop the strategy, edit it, remove the unwanted address from the Wallets to Follow list, and restart. You can also tighten the AFTS ranges and percentage thresholds to reduce the likelihood of future false positives.

Does the copy strategy still run normally while AFTS is active?

Yes. AFTS only manages the watch list — it never overrides buy size, sell logic, execution settings, or any other strategy parameter. Existing copy positions are unaffected. Newly auto-followed wallets are subject to the same entry conditions (market-cap filter, buy size, max buys per token) as any manually entered wallet.

Rug Sniping

Front-run sell

A defensive exit for Rug Sniping strategies: detect abnormal token-transfer bursts from followed wallets and sell part of your position before a likely dump.

---

Why front-run sell exists

Some ruggers transfer all their tokens to one or several wallets shortly before dumping them.

If block.λ detects an abnormal number of token transfers over a short period, the bot triggers a sell before the rugger dumps. You choose the time window, the transaction count, and the minimum total amount of tokens transferred — by studying your rugger’s behavior beforehand.

Enabling front-run sell

In Create / Edit strategy (Rug Sniping template), open the Front-run sell section and switch Enable front-run sell on. When disabled, the bot ignores transfer-burst signals for that strategy.

Front-run sell works alongside your normal sell strategies (TP/SL, wallet-copy sells, manual sell). It adds an extra defensive exit; it does not replace them.

Parameters

All four fields are required when the feature is enabled.

Time window (sec)

Length of the rolling window in which transfers are counted. Example: 5 means the bot looks at token transfers that occurred in the last five seconds.

A shorter window reacts faster but may fire on noise. A longer window is smoother but may trigger too late.

Min transfer tx

Minimum number of qualifying token transfers that must occur inside the time window before a sell is triggered.

Example: 2 requires at least two separate transfers in the window — a single large move is not enough.

Min transfer amount (mio tokens)

Minimum total token amount moved across all transfers inside the time window, in millions of tokens. The bot sums every transfer amount seen in that window; a sell triggers only if that sum reaches this threshold (and Min transfer tx is also met).

Maximum 1000 (1 billion tokens — typical supply cap). Use this to filter out low-volume bursts. Example: with a 5-second window, min transfer tx 2, and min amount 1 mio, you need at least two transfers whose combined token amount is at least 1 million within those five seconds.

Sell position (%)

Percentage of your open position to sell when the burst conditions match. Example: 50 sells half of what you hold on that token.

You can keep the remainder exposed to your TP/SL rules or manual exits. A partial sell reduces risk without fully abandoning upside if the signal was a false alarm.

Trading bot

Create / Edit a strategy

The strategy form lets you configure who to copy, how large each buy should be, how execution should be priced, when the bot should sell, and when risk controls should block new buys.

---

Template choice

When creating a new strategy, the first choice is the template. Full Copy Trading mirrors buy signals from the wallets you follow and can mirror their sells too. Rug Sniping is aimed at token-creation strategies: it can auto-follow receiver wallets after SOL transfers and uses TP/SL exits.

Editing an existing strategy opens the form directly with the saved settings. The same sections appear, but the template itself is no longer the main choice: you are editing the strategy already created.

General

Use the general section to label the strategy in a way that makes sense to you: copied wallet group, risk profile, wallet purpose, or notes about the setup.

• Name — short label for the strategy.
• Description — optional notes visible only in your account.

Wallets to follow

This section defines the source wallets the bot watches. When one of these wallets emits a matching buy signal, the strategy can mirror it according to your buy options.

Only real wallet addresses are allowed here. Token accounts, program accounts, mints, and other non-wallet addresses are rejected. The app checks the address format first; the API also checks account ownership on-chain when account info is available, so a token or program account cannot be used as a copied wallet.

• At least one wallet is required.
• Duplicate wallet addresses are rejected.
• The current hard cap is 5,000 followed wallets per strategy.

Buy options

Buy options decide how much the bot buys when a followed wallet creates a valid buy signal, which market-cap range is allowed, and how many buy transactions the bot may send per distinct token while the strategy is running.

Buy size

• Fixed — the bot buys the same amount every time. The amount can be in USD or SOL.
• Proportional to wallet — the bot sizes your buy as a percentage of the followed wallet's buy size. For example, 50% means your quote size is half of the copied wallet's quote size.
• Advanced function (Pro) — the bot maps each copied-wallet buy to your buy using a configurable curve (spread, optional S-curve distortion, and optional bounds). See Advanced function (Pro) below.

Only one sizing mode can be active at a time. The form requires a valid configuration for the selected mode before a strategy can be saved.

Advanced function (Pro)

Use this mode when a flat fixed amount or a single wallet percentage is not enough — for example, to size up on large wallet entries, skip tiny wallet buys, or shape how aggressively your size follows theirs.

The bot compares the followed wallet's buy notional to Wallet buy notional base to get a ratio, applies your Spread coefficient and Sigmoid distortion, then multiplies by Your buy notional base. Optional bounds can block buys or clamp the result.

• Your buy notional base — your reference buy size when spread is 0% (the curve is flat at this amount regardless of wallet size, subject to bounds).
• Wallet buy notional base — the wallet buy size that defines ratio 1. Your size scales relative to wallet buy notional ÷ wallet buy notional base.
• Spread coefficient — 0% keeps every buy at your notional base (inside bounds). 100% scales linearly with the wallet ratio when sigmoid is 0%. Values above 100% amplify size beyond that linear curve.
• Sigmoid distortion — 0% is a straight ratio response; 100% applies a full S-curve (flatter near the ends, steeper in the middle).
• Wallet buy bounds (min / max) — if the wallet's buy notional is outside this range, the bot does not buy (0). Leave empty for no bound. Uses the same unit as your notional bases.
• Limit our buy (min / max) — floor and ceiling on your buy notional after sizing. Leave empty for no bound.

Example use cases

Once the strategy is saved, you can reopen the curve from the summary card: under Size, the f(x) icon marks advanced sizing — click the chart icon beside it to view the curve and all parameters.

Market-cap filters

• Min MC — minimum token market cap, expressed in k$ MC. A value of 50 means $50k market cap.
• Max MC — maximum token market cap, also expressed in k$ MC. A value of 1600 means $1.6M market cap.

Use a minimum market cap to avoid very early / tiny tokens. Use a maximum market cap to avoid copying entries that already ran too far. If both are set, max must be greater than min.

Token programs are selected by the app for this strategy family: the current form sends Pump.fun and Pump.fun AMM as allowed programs.

Buy max per token

This setting caps how many buy transactions the bot may execute for each distinct token during the current strategy session (the count resets when the strategy is restarted).

The default is effectively one buy per token per session. Increase it when you want the bot to scale in on later signals from followed wallets for the same mint before your sell logic or manual exits apply.

Execution

Execution settings decide how hard the bot pushes each transaction into the next blocks, and how much worse the on-chain price is allowed to become before the bot gives up. These numbers are not cosmetic: in fast Solana markets, they can be the difference between landing the copy and missing it.

Priority fees

Priority fees are the native Solana way to pay more for transaction priority. Under the hood, Solana uses compute units: a transaction requests a compute-unit limit, then sets a compute-unit price. The priority fee is based on that requested compute budget, not only on what the transaction finally consumes. Solana explains this in its compute budget documentation.

In this form you enter a simple SOL amount. The app converts it into a compute-unit price for the strategy transaction. Higher priority fees make sense when blocks are busy or when you are copying wallets that trade into crowded launches. If you set it too low, the transaction can sit behind better-paying transactions and land late, or not land at all.

The form minimum is 0.0001 SOL. Treat it as a floor, not as a magic value. Small, quiet trades can often work near the minimum. Competitive tokens usually need more.

Jito tips

Jito tips are different. They are not Solana priority fees. They are tips used on the Jito path, where transactions or bundles go through Jito's block-engine flow. Jito describes this in its low-latency transaction send docs: bundles compete on tips, and the winning flow is sent to validators running Jito-Solana.

Simple version: priority fees help inside the normal Solana fee market; Jito tips help when the transaction is routed through Jito's auction / bundle path. You usually want both set to sane values. Priority fee alone can be too weak during hot launches. Jito tip alone does not replace the regular transaction priority path.

The form minimum is 0.00025 SOL. In quiet markets that may be enough. In contested launches, copy trades, or rug-sniping moments, the tip may need to be much higher because you are competing with other bots for the same blockspace.

How to tune fees

• If you miss entries, raise priority fees and Jito tips. Missing entries usually means you were too cheap, too slow, or both.
• If you land but execution is late, raise them gradually. Late fills often cost more in price movement than the extra fee would have cost.
• If your P&L is eaten by fees, lower them or increase trade size. Very small trades can become unprofitable even when the gross trade is right.
• If the market is calm, do not overpay. The goal is not to maximize fees; the goal is to pay enough to land reliably.

Buy max slippage

Slippage is your price protection. The bot quotes the buy from the current Pump.fun curve state. If the trade would cost more than your configured percentage above that quote by the time it executes, the buy is rejected.

Example: the quote is 1 SOL and max slippage is 18%. The bot accepts the buy up to 1.18 SOL. If the curve moved so much that the buy now needs 1.20 SOL, the transaction is rejected instead of chasing the price.

Higher slippage means more landed buys, but worse possible fills. Lower slippage protects your entry price, but you will miss more trades when markets move fast. For slow wallets or larger tokens, lower slippage can be fine. For very early Pump.fun moves, too-tight slippage often just means you never enter.

Anonymous fees vault

When you use a trading bot, the fees you pay to the bot are usually transferred to one or more vault wallets operated by the service. Some experienced traders can follow these flows and trace them back to you, revealing your transactions and therefore part of your strategies.

The Anonymous fees vault option routes block.λ fees to a private fee vault dedicated to your account. We then retrieve the funds to our operational wallets through anonymous means (for example via CEX and mixers), which makes it much harder for those traders to trace the flows back to you. Use this option if you want maximum confidentiality for your strategies.

Enabling this option increases platform fees by 0.25% and sets the minimum to 0.225$. Use it when confidentiality against wallet trackers matters more than the extra cost.

Sell strategies

Sell strategies decide how the bot exits positions after a buy. You can always use manual sell from the strategy page as an override, even when automatic sell logic is configured. The form’s Mark-to-Market control (next to TP/SL) is documented under Mark-to-Market mode.

When wallet sells

Use this when you want the strategy to mirror exits from the followed wallet. If the followed wallet sells a token you hold, the strategy sends a sell based on the wallet-copy sell type:

• Fixed amount — sell a fixed USD or SOL amount each time the followed wallet sells.
• Position percentage — sell a percentage of your currently open position. Example: 25% sells one quarter of what you hold.
• Copied tx percentage — sell relative to the followed wallet's sell size. Example: 50% tries to mirror half of the copied wallet's sell size, capped by your available position.

If your position is already flat for that token, the mirrored sell is ignored. If the copied sell is larger than your balance, it is capped to your full available position.

Multi TP/SL

TP/SL mode lets you add one or more take-profit, stop-loss, and trailing stop-loss legs. Each line has:

• Side — TP (take profit), SL (stop loss), or TSL (trailing stop loss).
• Type — either % of entry price, % of last max price (TSL only), or Price in k$ MC.
• Target — percentage move from entry price, drop from the running ATH, or exact market cap in K$.
• Size (% of lot) — how much of the original position lot to sell when that leg fires.

TP percentages must be above 1%. SL and trailing SL percentages must be below -1%. Total TP, SL, and TSL sizes each cannot exceed 100%.

Trailing SL

A regular stop loss is tied to your entry price. If you bought at $20k market cap with SL -30%, the bot sells when price falls 30% below entry — even if the token first pumped to $80k and gave back most of the gain.

A trailing stop loss follows the highest price your lot has seen since the buy. The stop line moves up when price makes new highs, but it never moves back down. You choose how far below that peak you are willing to let price fall — for example -15% from the last max.

Example: you enter at $20k MC. Price runs to $50k — that becomes your “last max”. With TSL -20%, the bot sells if price drops 20% below $50k (around $40k), not 20% below your entry. If price keeps climbing to $70k, the trigger moves up with it.

In the form, pick TSL and % of last max price. Trailing stops only work with percentages (not market-cap targets). Sizing uses the same % of lot rules as TP and SL.

How “% of lot” works

In TP/SL mode, a lot is created every time the strategy buy fills. The lot stores the original token amount bought, the remaining token amount still managed, the entry price, and which TP/SL lines already fired for that lot.

This matters because Size (% of lot) is based on the original buy lot, not on the live remaining balance. A 50% TP on a 100-token lot means “sell 50 tokens when this TP fires”, even if the position later contains tokens from other buys.

Multiple buys create multiple lots. If the strategy buys 100 tokens, then later buys 80 more, TP/SL rules are checked per lot. A 50% lot TP can sell 50 tokens from the first lot and 40 tokens from the second lot if both lots hit their trigger.

If several TP/SL lines trigger at the same time, the algo combines the allocations into one sell order, then caps the final size by the real on-chain position balance. If a manual sell or API sell happens outside the TP/SL engine, the algo reconciles lots in FIFO order so future TP/SL sizes do not overestimate what remains. Tiny final sell sizes below 1 token are skipped as dust.

Complex example: several buys + manual sell

Here is the situation that usually creates confusion: the position card shows one token balance, but the TP/SL engine remembers several lots inside that position.

Mark-to-Market mode

Mark-to-Market mode controls which price the strategy uses for valuation and TP/SL checks. This matters because the displayed market price and the price you would receive if you sold now are not always the same, especially on thin curves or larger positions.

Use Spot when you want faster, lighter checks. Use Estimate @ next bid when execution quality matters more than reacting immediately, especially for larger positions or thinner liquidity.

None (manual or API only)

Choose None when you do not want automatic exit logic. You still keep control: you can sell full or partial positions manually from the strategy page, or submit sells through the buy/sell API. This mode gives maximum discretion, but it also means the bot will not auto-close unless you intervene.

Margin

Max margin is a per-strategy risk control. When enabled, it blocks new buys once the selected margin metric crosses the configured limit. Existing positions stay visible and can still be sold.

• Enable max margin — turns the buy-blocking risk system on or off for this strategy.
• Max margin — the limit amount, configured in USD or SOL.
• Mode — selects which metric is compared against the max margin.

PnL Realized

Uses only realized P&L from closed sells. This is the least conservative mode because open positions do not count until they are sold. A strategy can keep buying while open losses are still unrealized.

Total PnL

Uses realized plus unrealized P&L, evaluated in real time for all open positions at market price. This reacts to open drawdown before it becomes realized.

Quote spent

Uses a capital-at-risk view: it includes negative realized P&L and adds position values at entry price. This is the most conservative mode because it treats deployed inventory as risk budget already consumed.

When the selected metric goes beyond the configured limit, new buys are blocked and the app sends a margin-call notification. Selling remains available so you can reduce exposure and free margin again.

Auto-Follow Transfer System (rug sniping only)

For Rug Sniping strategies, the Auto-Follow Transfer System (AFTS) section appears at the bottom of the form. It watches transfers from followed wallets and automatically promotes receiver wallets into your watch list when the transfer meets your configured SOL amount ranges and filter rules.

AFTS is enabled by default on new Rug Sniping strategies. The section includes an enable/disable toggle, optional SOL amount ranges, Remove source after transfer and Wallet always kept (always visible below the ranges), and a collapsible Advanced panel for percentage thresholds and post-transfer balance filters.

Full documentation of every AFTS parameter, default values, and configuration examples is covered in the dedicated Auto-Follow Transfer System page.

Save, edit, and delete

Press Create for a new strategy or Save when editing. If validation fails, the form scrolls to the field that needs attention and shows the server-side message in context. For existing strategies, a delete section appears below the form; delete is irreversible and removes saved strategy configuration and statistics.

Trading bot

Strategy terminal

The strategy page is the command center for one running bot configuration: start or stop the strategy, inspect live performance, review every copied transaction, and manually reduce positions when needed.

---

Page layout

The strategy page should be read as a live risk report. It answers four questions:

• Can the bot trade? Status tells you whether the strategy is stopped, waiting for the algo, actively running, or running with new buys paused.
• How much is still at risk? Mark-to-Market and open positions describe exposure that can still move.
• What is already locked? Realized P&L, daily P&L, and the calendar describe closed results.
• Was execution good? Transaction diagnostics compare your fill against the copied wallet and the best theoretical copy fill.

Summary card

Mark-to-Market is current exposure value, not profit. It answers: “If I sold my open inventory around current mark prices, how much is this inventory worth?”

Unrealized P&L is the estimated gain/loss still inside open inventory. It is useful for risk decisions, but it is not locked until a sell lands.

Daily P&L is realized performance since midnight in your timezone. Open positions do not count there until they are sold, which makes it better for judging what the strategy has actually banked today.

PnL w/ fees switches from gross trading result to net result after known execution costs. Use gross P&L to evaluate entries/exits; use fee-inclusive P&L to evaluate real profitability.

Control your strategy

While a strategy is running, the summary header shows Pause (or Resume when buys are paused), Stop, and a ⋮ menu on the right. Use Start when the strategy is stopped.

Pause and Resume buys

While a strategy is running, you can temporarily pause new buys without stopping the session. Click Pause in the summary header. The bot keeps managing open positions: take-profit, stop-loss, and manual sells still apply. It simply stops opening new copy positions until you click Resume.

The status badge shows Paused when buys are paused but the session is still active. After you click Pause or Resume, the buttons and badge update once the server and algo confirm the change. You also receive an in-app notification (and on Telegram, if linked) when buys are paused or resumed.

Pause is not the same as Stop: stop ends the session and requires flat positions for a normal stop. Pause is for a short break from new entries while existing exposure stays under bot management.

Stop (normal)

Stop tells the bot to end the session cleanly. The server only accepts a normal stop when there are no open positions (non-flat balances) in the current session. If you still hold tokens, close or manually sell them first, then stop again.

Status moves through Running → stopped. If the algo is slow to acknowledge, the UI may show Awaiting algo briefly after start; the same stop rules apply once a session is active.

Force stop

When the strategy is running, open the ⋮ menu and choose Force stop if you need to halt the bot while tokens are still held. This is an emergency override, not a substitute for selling.

• A confirmation dialog explains that open inventory will not be sold automatically.
• To proceed, you must type force stop exactly and confirm.
• Tokens remain in your wallet; the bot no longer manages them. You are responsible for monitoring and selling manually.

Margin and max-margin controls

Margin / Max is the strategy’s buy-blocking risk limit. The current margin comes from live strategy stats; the strategy is at limit when that margin is lower than or equal to -Max. In that case, the bot blocks subsequent buys and sends a margin-call notification. Existing positions still remain visible and can be sold.

Mode	Meaning
Realized PnL	Checks realized P&L only. If realized P&L is below -Max, the bot blocks subsequent buys. Open positions do not affect this mode until they are sold.
Total PnL	Checks realized plus unrealized P&L on open positions. If total P&L is below -Max, the bot blocks subsequent buys. This mode reacts to open drawdown before it is realized.
Quote out	Checks realized P&L minus open positions valued at average entry price, in the configured quote unit. If that value is below -Max, the bot blocks subsequent buys. This mode limits how much quoted capital is still committed to the market.

The max amount can be configured in USD or SOL. The mode label after the max value, for example (Total PnL), tells you which calculation is driving the block.

Charts

Use short periods (1s, 15s) to inspect fast execution moments. Use longer periods (15m, 1H) to judge session direction without micro-noise.

PnL chart

The PnL chart plots four series so you can separate locked results from open exposure, and compare gross trading performance with net performance after fees.

• PnL realized (solid amber) — profit or loss already booked from closed sells. It moves in steps: flat while nothing closes, then jumps when a sell finalizes.
• PnL unrealized (solid red) — estimated P&L on what you still hold; it moves continuously as mark prices change.
• PnL realized fees incl. (dashed amber) — same stepped realized curve, but after known execution costs. Usually sits below solid realized when fees matter.
• PnL unrealized fees incl. (dashed red) — unrealized P&L if you closed at current prices and paid fees; tracks the volatile path slightly below solid unrealized when costs are material.

How to read it: Compare solid vs dashed to see how much fees erode results. Compare amber vs red to see how much P&L is still floating in open positions versus already locked in. If gross and fee-inclusive lines drift far apart, execution costs are large relative to trade size.

Margin chart

Switch the chart type to Margin to see how your current margin tracks against the configured cap (max margin). This view is for risk limits, not for P&L.

PnL calendar

The calendar is for realized day-by-day consistency. It ignores open risk until positions are sold, so it is better for answering “what did this strategy actually bank?” than “what is open right now?”

PnL w/ fees changes whether daily buckets include execution costs. PnL in $ converts values to USD using the available SOL/USDT rate; disabling it is useful when you want to reason in raw SOL terms.

Positions

A position groups all buys and sells for one token in the current session. Realized belongs to the part already sold; Unrealized belongs to the remaining balance. After a partial sell, both can exist at the same time.

Avg. Price is displayed as average entry market cap, so it can be compared directly to execution market caps in the transaction table.

Field	Meaning
Token header	Shows the token mint shortcut. The copy icon copies the mint address; the GMGN icon opens external token analysis.
@ market cap	Current mark-to-market market cap for the token. The percentage beside it compares current market cap to the position’s average entry market cap.
Show Txs	Filters the Transactions table to this token and scrolls there. Use it to explain why a position has its current balance, realized P&L, or unrealized P&L.
Balance	Remaining token amount still held by the strategy. If the position is flat, there is no meaningful open exposure left for that token.
Avg. Price	Average entry market cap across buys for the position. It is not a per-token price; it is shown as market cap so it can be compared with executed M.C. in the transaction table.
MtM	Mark-to-Market value of the remaining balance at the current token mark price. This is exposure value, not realized profit.
Realized	P&L already locked by sells for this token. With PnL w/ fees enabled, this is shown after known fees.
Unrealized	Estimated P&L still attached to the remaining balance. It changes with market price and becomes realized only when a sell executes.
Last update	Timestamp of the latest position refresh, useful for checking whether a stale-looking value is actually recent.
Sell partial / Sell full	Manual override actions. Partial sell realizes only the selected percentage; full sell requests an exit of the remaining balance.

Manual selling

Manual selling is an override for risk reduction. A full sell exits the remaining balance; a partial sell realizes P&L on the selected percentage and leaves the rest exposed.

Manual sells appear in the transaction history as manual transactions. They do not have a copied trader or copied transaction because the decision came from you, not from a followed wallet signal.

Transactions table

The transaction table is where you diagnose execution quality. The summary and position cards tell you the result; this table explains how that result was produced.

Newest first changes sorting. Display full date switches from relative ages to exact timestamps. Quote in $ controls whether quote amounts, market caps, fees, and P&L are expressed in USD or SOL.

Important columns

• Total is the notional size of the transaction in the selected quote currency. It is useful for checking whether the strategy respected the configured order size.
• M.C. is the market cap at which your transaction executed. For copy trading, this is the most important fill-quality number.
• Copied Tx is the source transaction the bot followed. Its market cap is the price reference of the original wallet action.
• Target M.C. is the best theoretical market cap if your transaction had landed immediately after the copied transaction. It uses the program bonding-curve formula to estimate the best price you could possibly have with your trade size if your transaction is exactly the next one after the copied transaction. The gap between executed M.C. and target M.C. estimates the cost of latency and queue position.
• Fees is not just the platform fee. It can include Pump.fun/PumpSwap fees, block.λ fees, priority fees, and Jito tips. High priority or Jito spend can make gross P&L look better than net P&L.
• PnL appears on sells because profit is realized when inventory is closed. Buys usually show no realized P&L because they open or increase exposure.

Tooltips and execution diagnostics

The colored dots next to M.C. compress execution quality into a quick signal. Green means the fill was close to the reference; yellow/orange/red mean the fill moved farther away. For buys, paying a higher market cap than the reference is bad. For sells, receiving a lower market cap than the reference is bad.

Mobile behavior

On smaller screens, dense option rows move into compact menu dialogs: position options, chart period selection, and table options stay accessible without forcing the main layout to overflow. The data stays the same; only the control placement changes.

Trading bot

Imported wallets

Besides your primary trading wallet (created when you onboard), you can register additional Solana keypairs so each strategy can execute from a different address — for example, to add your axiom / gmgn wallets and execute the strategies on them.

---

What “imported” means

An imported wallet is a Solana address you add by supplying its private key once. The app derives the public key, checks that the address may be registered to your account, then stores the key material in the same custodial path as your main trading wallet so the bot can sign transactions on your behalf.

Where to manage them

Open your Profile menu (top right) and use Import wallet to add a key, or Imported wallets to see the full list.

The list always shows your trading wallet first (the Blocklambda-generated custodial wallet). Additional rows are wallets you imported yourself.

Import flow

• Private key — Paste a Solana secret key as base58 text or as a JSON byte array (the same formats many wallets export). As soon as the key parses, the form shows the derived public key and loads a live SOL balance preview from the chain.
• Optional name — Up to 40 characters, shown in the list to help you tell wallets apart.
• Import — The button stays disabled until the key is valid, the preview balance loaded successfully, and ownership checks pass. After a successful import, the key field is cleared.

Per-strategy execution wallet

On Create / Edit strategy, the Execution section (priority fees, Jito tips, slippage) also includes which wallet signs trades for that strategy. By default the bot uses your trading wallet; you can pick any imported wallet from the same list. Use Manage imported wallets from that section to jump back to the list or import another key without leaving the form.

Security notes

Your responsibility. Never share a wallet’s private key with anyone — not “support,” not moderators, not other traders. Anyone who obtains it can drain the wallet.

Check the real site. Before you paste a private key, confirm your browser’s address bar shows blocklambda.com with HTTPS (the lock icon). If the host name is anything else, or if someone sends you a link by DM claiming it is the app, treat it as a phishing attempt and do not sign in or import keys there.

Treat imported keys like any hot wallet: only import addresses you intend the bot to control, and remove imports you no longer need. Key material is kept server-side for signing and is not exposed again in API responses after import — same custody model as your primary trading wallet (see Trading Setup).

Get Started

Trading Setup

Configure your trading wallets, copy strategies, and automatic position management.

---

Wallets

Manage the Solana wallets your bot uses to execute trades. block.λ supports multiple wallets per account, each assignable to separate strategies.

Add a wallet

Navigate to Settings → Wallets and click Add wallet. Paste your Solana private key in base58 or JSON array format. The key is encrypted with AES-256 before storage and is never returned in API responses or logs.

Multiple wallets

You can configure multiple wallets and assign each to different strategies. This lets you separate risk exposure — for example, one wallet for copy trading and a separate one for rug sniping with a different SOL limit.

Balance monitoring

The dashboard shows each wallet's current SOL balance in real time. A warning is shown when a wallet's balance drops below your configured minimum reserve.

Strategies

A strategy defines the entry and exit logic applied to every copy trade. You can run multiple strategies in parallel, each pointing to a different wallet and target wallet set.

Preset strategies

• Classic Copy — buy when the target wallet buys, sell when they sell.
• TP/SL Auto-Close — buy on signal, auto-sell at configurable take-profit or stop-loss percentages.
• Timed Exit — buy on signal, auto-sell after a fixed duration regardless of price.
• Trailing Stop — buy on signal, auto-sell when the price drops a configurable % below the running high.

Custom strategies

Contact our team to implement custom signal logic. Examples include: "enter when buy count in last 12s > 60 AND total fees paid in last 60s > $20" or "copy only when wallet has made 3+ profitable trades this week".

Custom strategies are available on Pro and Expert plans.

Take-Profit & Stop-Loss

TP/SL parameters can be set globally (for all positions in a strategy) or overridden per-position directly from the dashboard. Monitoring runs on-chain at sub-second granularity — positions are closed as soon as the condition is detected in the shred stream.

Parameters

Parameter	Description	Default
take_profit_pct	Sell when position is up this %	None (manual)
stop_loss_pct	Sell when position is down this %	None (manual)
trailing_stop_pct	Trail below the running high by this %	None
max_hold_seconds	Force-close after this many seconds regardless of price	None

Per-position overrides

Expand any open position row in the dashboard and click Edit TP/SL to set values that override the strategy defaults for that specific position only. Useful when you want to lock in a profit on one position without changing the strategy globally.

Trading bot

Notifications

Get in-app and Telegram alerts for everything that happens on your strategies, with the execution detail you need to trust each fill.

---

Link Telegram and enable alerts

What you will receive

After linking, messages cover every type of event tied to your strategy — for example: trades, errors, and strategy start / stop, pause / resume of buys (and similar lifecycle updates). Each notification is built to be actionable, with full context on execution, including where relevant:

• Slippage — how far the fill moved versus expectations.
• Target price — the reference price (e.g. from the lead wallet or the intended level).
• Copied (fill) price — the price at which your copy was executed on-chain.

Token identity, size, and links to on-chain data (e.g. Solscan) are included as appropriate to the event type.

Product

Release notes

Notable app updates, grouped by version and release date.

---

v2 — 3 June 2026

Advanced buy sizing, rug-sniping defences, live strategy controls, AFTS limits and mother-wallet tracking, separated buy/sell execution fees, and in-app RPC billing for analysis workloads — plus strategy naming and list ordering.

Copy trading

• Feature Advanced buy sizing — Control your exposure relative to the wallet you copy based on its buy amount. See the documentation.
• Feature Trailing stop loss — Add TSL to trail the highest price each lot has seen since entry, so exits can lock in gains after a pump without selling at a fixed level from entry. See Trailing SL.
• Feature Separate buy and sell execution fees — Set different priority fees and Jito tips for buy transactions versus sell transactions in the strategy form Execution section.
• Feature Strategy name & description — Label strategies in the form for your own reference; these fields do not change execution logic. See General.
• Feature Reorder strategies — Drag the move handle on the strategy list to set the order strategies appear in your terminal.
• Feature Pause / Resume strategy — Pause a strategy when you want sells to keep running and AFTS to keep following wallets (rug sniping), while blocking all new buys. See Pause and Resume buys.
• Feature Force stop — To stop a strategy on block.λ, every position must be closed. If you sold outside the terminal, you can no longer sell from the app — you can force stop the strategy instead if you fully understand the risks. See Force stop.

Specific to rug sniping

• Feature Rug sniping / Front-run sell — Exit before a rugger dumps when the bot detects an abnormal burst of token transfers in a short window. Configure the time window, minimum transaction count, and minimum total tokens moved. See the Front-run sell documentation.
• Feature Rug sniping / TRS (Transfer Replay Service) — Find a rugger again, automatically analyze patterns you could never decode by hand, and capture every buy and every token creation from thousands of wallets in the same scheme — in about 2 minutes. See the documentation.
• Feature RPC in-app balance & top-up — A USD balance is linked to your account and pays for all analyses: TRS, backtests, and more. Add funds directly in the app, or use the credits included with your plan.
• Feature Rug sniping / AFTS limits — Up to 1,000 wallets on the watchlist and 1,000 followed transfers per rolling hour per strategy. Track your limits in real time in each strategy’s terminal. See Limits.
• Feature Rug sniping / AFTS: Wallet always kept — Keep wallets on your watchlist without removing them when they send a new transfer. Use this for mother-wallet schemes. See the documentation.

Bug fixes

• Bug AFTS replay — Reported 3 June, fixed: replay did not follow a wallet due to a commitment-level mismatch (was finalized, should have been confirmed).
• Bug Onboarding: SMS — Reported 2 June, fixed: SMS could not be sent to non-French phone numbers.
• Bug Onboarding: referral — Reported 2 June, fixed: prefilling a referral username caused an internal error.
• Bug PnL cards on Discord — Seen 20 May, fixed: some PnL cards were not posted automatically to Discord when token supply was not yet available for very fresh mints.

No bugs on the trading bot were reported.

v1.2.0 — 18 May 2026

Rug-sniping workflow upgrades (AFTS overhaul, saved rug filters, buy limits), new long-term subscription tiers, and an official referral program — plus faster rug discovery and upstream API / protocol alignment.

• Feature Rug sniping: Auto-Follow Transfer System (AFTS) — Fully reviewed. Every option is now exposed in the strategy form, and we added an RPC replay path so ultra-fast ruggers who hop from wallet to wallet in tight bursts are still evaluated against your rules. See the Auto-Follow Transfer System documentation.
• Feature Rug sniping: Saved filter presets — Save filter configurations as named presets and switch between them quickly from a dedicated menu.
• Feature Buy options: max buys per token — Configure a maximum number of buys allowed per token from the buy options.
• Feature Pricing: 3-month and 1-year plans — New billing periods with 30% and 50% discounts versus monthly pricing.
• Feature Official referral program — In-app referral codes and shareable links; see the Referral program documentation.
• Bug Improved performance of rug live analysis — the rug list now loads roughly 2–3× faster.
• Bug Integrated GMGN API changes after a major upstream update.
• Bug Pump.fun — Updated buy/sell instruction builders for the new account layout on Pump.fun trades.

v1.1.0 — 12 May 2026

Wallet import with per-strategy assignment, rug list filtering on all tracked metrics, full support for custom on-demand strategies with live terminal stats, shareable PnL cards verifiable by QR code, and Discord account linking — plus a few bug fixes. The bot had been stable for two days with no new reports at release time.

• Feature Wallet import & per-strategy assignment — Import your own wallets and assign a specific wallet to each strategy. Enables multi-wallet buying on the same token by running multiple strategies each bound to a different wallet. Import from Profile (top-right) → Import wallet; assign from the strategy's Edit → Execution section.
• Feature Rug list filters — Filter the rug list by any tracked metric — ATH, bundle rate, market ratio, and time to ATH — in addition to sorting by column.
• Feature PnL cards — Generate and share cards from transaction history using Share next to any realized PnL. Each card includes QR code verification so anyone can confirm trade authenticity.
• Feature PnL card privacy — Privacy Mode hides the traded token and the trade date on shared cards so others cannot reverse-engineer your strategy from a screenshot.
• Feature PnL card themes — Designs use air-transport motifs: the higher your return, the more advanced the vehicle — from gliders to rockets.
• Feature Custom on-demand strategies — Request fully custom strategies from the Blocklambda dev team. They run inside the terminal with multiple independent instances, custom parameters per instance, and separate PnL tracking, execution statistics, and position monitoring.
• Feature Discord integration — Link Discord during onboarding; linked accounts receive the Blocklambda Member role for full access to the server. Manage the connection anytime from Settings.
• Feature Pump.fun launchpad updates — Support for the latest Pump.fun launchpad changes, including the PumpSwap migration path and creator royalty updates. See Pump.fun Updates 2026 for more detail.
• Feature Official Discord — The official Blocklambda Discord server is now live.
• Bug Fixed float precision drift affecting custom sell executions (reported by Leo).

No other bugs were reported in this release.

v1 — 5 May 2026

Focus: self-serve strategy management, richer copy-trading controls, and critical strategy/position reliability fixes.

• Feature Added an in-app strategy form: you can now create, edit, and delete strategies directly in the app, without going through the dev team.
• Feature Added copy-sell automation with three modes: position percentage, copied transaction percentage, or fixed amount.
• Feature Added proportional copy-buy sizing.
• Feature Added multi TP/SL per lot — each buy creates its own lot with independent TP/SL tracking. How it works →
• Feature Added fee-tier visibility in the strategy summary.
• Bug Fixed a cross-strategy position display issue where positions from another strategy (same user) could appear on the wrong strategy page. Each strategy page now shows only its own positions.
• Bug Prevented strategy edits while a strategy is still running, so configuration changes are only allowed once the strategy is fully stopped.
• Bug Fixed a dust-position deadlock: some tiny token remainders (MtM below $0.01) could hide sell actions while still blocking strategy stop. Strategies can now be stopped cleanly even when dust remains.

v0.2.0 — 27 Apr 2026

Focus: max-margin risk controls, margin visibility, and fixes for recent pump.fun migration changes.

• Bug Updated the PumpSwap (Pump AMM) buy instruction builder after the protocol began requiring two extra accounts for coin creator fees (coin_creator_vault_ata, coin_creator_vault_authority). See Pump.fun breaking fee recipient upgrade in pump-public-docs.
• Feature Added the max-margin system to the algorithm, including a dedicated margin chart and notifications when the configured margin threshold is hit.
• Bug Fixed an issue with tokens that changed programs during migration from pump.fun to AMM.

v0.1.0 — 23 Apr 2026

Focus: notifications, Telegram account controls, and a rebuilt strategy P&L experience driven by live strategy stats.

• Feature Notifications — Full notification system: in-app panel with separate new and read items, a layout tuned for mobile, and delivery to Telegram for supported events.
• Feature Telegram in Settings — Link or unlink your Telegram account from the dashboard so alerts go to the account you intend.
• Feature Strategy PnL chart — Rebuilt on the global strategy stats event stream, including realized and unrealized P&L, with series both including and excluding fees.

Product

Scheduled for next major release

Planned features for the next major version.

---

Target date

Features

• Feature Smarter error notifications — The app will separate errors you can fix yourself (slippage too tight, insufficient funds, and similar) from real bot bugs that need an engineering fix. User-actionable errors will be clearer in the notification panel.
• Feature Backtest interface — Using your RPC balance, backtest any set of buys and find the best optimized TP/SL combination for your rules.
• Feature Flexible OTP verification — SMS OTP will no longer be mandatory. If you skip SMS verification, linking Telegram becomes required instead.
• Feature Better display of imported wallets — Richer views for every imported wallet, including realized P&L charts with and without fees.
• Feature TP/SL on wallet-copy sells — Add TP/SL at the same time as copying the wallet’s sells (today it is one or the other, not both).
• Feature Min / max token age on buy — Filter copy buys by how old the token is (minimum and maximum age since creation).
• Feature Playground strategy (manual buys) — A dedicated strategy to buy tokens manually at lower cost: block.λ fees are about 2× cheaper than GMGN, Axiom, Bloom, Tradewiz, and similar tools. Members will be able to buy any token on the platform at lower cost.

Product

Referral program

Share block.λ with a personal link and earn a commission when referred users subscribe.

---

Overview

After you opt in from Profile → Referral in the app, the product generates a short referral code and two ready-to-share URLs: one for the copy trading landing page and one for rug sniping (/rugs). Each URL includes a ?ref=… query so new visitors are attributed to you when they sign up and complete onboarding.

In the app: Open Referral.

Reward tiers

Your account is assigned one of three program levels (shown on the Referral page). The in-app copy matches what you see there:

• Member — 25% of the first subscription payment from each user who signs up through your link.
• Partner — 25% on every subscription payment, including renewals, for the full lifetime of each referred subscriber.
• Custom partnership — rates and eligible products are agreed with the team; use support / Discord to clarify your deal.

Active community contributors (moderation, content, KOL work) can apply for a higher tier via the partnership contact in the app.

Payouts

Eligible referral commissions appear in the Referred payments table on the same page. Payouts are sent manually on a ~24h cadence to your block.λ trading wallet; each row eventually shows Paid with an on-chain transfer reference, or Pending payment while it is queued.