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

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

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

• 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!

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

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

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

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/

v0.2.7-alpha - 1st iteration Jito Bundles: Fixed Tip, Commitment

WARNING: Profit checking smart contract has not been modified to account for the Jito Bundle Tip. This version allows you to set a custom jito bundle tip.

• this version is strictly for testing / proof of concept

• new .env variable: BLOCK_ENGINE_URL
  All possible values: amsterdam.mainnet.block-engine.jito.wtf | frankfurt.mainnet.block-engine.jito.wtf | ny.mainnet.block-engine.jito.wtf | tokyo.mainnet.block-engine.jito.wtf

• new baseConfig.json object property: bundleTipLamports
  Setting this to 0 will disable bundles and the transaction will be sent normally, witthout jito.

You will have to add these to your .env file if you want to use them, I'm not going to include them in the default file because I don't want to confuse people:

• new .env variable: NORMAL_COMMITMENT
  default is processed

• new .env variable: BUNDLE_COMMITMENT
  default is confirmed

READ ABOUT COMMITMENT HERE: https://solana.com/docs/rpc#configuring-state-commitment

v0.2.6-alpha - Minor performance improvement

• Changed some logic to slightly improve performance for users on the budget setup: Setup Video
• Removed the rawTx log. You can turn it back on by putting this in the .env: DEBUG=true
• Cleaned up the auto populate createAtaBlacklist.json
• For those that want to play with the slippage values, you can add these to your .env:
  MIN_SLIPPAGE_BPS=2000
  MAX_SLIPPAGE_BPS=9000

The values are basis points (integers). If you don't have these variables in your .env then the values above are assigned by default.

New Budget Friendly Setup Video
Documentation

v0.2.5-alpha - Auto populate createAtaBlacklist.json

Minimal convenience update

• New .env variable: AUTO_CREATE_ATA_BLACKLIST
• When true, the bot will get all your token mints on startup and put them in createAtaBlacklist.json
• The output is a bit buggy but if you see "Successfully wrote mint addresses to createAtaBlacklist.json" then it probably worked. You can also check the file to see if it worked.
• If you have a wSOL account, please remember to set WRAP_UNWRAP_SOL_ENABLED=false