Jito Blacklisting Policy

JIP - Ideas
1

This is a draft of the Jito wide Blacklisting Policy. From the point of posting the policy should be considered in active implementation, however a two week draft process is open to allow modification based on community feedback. DAO members and wider Jito Network participants are invited to read the policy and provide feedback. Feel free to discuss and deliberate in this thread.

Jito Blacklisting Policy

Introduction

The Jito Network takes a zero tolerance approach to actions that harm user transactions. To reflect this, the DAO authorized occasional blacklists of actors from accessing its products, including the Jito Stake Pool and BAM.

This policy acts as a unified document that draws together a range of interventions, so that validators can understand what is expected practice from validators who wish to utilise Jito products and what actions will result in a blacklisting.

Harmful MEV

  • JIP’s (JIP-4, JIP-15 and JIP-22) concern the blacklisting processes related to harmful MEV. JIP-4 and JIP-15 were one time blacklisting actions and JIP-22 formalised a structure the BOC (Blacklisting Operations Committee) that retains an on-going mandate for blacklisting validators.

  • The policy is as follows:

    • The BOC monitors best available sources to measure harmful MEV events and frequency as they link to validator ID’s.

    • The BOC uses a statistical approach to monitor validator MEV activity and will periodically blacklist validators who over 10 epoch’s demonstrate a sandwich rate exceeding 25% or over 2X the cluster median sandwich rate.

    • In the event that a validator is identified in this state, then a transaction will be executed that adds validator identities to a blacklist, which will prohibit them from accessing the Stake Pool.

    • A list of all currently blacklisted validators is available at the sheet HERE

    • If a validator feels that they have been wrongly blacklisted, they have the right to appeal via the Jito Forum in the following thread.

Slot Lagging

  • Slot lagging is the action of intentionally delaying a block to gain an economic advantage. This material reduces the quality of the network and is anti ‘IBRL’

  • JIP-23 introduced the IBRLOC (IBRL Operations Committee), which is a long-standing structure which monitors for overt, consistent slot lagging behaviour.

BAM

  • BAM creates a high fidelity block building and execution environment for the Solana network. It mitigates user harm by reducing harmful MEV and optimises the network with efficient block packing.

  • Validators are responsible acting in the following manner:

    • The validator executes all transactions from BAM Nodes, in the exact order received.

    • Only execute transactions received from BAM Nodes

    • Provide correct execution feedback and state information.

  • The BAM Verifier will over time transition to mechanistic hard enforcement, automatically detecting BAM violations and disconnecting validators from BAM nodes and its transactions flows.

  • However, given that BAM and the BAM Verifier are early stage technologies and false positive measurements are undesirable a phased approach of the BAM Verifier blacklisting process will be rolled out in a phased manner.

  • The following process will be rolled out, which progressively moves the system towards a fully automated mechanism.

Phase 1:

  • A periodic manual review of BAM verifier data will take place, which includes the measurement and frequency of unrecognized TX’s that were not sent from BAM nodes and ordering violations, where a validator executes transactions out of presented order, skips items or injects transactions not in the stream.

  • BAM Verifier Warning: Validators will be given 5 epochs to respond to data presented via the team to reform their practices and bring themselves within the contract bounds.

  • Disconnections will be triggered as-and-when sufficient evidence has been accumulated, which demonstrates overt violations of the BAM contract.

Phase 2:

  • Based on phase one data collection and statistical analysis, a statistical threshold will be set in the form of X unrecognised Tx violations in a 10 epoch window, and Y ordering violations in a 10 epoch window.

  • A dashboard will be presented to the BAM validator set that allows validators to review their data and analyse their practices against the data as it emerges.

  • Manual execution will take place on a periodic basis, with no warning, based on statistical thresholds.

  • If a validator feels that they have been incorrectly blacklisted, they will be able to appeal via a form and process rolled out at the beginning of phase 2.

Phase 3:

  • Fully automated BAM Verifier blacklisting, based on finalised statistical threshold and established practices.

  • From phase 3, validators will be blacklisted indefinitely from BAM for any sandwiching activity.

  • Other violations will lead to a X epoch blacklisting.

Blacklist Removal

  • From the point of publishing this policy, it will be possible to be removed from all existing blacklists, conditional on running BAM for at least 3 epochs and committing to continue running BAM.

  • If you are a validator that has run BAM for at least 3 epochs and is currently on a Jito Blacklist, contact us HERE to be removed.

1 Like
2

Thank you for publishing this unified blacklisting policy and opening it up for community feedback. I appreciate the transparency and the opportunity to contribute.

I’d like to raise a specific issue regarding commission-related blacklisting that I believe warrants consideration in this policy update.

The Issue: Lookback Window for Commission Changes

Currently, validators can be blacklisted for historical commission changes that occurred during legitimate operational transitions, even when those changes weren’t malicious “commission rugs”.

Our Case Study:

Our validator raised commission to 100% around Epoch 547 when we were planning to wind down operations. This is standard practice when sunsetting a validator - you signal to delegators that the validator is no longer actively competing for stake. We subsequently revived the validator and restored normal commission rates, but the historical 100% commission triggered a blacklisting.

Proposed Amendment:

I suggest the policy include a defined lookback window for commission-related violations - perhaps 100 epochs - after which historical commission changes would no longer count toward blacklisting criteria. This would:

  1. Still catch bad actors - 100 epochs is more than sufficient to identify and penalize actual commission rugs and other nefarious behaviour

  2. Allow for legitimate operational changes - Validators going through transitions, wind-downs, or ownership changes wouldn’t be permanently penalized for non-malicious actions

  3. Encourage validator recovery - Operators who’ve reformed their practices and returned to the network in good standing shouldn’t be indefinitely punished for historical decisions

Additional Context:

The policy already acknowledges the value of rehabilitation through the BAM-based blacklist removal process. Extending this principle to include a reasonable lookback window for commission violations would align with that philosophy.

Happy to provide additional details or data if helpful.

3 Likes
3

Hey @wallypues Thank you for the consideration and proposed amendment. Will do some analysis on it and get back to you before we freeze the policy.

2 Likes