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:

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:

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.

Save log to file

./run.sh | tee bot.log

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

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!

Switch between different config files

You can pass in the config file when you execute run.sh

For example, if you create a config named config.jito.yaml. You can use that by doing this:

./run.sh config.jito.yaml

PreviousConfig examples NextPerformance tuning

Last updated 2 months ago

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:

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:

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.

Save log to file

./run.sh | tee bot.log

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:

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 for it to work properly.

Switch between different config files

You can pass in the config file when you execute run.sh

For example, if you create a config named config.jito.yaml. You can use that by doing this:

./run.sh config.jito.yaml