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. | 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.