# Pump.fun AMM Swap ## BUY SETTINGS *** ### **nodes:** Select node that will be used to send GPA request, if you didn't fill Liquid pool field *** ### NodesToken Select node that will Monitor the price of the token {% hint style="warning" %} We don't use WebSocket or Geyser for monitoring because some nodes are unstable, so we send a simple GetProgram request to the node to receive the actual price of your position. {% endhint %} *** ### NodesTX Select node that will send buy transactions *** ### **wallet** select your wallets *** ### **Token in** Insert token address which you will spend in the trade (Example: If you want to buy some token/sol pair insert sol address ) {% code overflow="wrap" %} ``` So11111111111111111111111111111111111111112 ``` {% endcode %} *** ### **Output Token** Insert token address that you want to buy in the trade *** ### **Liquid Pool** input Liquid Pool address of the token
{% hint style="warning" %} You can leave this field empty, if there are only 1 original pool.\ If you want to buy specific pool, enter it in this field {% endhint %} *** ### Buy tx Amount of transaction that bot will send to buy coin. Buy TX input explanation: {% code overflow="wrap" %} ``` In Buy TX, you can input only two values, separated by a comma. The first value is the number of transactions the bot will send during your initial attempt to buy a token. The second value is the number of transactions the bot will send in subsequent attempts to buy the token again, if the first attempt fails. If you have more than one retry attempt, all subsequent attempts will use the number of transactions specified by the second value of #BuyTX. Example:50,35 50: The number of transactions the bot will send for the first attempt to buy. 35: The number of transactions the bot will send for the second and any further attempts. If you need only one attempt to buy a coin, you should input a single value representing the number of transactions the bot will send to buy the coin. Example:50 50: The number of transactions the bot will send to buy coin. ``` {% endcode %} Tips for Buy TX field: 
f you are using a Node, always check its TPS (Transactions Per Second) and avoid overusing it, as this can result in getting rate-limited.

The number of transactions depends on your fees, and you have several options here:

1.Lower fees and a high number of transactions (to spam the block with your transactions) with SAME TX disabled.
2.High fees and a low number of transactions with SAME TX disabled.
3.High fees and a high number of transactions with SAME TX enabled.

Each of these strategies has advantages and disadvantages depending on the module you are using:

Spamming with SAME TX disabled tends to result in better transaction landing compared to SAME TX enabled.
However, with SAME TX enabled, you can significantly increase your fee and the number of transactions you send.
The best approach is to test and choose the option that works best for your specific scenario.
*** ### Delay buy This is the time that the bot waits before sending the next transaction, measured in milliseconds. Delay buy input explanation: {% code overflow="wrap" %} ``` In Delay Buy, you can input only two values, separated by a comma. The first value is the delay between transactions during your first attempt to buy a token. The second value is the delay between transactions during your next attempts to buy the token again, if your first attempt fails. The second value is intended for use in #buyTX after a failed transaction. If you have more than one retry attempt, all subsequent attempts will use the delay specified by the second value of #Delay Buy. Example:1,3 1: The delay between transactions for the first attempt (First value in buyTX). 3: The delay between transactions for the second and any subsequent attempts (Second value in buyTX). ``` {% endcode %} Tips for delay buy: {% code overflow="wrap" %} ``` If you use a regular node, the optimal delay between transactions is 1 ms. This means that before sending each transaction, the bot will wait 1 millisecond, allowing you to spam within a single block and increase your chances of a successful transaction. If you use JITO, the recommended delay is 200 ms. However, you can also choose a random location for JITO in the settings and try to reduce your delay further. Test your setup to find the best delay that avoids rate limits. ``` {% endcode %} *** ### Fee buy in sol A fee in Solana is a small amount in SOL tokens that users pay for conducting and confirming transactions on the Solana blockchain. Input in this field fee in SOL {% code overflow="wrap" %} ``` In Fee Buy, you can input only one value. The fee that you input will be used for the main attempt to buy (for the first value in the Delay Buy and Buy TX fields) and for subsequent attempts to buy the coin again (for the second value in Delay Buy and Buy TX fields) if the first attempt fails. You can also use this field as the fee for sending a JITO TIP. If you enable JITO BUY and fill in the JITO TIP field, you can also fill in the Fee Buy field, and this value will be used as the fee to send the swap transaction. ``` {% endcode %} Tips for Fee buy field: {% code overflow="wrap" %} ``` if you use the SAME TX for buying or selling, it reduces costs because you avoid failed transactions, with only one successful buy. This allows you to significantly increase your fees. However, keep in mind that spamming with unique transactions is generally more effective than repeating the same transaction multiple times. Therefore, if you choose to use SAME TX, always increase your fees to improve your chances. ``` {% endcode %} *** ### Tip Buy sol Jito / nextblock / temporal will be sent with fee in SOL that you input in this filed {% code overflow="wrap" %} ``` Also you can send buy transaction using usual node and jito bundle to use this input fee in sol in fee buy/sell field(s) Usual fee will be in swap transaction ``` {% endcode %} {% code overflow="wrap" %} ``` Additionally, your fees should depend on which module you are using. If you experience unsuccessful transactions in 99% of cases, it's likely due to low fees, low Buy/Sell TXs, or large delays between transactions. ``` {% endcode %} *** ### **Compute units** Compute Units in Solana measure the computational resources consumed by a transaction. The more units used, the higher the transaction cost. ``` 70000 - if precreate ata disabled 35000 - if precreate ata enabled ( check guide on precreate ata pls ) ``` *** ### Slippage Absolute **Slippage absolute** is the minimum number of tokens you will receive after a purchase. If the amount is less than what you specified, the transaction will fail. *** ### Slippage Percent **Slippage percent** is the maximum token amount deviation you’ll accept. If it’s exceeded, the trade won’t go through. Because our contract uses a fixed price for the trade, this affects the token amount you will receive. {% code overflow="wrap" %} ``` Example: 10 You send a transaction expecting to receive 1 million tokens. While it’s processing, someone makes a whale buy, and now you only receive 700k tokens. The transaction fails because the token amount deviation exceeds 10%. ``` {% endcode %} *** ### Buy amount Amount of sol that you want to spend to buy token *** ### Slot Difference Enter the maximum number of slots the transaction should go through; otherwise, the transaction will fail. *** ### Retries Buy This field is used to specify the number of attempts to buy a coin again if the initial attempt fails. Attempt - amount of transactions from [#buy-tx](#buy-tx "mention") and delay between them from [#delay-buy](#delay-buy "mention") Retries Buy input explanation: {% code overflow="wrap" %} ``` In Retries Buy, you can input only one value. This value represents the number of attempts to buy the coin again, using the second value from #BuyTX and #DelayBuy. Example:3 This means that the bot will make 3 attempts to buy the coin again if your main attempt fails (the main attempt refers to the first value from #BuyTX and #DelayBuy). The retries will occur if the main attempt does not go through within the time specified by the first value in #RetriesDelay (in milliseconds). ``` {% endcode %} {% code overflow="wrap" %} ``` If you don't need Retry attempt you can leave this field empty. ``` {% endcode %} *** ### Retries delay This field is used to specify the delay between attempts to buy coin. Retries Delay input explanation: {% code overflow="wrap" %} ``` In Retries Delay, you can input only two values in milliseconds, separated by a comma. If you have more than 1 retry attempt, you should input 2 values: Example:10000,20000 The first value is the delay between your main attempt and the first retry attempt. The second value is the delay between subsequent retry attempts. ``` {% endcode %} ``` If you have only 1 attempt, you should input input 1 value. Example:10000 It will be delay between your main attempt and retry attempt. ``` ``` If you don't need Retry attempt you can leave this field ``` *** ### Only Buy Enable if you want to buy a token and not sell via vision sell tab ( token will not appear there ). *** ### Precreate Ata Bot will create token ATA, so you will be able to reduce your Compute units to 35000 {% hint style="danger" %} If you enable Precreate ATA make sure to use Jito or Same TX, otherwise every transaction that you send will be successful {% endhint %} *** ### **Send Separate** Works only if you have enabled multiple token-buying services (e.g., Jito, Nextblock, Temporal anti-MEV). When enabled, each service sends a unique transaction. You are charged only for the successful transaction. For any failed transactions (only the Jito, Temporal, and Nextblock toggles may fail; anti-MEV cannot), you pay only the **Fee buy in SOL** — the **Tip Buy SOL** is not charged on failed transactions. When disabled, you will send every service that you enabled in one transaction and pay Tip Buy SOL for each service.

Disabled

*** ### 0Slot Enabled - bot will buy tokens using 0Slot service without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### **JITO** Enabled - bot will buy tokens using Jito without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### JITO 95% Tip Enabled - bot will send transaction via JITO with 95% chance of successful landing. It will be dynamic TIP that bot requests from JITO API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable JITO or JITO anti-mev toggle to send tx with mev protection or without and after that enable JITO 95% TIP. JITO API: {% endhint %} *** ### JITO 99% Tip Enabled - bot will send transaction via JITO with 99% chance of successful landing. It will be dynamic TIP that bot requests from JITO API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable JITO or JITO anti-mev toggle to send tx with mev protection or without and after that enable JITO 99% TIP. JITO API: {% endhint %} *** ### Jito Anti-mev Enabled - bot will send jito bundle with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Jito Only bundle If you want to use this toggle **enable JITO toggle.** Enabled - bot will send jito bundle without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### NextBlock Enabled - Bot will buy tokens using Nextblock without mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} Mininmum TIP is 0.001 sol {% endhint %} Docs: *** ### Nextblock Anti-mev Enabled - Bot will buy tokens using Nextblock with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} Mininmum TIP is 0.001 sol {% endhint %} Docs: *** ### Temporal Enabled - Bot will buy tokens using Temporal without mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Temporal 95% Tip Enabled - bot will send transaction via Temporal with 95% chance of successful landing. It will be dynamic TIP that bot requests from Temporal API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable Temporal or Temporal anti-mev toggle to send tx with mev protection or without and after that enable Temporal 95% TIP. Temporal API: {% endhint %} *** ### Temporal 99% Tip Enabled - bot will send transaction via Temporal with 99% chance of successful landing. It will be dynamic TIP that bot requests from Temporal API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable Temporal or Temporal anti-mev toggle to send tx with mev protection or without and after that enable Temporal 99% TIP. Temporal API: {% endhint %} *** ### Temporal Anti-mev Enabled - Bot will buy tokens using Temporal with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Normal TX Use this toggle if you enabled multiple sending transaction services( jito, nextblock, temporal ) Enabled - bot will send usual transaction via node that you selected in NodeTX with other services that you enabled, Disabled - Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Same TX This toggle is used to switch between sending unique and non-unique transactions. Explanation: {% code overflow="wrap" %} ``` Disabled Toggle: This means that you will send unique transactions. In this case, 1 transaction will be successful, and the other transactions will fail. You will need to pay a fee for each transaction that is landed on the chain. Enabled Toggle: This means that you will send 1 transaction X times, as specified in #BuyTX. With this option, you will have only 1 transaction on the chain and no failures. ``` {% endcode %} How you can use this: {% code overflow="wrap" %} ``` For buying, you can use either unique or non-unique transactions, depending on your setup. In some cases, spamming with unique transactions may be more effective, but it really depends on your specific situation. With non-unique transactions, you can spam 100 million lamports and pay only 0.007 SOL (if your CU = 70,000) while avoiding failed transactions. For selling, it's generally better to use non-unique transactions (Enabled SAME TX), as this allows you to sell less than 50% of the tokens without any issues. However, if you need to sell tokens instantly and want to sell 100% of them, it's better to spam with unique transactions (Disabled SAME TX). ``` {% endcode %} *** ## SELL SETTINGS *** ### Delay sell This is the time that the bot waits before sending the next transaction, measured in milliseconds. Delay sell input explanation: {% code overflow="wrap" %} ``` In Delay sell, you can input only two values, separated by a comma. The first value is the delay between transactions during your first attempt to sell a token. The second value is the delay between transactions during your next attempts to sell the token again, if your first attempt fails. The second value is intended for use in #sellTX after a failed transaction. If you have more than one retry attempt, all subsequent attempts will use the delay specified by the second value of #sell delay. Example:1,3 1: The delay between transactions for the first attempt (First value in sellTX). 3: The delay between transactions for the second and any subsequent attempts (Second value in sellTX). ``` {% endcode %} Tips for delay sell: {% code overflow="wrap" %} ``` If you use a regular node, the optimal delay between transactions is 1 ms. This means that before sending each transaction, the bot will wait 1 millisecond, allowing you to spam within a single block and increase your chances of a successful transaction. If you use JITO, the recommended delay is 200 ms. However, you can also choose a random location for JITO in the settings and try to reduce your delay further. Test your setup to find the best delay that avoids rate limits. ``` {% endcode %} *** ### **delay price** delay between Sending requests to receive your position price {% hint style="success" %} This field will use node from NodesToken {% endhint %} *** ### Sell tx Amount of transaction that bot will send to sell coin. sell TX input explanation: {% code overflow="wrap" %} ``` In sell TX, you can input only two values, separated by a comma. The first value is the number of transactions the bot will send during your initial attempt to sell a token. The second value is the number of transactions the bot will send in subsequent attempts to sell the token again, if the first attempt fails. If you have more than one retry attempt, all subsequent attempts will use the number of transactions specified by the second value of #sellTX. Example:50,35 50: The number of transactions the bot will send for the first attempt to sell. 35: The number of transactions the bot will send for the second and any further attempts. If you need only one attempt to sell a coin, you should input a single value representing the number of transactions the bot will send to buy the coin. Example:50 50: The number of transactions the bot will send to sell coin. ``` {% endcode %} Tips for sell TX field: 
if you are using a Node, always check its TPS (Transactions Per Second) and avoid overusing it, as this can result in getting rate-limited.

The number of transactions depends on your fees, and you have several options here:

1.Lower fees and a high number of transactions (to spam the block with your transactions) with SAME TX disabled.
2.High fees and a low number of transactions with SAME TX disabled.
3.High fees and a high number of transactions with SAME TX enabled.

Each of these strategies has advantages and disadvantages depending on the module you are using:

Spamming with SAME TX disabled tends to result in better transaction landing compared to SAME TX enabled.
However, with SAME TX enabled, you can significantly increase your fee and the number of transactions you send.
The best approach is to test and choose the option that works best for your specific scenario.
*** ### Fee sell SOL A fee in Solana is a small amount in SOL tokens that users pay for conducting and confirming transactions on the Solana blockchain. Input in this field fee in SOL 
In Fee Buy, you can input only one value.

The fee that you input will be used for the main attempt to sell (for the first value in the Delay Sell and Sell TX fields) and for subsequent attempts to sell the coin again (for the second value in Delay Sell and Sell TX fields) if the first attempt fails.

You can also use this field as the fee for sending a JITO TIP. If you enable JITO SELL and fill in the JITO TIP field, you can also fill in the Fee Sell field, and this value will be used as the fee to send the swap transaction.
Tips for Fee buy field: {% code overflow="wrap" %} ``` if you use the SAME TX for buying or selling, it reduces costs because you avoid failed transactions, with only one successful buy. This allows you to significantly increase your fees. However, keep in mind that spamming with unique transactions is generally more effective than repeating the same transaction multiple times. Therefore, if you choose to use SAME TX, always increase your fees to improve your chances. ``` {% endcode %} *** ### **Delay token** Right after vision started to send transactions to buy token, vision will also start to send requests to detects if it bought the token or not Input value in **milliseconds** {% hint style="success" %} delay by default - 1000 ms This field will use node from NodesToken {% endhint %} *** ### Slippage Absolute **Slippage absolute** is the minimum number of tokens you will receive after a sell. If the amount is less than what you specified, the transaction will fail. *** ### Slippage Percent **Slippage percent** is the maximum sol amount deviation you’ll accept. If it’s exceeded, the trade won’t go through. {% code overflow="wrap" %} ``` Example: 10 You send a transaction expecting to receive 1 sol. While it’s processing, someone makes a whale buy, and now you only receive 0.8 sol. The transaction fails because the sol amount deviation exceeds 10%. ``` {% endcode %} *** ### Slot Difference Enter the maximum number of slots the transaction should go through; otherwise, the transaction will fail. *** ### Tip Sell Sol Jito bundle will be sent with fee in SOL that you input in this filed {% code overflow="wrap" %} ``` Also you can send buy transaction using usual node and jito bundle to use this input fee in sol in fee buy/sell field(s) Usual fee will be in swap transaction ``` {% endcode %} 
Additionally, your fees should depend on which module you are using. If you experience unsuccessful transactions in 99% of cases, it's likely due to low fees, low Buy/Sell TXs, or large delays between transactions.
*** ### Retries Sell This field is used to specify the number of attempts to Sell a coin again if the initial attempt fails. Attempt - amount of transactions from [#sell-tx](#sell-tx "mention") and delay between them from [#delay-sell](#delay-sell "mention") Retries sell input explanation: {% code overflow="wrap" %} ``` In Retries sell, you can input only one value. This value represents the number of attempts to sell the coin again, using the second value from #sellTX and #DelaySell. Example:3 This means that the bot will make 3 attempts to sell the coin again if your main attempt fails (the main attempt refers to the first value from #SellTX and #DelaySell). The retries will occur if the main attempt does not go through within the time specified by the first value in #RetriesDelay (in milliseconds). ``` {% endcode %} {% code overflow="wrap" %} ``` If you don't need Retry attempt you can leave this field empty. ``` {% endcode %} *** ### Retries delay This field is used to specify the delay between attempts to sell coin. Retries Delay input explanation: {% code overflow="wrap" %} ``` In Retries Delay, you can input only two values in milliseconds, separated by a comma. If you have more than 1 retry attempt, you should input 2 values: Example:10000,20000 The first value is the delay between your main attempt and the first retry attempt. The second value is the delay between subsequent retry attempts. ``` {% endcode %} ``` If you have only 1 attempt, you should input input 1 value. Example:10000 It will be delay between your main attempt and retry attempt. ``` ``` If you don't need Retry attempt you can leave this field empty. ``` *** ### **Send Separate** Works only if you have enabled multiple token-buying services (e.g., Jito, Nextblock, Temporal anti-MEV). When enabled, each service sends a unique transaction. You are charged only for the successful transaction. For any failed transactions (only the Jito, Temporal, and Nextblock toggles may fail; anti-MEV cannot), you pay only the **Fee buy in SOL** — the **Tip Buy SOL** is not charged on failed transactions. When disabled, you will send every service that you enabled in one transaction and pay Tip Buy SOL for each service.

Disabled

*** ### 0Slot Enabled - bot will buy tokens using 0Slot service without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### **JITO** Enabled - bot will buy tokens using Jito without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### JITO 95% Tip Enabled - bot will send transaction via JITO with 95% chance of successful landing. It will be dynamic TIP that bot requests from JITO API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable JITO or JITO anti-mev toggle to send tx with mev protection or without and after that enable JITO 95% TIP. JITO API: {% endhint %} *** ### JITO 99% Tip Enabled - bot will send transaction via JITO with 99% chance of successful landing. It will be dynamic TIP that bot requests from JITO API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable JITO or JITO anti-mev toggle to send tx with mev protection or without and after that enable JITO 99% TIP. JITO API: {% endhint %} *** ### Jito Anti-mev Enabled - bot will send jito bundle with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Jito Only bundle If you want to use this toggle **enable JITO toggle.** Enabled - bot will send jito bundle without mev protection. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### NextBlock Enabled - Bot will buy tokens using Nextblock without mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} Mininmum TIP is 0.001 sol {% endhint %} Docs: *** ### Nextblock Anti-mev Enabled - Bot will buy tokens using Nextblock with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} Mininmum TIP is 0.001 sol {% endhint %} Docs: *** ### Temporal Enabled - Bot will buy tokens using Temporal without mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Temporal 95% Tip Enabled - bot will send transaction via Temporal with 95% chance of successful landing. It will be dynamic TIP that bot requests from Temporal API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable Temporal or Temporal anti-mev toggle to send tx with mev protection or without and after that enable Temporal 95% TIP. Temporal API: {% endhint %} *** ### Temporal 99% Tip Enabled - bot will send transaction via Temporal with 99% chance of successful landing. It will be dynamic TIP that bot requests from Temporal API. Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. {% hint style="danger" %} You have to firstly enable Temporal or Temporal anti-mev toggle to send tx with mev protection or without and after that enable Temporal 99% TIP. Temporal API: {% endhint %} *** ### Temporal Anti-mev Enabled - Bot will buy tokens using Temporal with mev protection Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Normal TX Use this toggle if you enabled multiple sending transaction services( jito, nextblock, temporal ) Enabled - bot will send usual transaction via node that you selected in NodeTX with other services that you enabled, Disabled - Disabled - bot will send tx via your node that you selected in NodesTX or via other services that you selected. *** ### Same TX This toggle is used to switch between sending unique and non-unique transactions. Explanation: {% code overflow="wrap" %} ``` Disabled Toggle: This means that you will send unique transactions. In this case, 1 transaction will be successful, and the other transactions will fail. You will need to pay a fee for each transaction that is landed on the chain. Enabled Toggle: This means that you will send 1 transaction X times, as specified in #BuyTX. With this option, you will have only 1 transaction on the chain and no failures. ``` {% endcode %} How you can use this: {% code overflow="wrap" %} ``` For buying, you can use either unique or non-unique transactions, depending on your setup. In some cases, spamming with unique transactions may be more effective, but it really depends on your specific situation. With non-unique transactions, you can spam 100 million lamports and pay only 0.007 SOL (if your CU = 70,000) while avoiding failed transactions. For selling, it's generally better to use non-unique transactions (Enabled SAME TX), as this allows you to sell less than 50% of the tokens without any issues. However, if you need to sell tokens instantly and want to sell 100% of them, it's better to spam with unique transactions (Disabled SAME TX). ``` {% endcode %} *** ## SELL STRATEGY *** ### Take profit at Input the value of token growth in % that will be used as the Take Profit. The bot will sell **X** amount of the tokens when this percentage is reached. {% code overflow="wrap" %} ``` You can specify multiple TP levels, separated by commas. For each TP level, you must provide an equal number of "sell % of tokens after TP" values. For example, if you have 3 TP levels, you need 3 corresponding "sell % of tokens after TP" values. You must also specify an equal number of Stop Losses (SL). Otherwise, the task will not start. (If you do not need SL, just input 1000 for every level.) Example:40,60,100 40: When the token reaches 40% growth, the bot will sell X% of your tokens (as specified in the "sell % of tokens after TP" field). 60: When the token reaches 60% growth, the bot will sell another X% of your tokens. 100: When the token reaches 100% growth, the bot will sell the remaining X% of your tokens. ``` {% endcode %} *** ### Stop loss Input value of token decrease in % that will be used as Stop loss and bot will sell X amount of token when this % reached 
You must have equal amount of SL and TP levels ( otherwise task you won't be able to run task )

If you need only 1 SL, you can input it in every level and input in Sell "% of tokens after TP" 100 in each level

If you don't need SL, but you have TP you can simply input 1000 for each level
*** ### Sell % of tokens after TP Enter the token growth value in % that will be used as the take profit, and the bot will sell X amount of the token when this percentage is reached. {% code overflow="wrap" %} ``` You can use multiple take profit (TP) levels separated by commas. For each TP level, you must specify an equal number of 'sell % of tokens after TP' values. For example, 3 TP levels require 3 corresponding 'sell % of tokens after TP' values. You must also provide an equal number of stop losses (SL). Otherwise, the task will not start. (If you don't need an SL, simply input 1000 for every level.) Example:50,80,100 Sell 50% of the tokens when the first TP is reached. Sell 80% of the remaining tokens when the second TP is reached. Sell 100% when the third TP is reached. ``` {% endcode %} *** ### Sell % of tokens after SL bot will sell x % of token after reaching value that you input in Stop Loss 
You should input % to sell for every Stop loss 

Example:50,80,100 
50 % tokens when 1 SL reached 
80 % rest of the tokens when 2 SL reached 
100 % when 3 SL reached

If you need only 1 SL and more than 1 TP, you can input this SL few times that will be equal to the TP levels and for each SL input 100 to sell 100% on each level
Example for 1 SL and more than 1 TP levels\ ![Example for 1 SL and more than 1 TP](https://788737236-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FV5oxHMkkXARv6Kg798Uu%2Fuploads%2FUkp574iGvam7C7ZVDNda%2Fimage.png?alt=media\&token=a9757ead-b64b-4de0-aa31-b4b87512efda) *** ### **Sell After Ms** Bot will send sell transactions after X MS after token bought {% code overflow="wrap" %} ``` input 1000 and bot will sell tokens in 1000 ms after token bought ``` {% endcode %} *** ### Trailing SL A trailing stop is a modification of a typical Stop Loss that can be set at a defined percentage. The Bot will remember every ATH of your position and if price drops for x% that you input from ATH bot will sell. *** ### Sell % after trail % of position to sell after Trailing SL level reached *** ### Price movement This field is used to sell the token if the price does not move by **X%** within **X** milliseconds. Input explanation: {% code overflow="wrap" %} ``` You need to input 3 values in this field: %move,ms,%sell %move: The value representing the percentage of price movement of the token. If the token does not move higher than this percentage, the bot will sell the token. (Input the value without the % sign.) ms: The value in milliseconds that the bot will wait before deciding whether to sell or not, depending on the price movement during this time period. %sell: The percentage of tokens you wish to sell if the price does not move higher than %move. Example:20,10000,100 If the price does not move higher than 20% (either positive or negative) within 10000 ms (10 seconds), the bot will sell 100% of your position. ``` {% endcode %} *** IMPORTANT TO KNOW: 1. You need to have Wrapped SOL on your wallet + SOL for commission\ Wrap here [^1]: