Skip to content

Releases: AlexRubik/rude-bot-solana

v3.1.0-alpha - Main Dexes

19 Jan 13:37
3d968f9
Compare
Choose a tag to compare
  • Download this version onto your Ubuntu server with this command:
    wget https://github.com/AlexRubik/rude-bot-solana/releases/download/v3.1.0-alpha/rude-bot-alpha3_1_0.zip

New param in jupManagerConfig.json. If set to true, it will only include the most popular dexes. If false, it will include ALL dexes.
Starting jup with all dexes can take up to 10 minutes, so setting this to true should reduce that time a bit.

"mainDexesOnly": true

To get started on a new server, run these commands individually:
sudo apt update && apt upgrade -y && apt install -y screen unzip
wget https://github.com/AlexRubik/rude-bot-solana/releases/download/v3.1.0-alpha/rude-bot-alpha3_1_0.zip
unzip rude-bot-alpha3_1_0.zip
cd rude-bot-alpha3_1_0
./rude --help

CLI Command Args

For args, use this format: ./rude --help

  • --help: Show help message
  • --overview: Show quick start guide
  • --createkp: Create new Solana keypair
  • --cnxs: Configure RPC/GRPC connections
  • --jup: Start Jupiter API instance
  • To start the bot, just use ./rude

v3.0.0-alpha - Simplification Iteration

04 Jan 21:22
547b063
Compare
Choose a tag to compare

RUDE Bot v3.0.0 Release Notes

New Features

CLI Command Args

For args, use this format: ./rude --help

  • --help: Show help message
  • --overview: Show quick start guide
  • --createkp: Create new Solana keypair
  • --cnxs: Configure RPC/GRPC connections
  • --jup: Start Jupiter API instance
  • To start the bot, just use ./rude

Configurable Profit BPS Thresholds

  • Added two new environment variables to control minimum profit thresholds:
    • MIN_PROFIT_BPS_MIN: Minimum profit BPS for large trades (default: 3)
    • MIN_PROFIT_BPS_MAX: Maximum profit BPS for small trades (default: 25)

Risk Presets and Worker Distribution

The RISK setting in your .env file now has three options that affect how workers are distributed:

Worker Distribution Logic:

  • WSOL gets 70% of workers by default
  • USDC gets 20% of workers if available
  • USDT gets 10% of workers if available
  • If a stable is missing, its allocation goes to WSOL

Risk Level Effects:

  1. LOW Risk

    • All workers use Jito (jitoProfitPerc: 80)
    • Most conservative
    • Best for stable network conditions
  2. MEDIUM Risk

    • Half workers use Jito, half use Native
    • Balanced approach
    • Good for mixed market conditions
  3. HIGH Risk

    • All workers use Native routes (jitoProfitPerc: 0)
    • Most aggressive
    • Best for high-volatility periods

Configurable Scale Thresholds

Added new environment variables to control profit scaling thresholds:

  • SOL Scale Thresholds:

    • MIN_SOL_SCALE: Minimum SOL amount for scaling (default: 0.05)
    • MAX_SOL_SCALE: Maximum SOL amount for scaling (default: 1)
  • USD Scale Thresholds:

    • MIN_USD_SCALE: Minimum USD amount for scaling (default: 5)
    • MAX_USD_SCALE: Maximum USD amount for scaling (default: 120)

Profit BPS will scale between MIN and MAX based on these thresholds:

  • For WSOL:
    • ≥MAX_SOL_SCALE: Uses MIN_PROFIT_BPS_MIN
    • MIN_SOL_SCALE to MAX_SOL_SCALE: Scales from MAX to MIN
  • For USDC/USDT:
    • ≥MAX_USD_SCALE: Uses MIN_PROFIT_BPS_MIN
    • MIN_USD_SCALE to MAX_USD_SCALE: Scales from MAX to MIN

How It Works:

For a Default Setup with WSOL:

  • Trade size ≥ 1 SOL: Requires 3 BPS profit
  • Trade size 0.05 SOL: Requires 25 BPS profit
  • Trade sizes between scale linearly
    • 0.5 SOL ≈ 14 BPS
    • 0.25 SOL ≈ 19 BPS

For USDC/USDT:

  • Trade size ≥ $120: Requires 3 BPS profit
  • Trade size $5: Requires 25 BPS profit
  • Trade sizes between scale linearly
    • $60 ≈ 14 BPS
    • $30 ≈ 19 BPS

Adjust these values based on:

  • Your capital size
  • Market volatility
  • Risk tolerance
  • Network conditions

Improvements

  • Enhanced error handling for RPC connections
  • Improved token balance fetching reliability
  • Better logging for configuration updates
  • Optimized bundle sending for lower latency

v2.0.0-alpha - Fee Reduction, Jup Manager, JITO UUID

08 Oct 15:16
be97692
Compare
Choose a tag to compare

Getting started just got much easier.

Rent a minimum of 12 core server and then copy and paste these commands one by one after connecting to your server with SSH:

sudo apt update && sudo apt install unzip screen -y

wget https://github.com/AlexRubik/rude-bot-solana/releases/download/v2.0.0-alpha/rude-bot-alpha2_0_0.zip

unzip rude-bot-alpha2_0_0.zip

cd rude-bot-alpha2_0_0

chmod +x ./rude-bot-alpha2_0_0

Put your keypair.json in the bot directory.

Use screen to run a jup and bot instance:

screen -S jup

./rude-bot-alpha2_0_0 --jup Then leave the screen session with CTRL + D and then tap the letter A.

screen -S bot

./rude-bot-alpha2_0_0 Then leave the screen session with CTRL + D and then tap the letter A.

To go back into the sessions use:

screen -r bot or screen -r jup

Everything should now be running. If you got errors when starting jup or the bot then restart them (kill the process with CTRL + C).
When you are using FREE connections, it pulls from a list at random at startup and all of the connections on the list are not perfect so restarting will give you new connections. If the errors persist then you need to rent RPC + GRPC connections and put them in the jupManagerConfig.json and the RPC_URL variable in the .env file.


  • Fee is now fixed at 5%

  • Free RPC and GRPC connections now offered

  • FREE options on by default for all the places the bot takes an RPC or GRPC. Simply replace the word FREE with the appropriate URL you want to use if you want to use your own connections.

  • Jup API starts with this command: ./rude-bot-alpha2_0_0 --jup

  • New .env variable: JITO_UUID If you have a custom rate limit increase from Jito, you can provide your UUID.

  • update_mints.py
    -- Pretty good strategy for updating mints. Don't touch this file unless you know what you're doing.

  • jupManagerConfig.json
    -- Minute interval for updating mints and restarting jup api
    -- Can specify a Python file to update your mints (on start and restart)
    -- Can specify multiple RPC and gRPC connections to rotate through every restart

{
    "autoRestartMinutes": 10,
    "updateMintsCmd": ["python3", "./update_mints.py"],
    "rpcUrls": ["http://67.XXX.54.XXX", "http://69.420.54.XXX"],
    "grpcs": [
        {
            "url": "http://67.XXX.52.XXX:10000",
            "token": "none"
        },
        {
            "url": "http://69.XXX.52.420:10000",
            "token": "none"
        }
    ]
}

v1.2.0-alpha - maxTxnAge, useHeliusFee, REUP_NATIVE_ENABLED, SLOT_DATA_ENABLED, WRITE_TO_CSV

25 Jun 21:32
Compare
Choose a tag to compare

New baseConfig.json properties: maxTxnAge, useHeliusFee, inDexes, outDexes

  • inDexes, outDexes, useInDexes, useOutDexes: the variables that start with "use" can take true or false as their values depending on if you want to use them. For in/outDexes, you can provide a list of the dexes you want to restrict your in and out swaps to (read here to see what those swaps look like).
    You can find all the valid dex names here.

Example values:
"useInDexes": true,
"inDexes": ["Orca V1", "Orca V2", "Phoenix", "Meteora", "Lifinity V2", "Raydium CLMM", "Meteora DLMM", "Raydium"]

Don't use these maxTxn params for now. There might be value to them in the future.

  • maxTxnAge: approximate max age for your transaction measured in blocks. For example, if you only want transactions to land within 5 blocks then make this value = 5. In this example, if the bot finds an arb opportunity at block number ~100 and you have a processing time <400ms then the transaction will only land up to block ~105. A validator will not attempt to land your transaction later. Doesn't make since to use this for Jito txns so only test this with native txns. In theory, this should greatly reduce your amount of failed transactions once you find an optimal number.
  • useMaxTxnAge: boolean (true/false) for maxTxnAge mentioned above^
  • useHeliusFee: set this to true if you want to use Helius's suggested fees for all your normal transactions. You still need to have a Helius API key set in the .env file for this to work.

New .env variables: RANDOM_JITO..., REUP_NATIVE_ENABLED, SLOT_DATA_ENABLED, WRITE_TO_CSV

  • REUP_NATIVE_ENABLED: you can now disable/enable this feature
  • SLOT_DATA_ENABLED: set this to true to see what slots you attempt to send your txns
  • WRITE_TO_CSV: set this to true to write significant arb data to a csv inside the csvs folder. The naming format for the csvs is txns_{unix time of when bot was started}.csv
  • RANDOM_JITO_URLS: set this to true if you want to randomly use a jito url from BLOCK_ENGINE_URL.
  • RANDOM_JITO_URLS_COUNT: the number of jito urls you want to send each arb transaction to. For example, if this value is 2 then it will send every arb opportunity to 2 random jito urls. To reduce rate limits, you should have this number set to 1.

v1.1.0-alpha - Multi Wallet, CU Override, Proxies, Reup Native, Process Time Cutoff

15 Jun 03:46
Compare
Choose a tag to compare

New .env variables:

  • USE_BASE_CONFIG_KEYPAIR
    When true, bot uses payerKeypairPath value in baseConfig.json for each worker instead of PAYER_KEYPAIR_PATH in .env for all workers.

  • USE_JITO_PROXIES
    Set this to true and put your proxy urls in the proxies.json file to use proxies for Jito sending bundles.

  • RANDOM_2_JITO_URLS
    In an attempt to reduce rate limiting, you can set this to true and each bundle will be sent to 2 random block engines that you have listed in BLOCK_ENGINE_URL .env if you have > 2 listed.

  • CUTOFF_MS
    The bot now tracks the execution time of each arb opportunity from right before the Jup API calls to right before the sending of the transaction. If this processing time > CUTOFF_MS then the transaction will not be sent.

  • REUP_NATIVE_MINUTES_INTERVAL
    How often you transfer wSOL to native SOL.

  • MAINTAIN_WSOL_BALANCE
    The wSOL balance you would like to maintain. This should be the number of your largest SOL trade size.

New baseConfig properties:

  • payerKeypairPath
    Refer to USE_BASE_CONFIG_KEYPAIR above.

  • useCuOverride
    When true, the bot will use the cuOverrideValue for the transactions Compute Unit Limit. Learn about Compute Units here.

  • cuOverrideValue
    Compute Unit Limit value

v1.0.1-alpha - Proxies

12 Jun 15:30
Compare
Choose a tag to compare
Pre-release
  • New .env: USE_JITO_PROXIES=true
  • New file: proxies.json
  • Put your proxy urls in the proxies.json file

v1.0.0-alpha - Staked Helius Transactions!

31 May 20:01
26bc19e
Compare
Choose a tag to compare

Any paid Helius plan can now use their staked connection to send heavily prioritized transactions.

Newly required files in this zip (don't try to put the new executable in your older version directories).

Using a staked connection does not improve execution speed!
It only makes your transaction more likely to be included in a block (fail or success)!
Helius requires expensive priority fees (10k lamports minimum) for this feature which the bot calculates automatically (read below).
If you don't have an optimal setup, you can lose a lot due to these high priority fees.
If you are not targeting large profit or large trade sizes, you can lose a lot due to these high priority fees.

  • Put your Helius API key value in the new .env variable: HELIUS_API_KEY=X

  • In baseConfig.json you now have 2 new properties:
    "useHeliusTxn": true,
    "heliusPriorityLevel": "MEDIUM"

  • When useHeliusTxn = true, if the bot uses a helius rpc in any way for sending txns, it will send it with priority to their staked connection.

  • heliusPriorityLevel can be "LOW" , "MEDIUM", or "HIGH" . This determines the size of helius txn priority fee. They suggest MEDIUM.

  • A Helius transaction will always use more than 10k lamports priority fee

  • If you are using the spam .env variables, they will work as normal. They won't use the large priority fee even if you have useHeliusTxn = true

  • useHeliusTxn = true does not make the worker send only Helius transactions when using spam feature. If you are spamming, the worker will send normal transactions to your non Helius rpcs with the min/maxFeeLamports as the priority fee

  • Try using MAX_RETRIES=0 (in .env) and duplicating RPCs in your rpcs.json

  • A worker with jitoProfitPerc > 0 will still only send jito bundles. The new Helius properties/variables don't affect that. Bundles are prioritized in this condition.

Get started! https://rude-bot-org.gitbook.io/rude-solana-arbitrage-bot/bot-setup-instructions

Official Website: https://www.solanaarbitrage.com/

v0.2.10-alpha - UNSTABLE Auto Jito Tip Pre-Release

15 May 05:18
3e3697b
Compare
Choose a tag to compare

New (SOL/USDC/USDT ONLY) baseConfig property: "jitoProfitPerc": 50

Percent of profit to send as a jito bundle tip. E.g., if the value is set to 50 then every profitable transaction will send 50% of the profit as a jito tip in SOL. Jito tips are only in native SOL so make sure you have enough SOL to use this.

  • This only works with SOL/USDC/USDT workers. Keep this value = 0 otherwise.

  • When this value = 0 , normal transactions will be used. Not a jito bundle.

  • When this is > 0 the worker will only send your transactions in a jito bundle.

  • Use the new ledger_program.json

  • Removed bundleTipLamports from baseConfig.json

  • Added informative memo to bundle transactions and transactions sent when
    SPAM_RPCS_ENABLED=true
    SPAM_RPCS_UNIQUE_TXNS=true

Official Links: https://solanaarbitrage.com

v0.2.9-alpha - Unique Txns and Multiple Jito Block Engines

03 May 03:07
467a671
Compare
Choose a tag to compare

New boolean .env variable: SPAM_RPCS_UNIQUE_TXNS

When SPAM_RPCS_ENABLED=true and SPAM_RPCS_UNIQUE_TXNS=true, the bot will send the same transaction but with different transaction signatures to each RPC in rpcs.json

.env variable BLOCK_ENGINE_URL: you can now send your bundle to multiple block engine urls separated by commas

For example,
BLOCK_ENGINE_URL=ny.mainnet.block-engine.jito.wtf,frankfurt.mainnet.block-engine.jito.wtf

https://www.solanaarbitrage.com/
https://twitter.com/solanarbitrage

v0.2.8-alpha - New Config, Auto Updates, Fee Reduction

27 Apr 17:39
ce33cdb
Compare
Choose a tag to compare

New .env variable: UPDATE_INTERVAL_MINUTES

  • Interval for updating your createAtaBlacklist and pulling your rpcs.json and includeMints json files
  • So now you don't have to restart the bot to update the blacklist and you don't have to restart the bot if you change your rpcs.json file
  • You can change your rpcs.json and includeMints files while the bot is running and the changes will take place at the interval

New baseConfig object props: workerUniqueId and includeMintsJsonPath

  • workerUniqueId: name your workers
  • includeMintsJsonPath: you can now have a unique includeMints json for each worker

Fee Reduction: Fee is now 10% - 25%

https://www.solanaarbitrage.com/