Common workflow
Upgrade to latest version
The latest versino of the bot usually contains bug fixes and new features. So it's important to keep your bot up to date.
First ssh into your Linux machine, cd into the folder of the bot, then download the zip file for the latest release.
The latest release can be found here: Releases
Cd into the bot folder
cd bot
Give permission to the upgrade script
chmod +x upgrade.sh
Run the upgrade script
./upgrade.sh
Restart your bot!
Downgrade to a certain version
This only works after version 0.3.7
Similiar to upgrade, you just call the script with the version you want to go to.
First ssh into your Linux machine, cd into the folder of the bot, then download the zip file for the latest release.
The latest release can be found here: Releases
Cd into the bot folder
cd bot
Give permission to the upgrade script
chmod +x upgrade.sh
Run the upgrade script with the version you want to download. for example 0.3.8
./upgrade.sh 0.3.8
Restart your bot!
Run bot in background
When you ssh into a remote machine and run the bot, once you close the terminal, the bot will stop running. This section shows you how to run it even when your terminal is closed.
Create a screen session, called bot
screen -S bot
Now you are in a screen session. To verify, run
screen -ls
You should see something like the following:
There are screens on:
1059895.bot (05/23/24 03:11:34) (Attached)
Attached means you are now in this screen session.
Now you can run the bot as shown above, which will run the bot inside the bot session, and it won't stop running even if you close the terminal!
./run.sh
Once you close your terminal and reconnect, run the following to open the previous created session.
screen -r bot
To fully close it, run
screen -X -S bot quit
Make sure you don't have 2 sessions both running the bot together, or the bot will fail to run.
To exit a screen session while you are attached, press ctrl+a, then d
Run multiple bots with one Jupiter API
There are a few reasons that you may want to do this. As running Jupiter API is pretty expensive, you may want to only run one and connect multiple machines to the same Jupiter API.
Jupiter API runs on port 18080, you can connect to it from other machine by setting the JUPITER_URL=http://ip_of_your_machine:18080
on your machines that does not run Jupiter.
If you want to us a machine to just host the Jupiter API, and not run any bot on the machine, you can run ./run-jup.sh
on the machine, which will just run Jupiter API for you. You can then use the Jupiter endpoint from other machines.
If you want to run multiple bots on the same machine with just one Jupiter API, you can run one bot as normal, and set DISABLE_LOCAL_JUPITER=true
for all the other bots. This way only one Jupiter API will be run on your machine.
Migrate from 0.2.x to 0.3.x
Give permission to the upgrade script
chmod +x upgrade.sh
Run the upgrade script
./upgrade.sh
Give permission to everything
chmod +x *
Run the migrate script
./migrate
Then a config.yaml
file should be automatically generated for you. Double check the config inside to make sure everything is good, then you have finished the migration!
You can optionally remove .env
and base-mint.json
file after fully migrated.
Upgrade/Downgrade Jupiter API version
You can run the upgrade-jup.sh script with a specific version you want to download and use
You can find all the Jupiter API versions here: https://github.com/jup-ag/jupiter-swap-api/releases
Example:
./upgrade-jup.sh 6.0.34
Use multiple IPs on your machine
This is just an example and there maybe better ways to do this.
First you should ask your server provider to give you additional ips to your server. Once you have that, you can do the following to utilize all of them when sending through jito.
Identify the Network Interface Name
The network interface name (eno1
, eth0
, etc.) can be identified using the following command:
ip link show
This will list all network interfaces. Look for the active interface connected to your network (e.g., state UP
). Example:
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
Add an Additional IP Address Temporarily
Replace eno1 with whatever your interface name is
sudo ip addr add x.x.x.x/32 dev eno1
Verify ip address is added correctly:
ip addr show dev eno1
Install ipset
sudo apt install ipset
This will require you to re-run this on restart. Or you can search for how to add it permanently with Netplan.
Then set ipset for all jito regions
#!/bin/bash
# Define URLs and their corresponding ipsets
declare -A URL_IPSETS=(
["amsterdam.mainnet.block-engine.jito.wtf"]="amsterdam"
["frankfurt.mainnet.block-engine.jito.wtf"]="frankfurt"
["ny.mainnet.block-engine.jito.wtf"]="ny"
["tokyo.mainnet.block-engine.jito.wtf"]="tokyo"
["slc.mainnet.block-engine.jito.wtf"]="slc"
)
# Loop through each URL
for URL in "${!URL_IPSETS[@]}"; do
IPSET_NAME="${URL_IPSETS[$URL]}"
# Ensure the ipset exists
if ! sudo ipset list "$IPSET_NAME" &>/dev/null; then
echo "Creating ipset: $IPSET_NAME"
sudo ipset create "$IPSET_NAME" hash:ip
fi
# Ping the URL to ensure it's reachable
echo "Pinging $URL..."
PING_RESULT=$(ping -c 1 "$URL" | grep "PING")
if [[ -z $PING_RESULT ]]; then
echo "Failed to reach $URL. Skipping."
continue
fi
# Extract the IP address from the ping result
RESOLVED_IP=$(echo "$PING_RESULT" | awk '{print $3}' | tr -d '()')
if [[ -n $RESOLVED_IP ]]; then
echo "Resolved $URL to IP: $RESOLVED_IP"
# Add the IP to the ipset, flushing the set first to ensure it's clean
echo "Flushing and updating ipset: $IPSET_NAME"
sudo ipset flush "$IPSET_NAME"
sudo ipset add "$IPSET_NAME" "$RESOLVED_IP"
else
echo "No IP resolved for $URL. Skipping."
fi
done
echo "IP sets updated successfully."
Finally set iptable rules to route through each ip one by one.
You should use your own ips here to replace ("1.1.1.1" "2.2.2.2" "3.3.3.3")
#!/bin/bash
# Set your own ips here, put all your server's ip in this section
# Define the source IPs to use for SNAT
SOURCE_IPS=("1.1.1.1" "2.2.2.2" "3.3.3.3")
# Define destination IP sets and their corresponding marks
declare -A DEST_MARKS=(
["amsterdam"]=1
["frankfurt"]=2
["ny"]=3
["tokyo"]=4
["slc"]=5
)
# Log start of the script
echo "Starting iptables configuration script..."
echo "Destination marks: ${!DEST_MARKS[@]}"
echo "Source IPs: ${SOURCE_IPS[*]}"
# Step 1: Mark outgoing traffic based on destination
echo "Setting up mangle table rules for marking traffic..."
for DEST in "${!DEST_MARKS[@]}"; do
MARK="${DEST_MARKS[$DEST]}"
echo "Marking traffic for destination set: $DEST with mark: $MARK"
sudo iptables -t mangle -A OUTPUT -p tcp --dport 443 -m set --match-set "$DEST" dst -j MARK --set-mark "$MARK"
done
# Log mangle table rules
echo "Current mangle table OUTPUT rules:"
sudo iptables -t mangle -L OUTPUT -v -n
# Step 2: Apply SNAT rules based on marks
echo "Setting up nat table SNAT rules..."
for MARK in "${DEST_MARKS[@]}"; do
TOTAL_IPS=${#SOURCE_IPS[@]}
echo "Applying SNAT for mark: $MARK with $TOTAL_IPS source IPs..."
for ((i = 0; i < TOTAL_IPS; i++)); do
PACKET_INDEX=$((i % TOTAL_IPS))
echo " SNAT: Mark $MARK, Source IP ${SOURCE_IPS[$i]}, Packet Index $PACKET_INDEX"
sudo iptables -t nat -A POSTROUTING -m mark --mark "$MARK" -m statistic --mode nth --every "$TOTAL_IPS" --packet "$PACKET_INDEX" -j SNAT --to-source "${SOURCE_IPS[$i]}"
done
done
# Log nat table rules
echo "Current nat table POSTROUTING rules:"
sudo iptables -t nat -L POSTROUTING -v -n
# Log script completion
echo "iptables configuration completed successfully."
Then you are all set!
To verify, you can turn on jito log, and you should see much less jito rate limit response. Do note you need to also enable USE_SEPARATE_TIP_ACCOUNT
for it to work properly.
Last updated