Gmgn Copy Trading Settings for Buys and Sells

Gmgn copy trading on Solana combines a buy-sizing rule with a separate exit method for copied positions. Fixed buys use a chosen amount, while maximum follow-buy caps each purchase. Follow-up sells mirror the target wallet's sold proportion within that task's holdings; take-profit and stop-loss settings use price-based exits.

Fixed buys and maximum follow-buy

Fixed buy amounts

Fixed buy uses your configured amount for each eligible purchase, regardless of how much the target wallet spends.

Capped follow buys

Maximum follow-buy uses the smaller of the target purchase amount and your configured cap. This limit applies to each buy.

Target purchase filters and token eligibility

Target-amount filters determine whether a purchase qualifies for copying. Their minimum and maximum refer to the target wallet's spending. A trade above that maximum is skipped, whereas maximum follow-buy caps your purchase.

Other filters cover market capitalization, pool liquidity, token age, and the pool's burnt ratio. Platform filtering restricts copied buys without blocking follow-up sells.

Sell methods and their prerequisites

The sell method determines what initiates an exit from the copied position.

Which holdings does a copied sell affect?

Automatic follow-up selling acts only on tokens acquired by the corresponding copy task. Manually bought tokens and purchases from other copy tasks remain outside that sell calculation.

Copy-task take-profit and stop-loss thresholds

Average entry price

Copy-task take-profit and stop-loss use the copied position's average entry price. Enabling these rules disables following the target wallet's sells.

Batch sell rules

Batch rules sell configured proportions of the current copied position. Each rule fires once without new additions; adding tokens recalculates the rules from the updated average price.

Slippage limits and transaction spending

Slippage tolerance controls how far the received amount may deteriorate from the quoted output. A wider limit permits a worse fill, while a tighter limit can reject a trade during rapid price movement. The tolerance itself does not represent a separate fee payment.

The standard Gmgn handling fee is 1% of the trade amount. Network charges and any applicable token-platform charges add separate costs. Consequently, the configured buy amount does not represent the entire wallet debit, and a sale's gross proceeds do not equal its net balance increase.

Solana transaction fees include a base fee and any configured prioritization fee, payable in SOL. Priority fees affect transaction scheduling. The trading controls also distinguish node tips from priority fees; those payments serve transaction delivery rather than the platform's handling charge.

Solana charges transaction fees even when a transaction reaches execution and fails. Repeated failed attempts can therefore reduce the available balance without producing a copied token purchase. Increasing execution fees also increases the cost of each attempt that incurs them.

Repeated buys and position additions

The position-increase setting limits additional purchases of the same token while a copied position remains open. Clearing that position resets the allowance.

A per-purchase cap does not establish a total spending ceiling across repeated eligible buys.

Lightning mode and unconfirmed activity

Lightning mode uses unconfirmed transaction messages. Solana's processed state reflects a node's newest processed block, which can still roll back. Acting on that state prioritizes an earlier signal over stronger confirmation.

A copied trade can execute even if the target transaction disappears from the chain's accepted history. Lightning mode can also cause duplicate execution or detect a sell before a buy, disrupting automatic follow-up selling.

Why can a copy task miss a trade?

A copy task can miss a trade because its filters reject the purchase or transaction execution fails. After 3 consecutive failed copied buys or sells, Gmgn pauses the task and sends a notification.

An execution wallet needs enough SOL for the purchase and transaction charges. A sell also needs the relevant token balance. These requirements apply at execution, so creating a task does not establish that later trades have sufficient funding.

Price movement beyond the permitted slippage can prevent execution. Network congestion, a node-service problem, or an unavailable trading route can also interrupt an order. Removing the pool's liquidity can eliminate its trading route; a larger priority fee does not replace missing liquidity.

Open full-size image

A timeout can occur after a transaction succeeds. Its on-chain outcome determines whether another order would repeat an executed trade. Distinguish failure before submission from failure during execution, because only the latter necessarily reaches the stage where network fees apply.

Execution wallets and account continuity

Telegram-authenticated accounts can access Solana wallet-copy tasks through the web interface and Telegram bot. Their target address supplies the trading signal; the execution wallet supplies the assets.

Account access and available funds are separate. Connect Phantom requires at least one Solana wallet and creates a custodial account with platform wallet addresses rather than spending directly from the connected Phantom wallet. Direct trading through the separate Trade with Wallet option uses a different account context and does not support Gmgn automated trading.

The task's execution address identifies the balance that must support its purchases and transaction charges. A connected wallet's displayed balance does not establish that the task can fund its next trade.