JIP-22: Establish a Mechanistic MEV Blacklist & Blacklist Operations Committee
Category: Procedural / Structure
Abstract
This proposal creates a blacklist operations committee (BOC) empowered to execute an semi-automated (targeting fully automated), epoch‐by‐epoch MEV blacklist using configurable oracles for sandwiching activity without requiring full DAO votes each time. It also establishes a minimal appeals process and preserves tokenholder control over StakeNet parameters.
Motivation
Jito DAO takes a zero tolerance approach to malicious MEV activity. Throughout Jito’s history the network has evolved forwards with a strong ethos of improving Solana network health. As part of this comes the strong belief that sandwiching activity is bad for Solana users, is fundamentally extractive and should be eliminated from the network.
It is imperative that Jito continues to show leadership towards better market practices and remains “the best” at maximising execution value (MEV), which includes removing harmful flow from Solana’s blockspace.
Other design directions:
Speed & Consistency: One‐off blacklists (JIP-4, JIP-15) took weeks. We need a near‐real‐time mechanism to keep pace with the evolving MEV arms race.
Governance Minimization: Routine epochal blacklists should run automatically once thresholds and data sources are approved. The goal is to achieve a safe, effective and harm reductive mechanism for pool curation.
Flexible Data Streams: The intervention will lean heavily on Ghost, who will serve as our initial data provider. This JIP seeks the mandate to be able to modify, update and augment data sources to achieve maximal accuracy.
Fairness & Oversight: A lightweight appeals process will be implemented to allow validators in the sanction period to regain access to the pool with evidence that successfully contradicts the data source.
Key Terms
Blacklist Operations Committee (BOC): A small body (6 members) responsible for managing blacklist execution and appeals.
Data Stream: An approved service providing per-validator sandwich rates (Ghost initially).
Default Threshold Rule: A validator is flagged if, over 10 consecutive epochs, their sandwich rate exceeds max(25%, 2× cluster median). Threshold Rule changes will be announced on the governance forum.
Epochal Blacklist: Each epoch, the BOC’s script generates the list of flagged validators to remove from the stake pool. The Blacklist will be executed by optimistic governance with a 2 epoch timelock with BOC veto authority.
Sanction Period: 50 epochs removal from JitoSOL stake pool.
Appeals Window: 14 days post-sanction for validators to submit evidence.
Blacklist Authority: A subset of StakeNet stakepool curation authority. This proposal transfers the “Blacklist” powers to the BOC.
DAO Veto: Jito DAO has the authority to retire the BOC’s authority and return blacklist authority to the DAO.
Specification
The passing of this JIP will transfer a subset of StakeNet pool curation authority to the BOC (Blacklist Operations Committee). Their role is to steward the technical execution of a mechanised approach to Blacklist enforcement.
The details:
BOC Composition & Authority: A five-member Blacklist Operations Committee, each serving 12-month terms, will be empowered via an amended StakeNet multisig to update the on-chain blacklist parameter at the end of every epoch.
Data Stream & Threshold Configuration: The BOC will initially pull sandwich-rate data from the Ghost API and flag any validator whose rate exceeds the greater of 25% or twice the cluster median over a 10-epoch window.
Automated Epochal Blacklist Execution: Within one week of each epoch’s close, an automated script will fetch approved oracle data and the BOC’s multisig will push a StakeNet transaction to suspend flagged validators from the JitoSOL stake pool for 50 epochs.
Validator Appeals Process: Sanctioned validators have a 14-day window to file an appeal with the BOC, after which a three-member panel reviews and can revoke stakepool sanctions.
Transparency & Reporting: A quarterly research report will share details of the performance of the blacklist mechanism.
Benefits / Risks
Benefits
Risks
Near Real-Time Defense: Epochal blacklists close vulnerability windows.
Vetting these behaviors at a regular cadence can improve the quality and efficiency of the project. Publicizing the blacklist (wallets + monikers) post-appeal process could also support social slashing, adding reputational consequences to technical enforcement. That transparency might help reinforce good behavior across the validator set entirely.
One suggestion: While Ghost is a solid starting point for data, I’d recommend building toward cross-referencing with at least one independent oracle in the near future. Relying on a single data provider long-term can introduce unnecessary risk. Even a basic secondary source or open-source pipeline could help validate findings and reduce doubt during appeals.
Thanks @Chainflow. I totally agree, I used the terms “flexible data streams” to get us to this eventuality. We don’t commit to ghost exclusively. It will be important that this kind of data be triangulated with multiple sources over time to avoid over emphasising the importance of any one source and methodology.
Hello, this seems like a reasonable proposal. How long will it take for the sandwichers to loose their stake if flagged? Also, how did the 25% number come about? What I understand is that it is very hard to achieve even numbers above 10% or even 3% for extended periods of time for validators which do not engage in sandwiching actively and conciously.
Following the completion of the recent vote and execution of JIP-22 and JIP-23, the first wave of validator blacklisting has taken place. A total of 28 validators have been blacklisted and are viewable on the sheet HERE. Blacklisted validators were executed in two batches. The first using the v1 Ghost API data. The second incorporated both v1 and v2 Ghost API data, which incorporates a wider spectrum of sandwiching strategies.
The process utilised data from the Ghost API, and the Ghost, Pine and Solana Compass data dashboards. All blacklisted validators had 30d or 60d sandwich rates over 25% and were each vastly over 2X the cluster median sandwich rate. In some cases they were also lagging their blocks and fell within scope of JIP-23.
The larger list of sandwiching validators was filtered for active Jito stake and non-delinquency revealing the final list above.
Going forward, a triangulated set of data sources (including those mentioned above and others as they arrive) will be used to monitor the Jito Stake Pool in a continual fashion and any validators engaging in sandwiching activity, or lagging behaviour will be blacklisted. Jito is committed to driving the Solana network towards IBRL and minimising user harm from malicious MEV.
This post will be serially updated as the BOC modifies the blacklist. Check back here if you think you have been included.
If you are a blacklisted validator and wish to appeal, details of how to appeal to the BOC can be found in the following post.
As a mechanistic structure the BOC operates based on objective data sources and executes blacklisting actions based on these data. Validators reaching a threshold level of sandwiching will be blacklisted indefinitely from the Jito Stake Pool.
The BOC operates on a “shoot first” principle, blacklisting validators with obvious sandwiching activity over thresholds identified in JIP-22. It will then leverage the following appeals process to allow validators to provide counter evidence via the forum:
Decisions eligible for appeal: (a) blacklisted validators with sufficient evidence that the data is incorrect (b) validators with sufficient evidence of non-complicity in the sandwiching activity.
Who may appeal: the affected validator operator.
Frequency:max 1 appeal per operator per 6 months.
Timelines
Filing window: within 14 days of decision notice.
Acknowledgement: within 7 days of submission (case ID provided).
Review period: 7 days from acknowledgement.
Decision publication: within 7 days of decision.
Appeal Submission (what the appellant must provide)
Appeals should include the following information:
Cover form (validator identity and vote account address), operator name / entity, contact).
Decision challenged: identify which blacklisting event you were part of e.g. Wave One.
The BOC is composed of 5 parties, which are non-disclosed at this time to maintain the ability of the group to make potentially difficult decisions without fear of community reprisal. The usual high quality standards of recruitment to the committees and delegate structures across the DAO are maintained. If at some point in the future, evidence of conflicts appears, this may change.
Execution threshold is 3 of 5 quorum within the committee
The BOC is an appeals processing and veto structure only.
The BOC oversees the optimistic mechanism that leads to validator blacklisting i.e. data sources are used to detect sandwiching validators and those above threshold will be added to the blacklist queue and there will be a short period for the BOC to intervene to veto the blacklist before it is executed.
The BOC reviews appeals and reserves the ability to revoke validators from executed blacklists, allowing validators to re-enter the pool.
If this occurs, the BOC will be required to produce a reasoning for their decisions.
If the decision stands, the BOC may simply respond with “appeal denied” and is not required to justify their decision. The community will have the ability to see the publicly provided evidence and observe that it is insufficient grounds for appeal. The BOC, may however, justify their denials if they deem the information valuable for the wider community to shape their behaviours and actions in the stake pool.
Conflict check & recusal: any member with a conflict recuses themselves from the appeal consideration; if more than 3 members are recused and the committee becomes sub-quorate, then a 6th member will be temporarily added to the BOC to resolve the deadlock.
Scope and Function Update: If the scope and function of the BOC is updated, the community will be notified on this thread of the governance forum. This will be primarily to nuance this simple base form of the committee structure, for example, if additional process is required for unforeseen circumstances and edge cases.
Wind Down: If at any point the community feels as though the BOC is operating sub-optimally, or if its scope has drifted from the consent sought in JIP-22, then a new proposal to wind down the BOC should be posted to the “Drafts” section of the governance forum. If at least 3 delegates endorse the proposal it will be elevated to official and will go to token holder vote.
An Open and Public Process
To ensure that this process remains transparent, public and resistant to abuse / bias. All appeals will be made via this public forum. Any and all community members are welcome to debate, discuss and challenge the above structure and its operations via this thread.
Our commitments are to the Jito protocol and to the Solana Network, which includes the important mission of minimizing harmful MEV on the network. Our intent is to eliminate sandwich attacks in particular both from the Jito Stake Pool and the network at large. DO NOT engage in sandwiching activity if you wish to receive Jito stake.