Paladin - P3 Runbook

Paladin is a Solana validator client that protects validators from sandwiching while helping them earn more in block rewards. Here's how to get started:

1. Get your validator whitelisted

While Paladin is in beta, access to receive p3 transactions requires getting whitelisted. This ensures you'll be able to receive P3 transactions and earn additional block rewards.

Please fill out the validator whitelisting request form:

Paladin Validator Whitelisting Request Form

After submitting the form, our team will review your request and follow up with next steps. You can proceed with the steps below in parallel.

2. Download and build paladin-solana

To run Paladin, you need to build the paladin-solana client from source. It's based on jito-solana.

You run it with your usual validator setup like you'd run jito-solana — no additional flags are necessary.

The latest version of paladin-solana is v2.1.16-paladin, which is rebased to jito-v2.1.16.

Building from source

Important: Always build from the latest release source code, not from the master branch. The master branch should not be considered production-ready.

Download the release source code:

# Clone the repository with submodules

$ git clone --recursive https://github.com/paladin-bladesmith/paladin-solana.git
$ cd paladin-solana
$ git checkout v2.1.16-paladin # Check out the latest release tag
$ git submodule update --init --recursive  # Ensure all submodules are initialized

# Build the release version

$ ./cargo build --release

The build process requires a standard Rust toolchain and Solana build dependencies. Make sure you have these installed before building.

Note: Like jito-solana, the binary that's built is called agave-validator.

When you check the client name you're running through solana --version, you'll see "Jito-solana". This is expected behavior.

3. Spin up your node with paladin-solana

Most validators have their own way of running Solana validator clients. If you run jito-solana, you can swap paladin-solana into your standard DevOps process.

Note: paladin-solana does not require any special flags when starting up relative to jito-solana. You should be able to apply the same flags you do in your typical setup.

5. Open and whitelist required ports

While Paladin is in beta, access to transaction sending ports is IP-whitelisted. In production, these ports will be token-gated through locking $PAL.

Important: Port 4818 has been deprecated in favor of ports 4819 and 4820. Please ensure port 4818 is closed.

For P3 to work properly on your machine, you'll need to open and whitelist the following UDP ports for trusted IPs that are sending high priority transactions:

4819: QUIC port for P3 transactions (include on revert)
4820: QUIC port for "MEV" P3 transactions (fail on revert)

Please reach out to @edgarpavlovsky on telegram for the current list of IPs to whitelist.

Example commands:

To whitelist on Ubuntu/Debian machines, ufw is a popular choice:

# Enable UFW if not already enabled
$ sudo ufw enable

# Allow specific IP address to access required ports
$ sudo ufw allow proto UDP from WHITELISTED_ADDRESS to any port 4819
$ sudo ufw allow proto UDP from WHITELISTED_ADDRESS to any port 4820
# Verify the rules
$ sudo ufw status

NOTE: This port will not be listening until your validator catches up with the chain. Once caught up, you should see this port listening for its respective protocols.

6. How can I check if I'm receiving P3 transactions?

P3 implements the same datapoint_info! tracking macro that's used throughout the rest of the agave client. When receiving P3 transactions, metrics will be logged like:

datapoint_info!(
    "p3_quic",
    ("age_ms", age_ms as i64, i64),
    ("regular_packets_forwarded", self.reg_forwarded as i64, i64),
    ("regular_packets_dropped", self.reg_dropped as i64, i64),
    ("mev_packets_forwarded", self.mev_forwarded as i64, i64),
    ("mev_packets_dropped", self.mev_dropped as i64, i64),
    ("staked_nodes_us", self.staked_nodes_us as i64, i64),
);

You can monitor these metrics in your logs to confirm that your node is successfully receiving and processing P3 transactions. Note that "regular_packets" refers to non-revert packets sent to port 4819, while "mev_packets" refers to revert-on-fail packets sent to port 4820.