# JIP-22: Establish a Mechanistic MEV Blacklist & Blacklist Operations Committee **URL:** \ **Category:** JIP - Official\ **Created:** [July 18, 2025, 11:19pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839 "2025-07-18T23:19:52Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![drnick](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/drnick/32/187_2.png) [@drnick](https://forum.jito.network/u/drnick)\ **Post date:** [July 18, 2025, 11:19pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/1 "2025-07-18T23:19:52Z")
# 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: 1. **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. 2. **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. 3. **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. 4. **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. | **Operational Complexity:** Scripts + appeals add overhead. | | **Vote Relief:** Tokenholders avoid repetitive votes for routine actions. | **Data Stream Reliance:** Dependence on external data sources. | | **Fairness:** Appeals guard against false positives. | **Multisig Security:** BOC keys must be carefully secured. | ## Outcomes - **Immediate:** BOC stands up; StakeNet updated; Ghost data stream and thresholds set. - **Ongoing:** Each epoch, automated blacklist + 50-epoch sanction roll out; validators may appeal. - **Long-Term:** A robust, adaptable mechanistic MEV defense. ## Cost Summary - No direct JTO spend. - Administrative resources for script maintenance, data storage, and appeals reviews—covered by existing Foundation budgets. ---
**Author:** ![Chainflow](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/chainflow/32/28_2.png) [@Chainflow](https://forum.jito.network/u/Chainflow)\ **Post date:** [August 5, 2025, 1:03pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/2 "2025-08-05T13:03:29Z")
In support of this proposal. 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. ---
**Author:** ![drnick](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/drnick/32/187_2.png) [@drnick](https://forum.jito.network/u/drnick)\ **Post date:** [August 11, 2025, 12:49pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/3 "2025-08-11T12:49:24Z")
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. ---
**Author:** ![kron](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/kron/32/249_2.png) [@kron](https://forum.jito.network/u/kron)\ **Post date:** [August 25, 2025, 12:10pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/4 "2025-08-25T12:10:10Z")
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. ---
**Author:** ![drnick](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/drnick/32/187_2.png) [@drnick](https://forum.jito.network/u/drnick)\ **Post date:** [September 17, 2025, 7:13pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/5 "2025-09-17T19:13:47Z")
# **Validator Blacklisting Updates** 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](https://docs.google.com/spreadsheets/d/1S6HWr6KyVuRkgyG-liYmGA1gGTtKWCFr2qwP1sZPDoc/edit?usp=sharing). 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**. ---
**Author:** ![drnick](https://sea1.discourse-cdn.com/jito/user_avatar/forum.jito.network/drnick/32/187_2.png) [@drnick](https://forum.jito.network/u/drnick)\ **Post date:** [September 17, 2025, 7:14pm UTC](https://forum.jito.network/t/jip-22-establish-a-mechanistic-mev-blacklist-blacklist-operations-committee/839/6 "2025-09-17T19:14:47Z")
# **Blacklist Operations Committee** ## **Scope** - 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: ## **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. - **Grounds** (choose any that apply): - **Evidence package:** on-chain metrics, logs, infra attestations, third-party reports/audits, remediation steps already taken. ## **BOC Structure** - **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. - **The BOC is an appeals processing and veto structure only**. - **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.