> For the complete documentation index, see [llms.txt](https://docs.marinade.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/blacklist-policy.md). # Blacklist Policy Grounds for blacklisting a validator from the Marinade Stake Auction Marketplace, and the process for removal from the blacklist. {% hint style="info" %} **TL;DR:** Blacklisting is triggered by automated, per-epoch detection against published criteria: sandwich MEV, slow voting, slow slots, commission rugs, and similar. Blacklisted validators cannot receive Marinade stake, and a bond penalty is charged once, in the epoch the validator first appears on the list. Appeals are possible through Discord with evidence. {% endhint %} ## Overview The Marinade Foundation sets the criteria by which validators may be blacklisted from the Marinade Stake Auction Marketplace, and Marinade Labs operates the tooling that applies them. Blacklisting is a last resort and is enforced only in clearly defined, verifiable cases, based on objective data and reproducible metrics. *** ## General Principles * **Validators that harm the network may be blacklisted:** The blacklist is reserved for behaviors with a clear negative impact on Solana or on Marinade stakers. * **Listing is automated, not discretionary:** Tooling runs every epoch and checks every validator against the published criteria using public data sources, across multiple epochs so that single-epoch noise does not trigger a listing. There is no per-validator judgment call and no per-validator vote to add a validator to the list. * **Continuously updated:** The blacklist is updated continuously and without prior notice as the detection tooling runs. * **Transparent criteria changes:** The Marinade Foundation may update blacklisting criteria at any time, but in non-trivial cases will do so only with broad community consensus and in support of Solana's long-term health. * **Discretion applies to removal, not to listing:** Appeals and reinstatements are reviewed by the team case by case. Additions to the list are not. *** ## Grounds for Blacklisting A validator may be blacklisted for: * **MEV sandwich attacks:** Engaging in MEV sandwich attacks in over 30% of blocks they produce. * **Network degradation:** Intentionally introducing latency or degrading network bandwidth, detected as sustained slow slot production across consecutive epochs. * **Slow voting:** Also known as vote lagging. * **Commission rugs:** Raising commission to capture rewards that would otherwise go to stakers. * **Cluster restart failures:** Failing to restart their node within 36 hours after a cluster restart due to a halt, if it occurs at least twice. * **Malicious MEV behavior:** Any other form of malicious MEV behavior, per MIP-9. * **Missing BLS key:** Having no BLS public key registered on the vote account. Since the first slot of epoch 1006 Solana builds its leader schedule and inflation rewards only from validators with a registered key (SIMD-0357), so a keyless validator earns nothing for itself or its stakers. Each entry on the live list carries a reason code naming the criterion that produced it: | Reason code | Meaning | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | | `MALICIOUS_SM_*` | Sandwich-attack MEV, suffix is the epoch of detection | | `SLOW_SLOTS_*` | Slow slot production / introduced latency, suffix is the epoch of detection | | `SLOW_VOTER` | Vote lagging | | `BLACKLIST_COMMISSION_RUG`, `COMMISSION_RUG_*` | End-of-epoch commission rug | | `MALICIOUS_MIP_9` | Other malicious behavior under MIP-9 | | `EXITING_CLUSTER` | Failure to restart after a cluster restart | | `MISSING_BLS_*` | No BLS public key registered on the vote account, suffix is the epoch of detection (currently `1006`, the epoch the requirement took effect) | ### Consequences * **No prior warning:** Detection and listing happen automatically. There is no advance notice. * **Exclusion from delegation:** Blacklisted validators are made ineligible and receive no Marinade stake. They also sit in the first redelegation tier, so existing Marinade stake moves away from them ahead of everyone else. See Stake Distribution and Decentralization. * **Bond penalty, charged once:** The auction charges a blacklist penalty from the bond in the epoch a validator **first** appears on the list. It is not recharged in subsequent epochs while the validator stays listed. The penalty per 1,000 SOL of stake per epoch is: ``` blacklist_penalty_pmpe = clearing_price + min(3 x effective_participating_bid, clearing_price) ``` Both terms come from that epoch's auction, so the charge scales with the clearing price and with how aggressively the validator was bidding, not with a case-by-case severity assessment. The resulting settlement is paid from the bond to stakers. #### **Where the Blacklist Is Published**
SourceWhat it is
delegation-strategy-2/blacklist.csvThe canonical live list. This is the file the auction pipeline pulls each epoch, via blacklistApiBaseUrl in auction-config.json
ds-sam-pipeline auctions folderPer-epoch snapshot of the list as used by that auction, at <epoch>/inputs/blacklist.csv. Use this to see the list as it stood in a past epoch
PSR dashboard protected-events viewShows whether a validator has been flagged as blacklisted
*** ## How to Appeal Validators who believe they were blacklisted in error or who have reformed after a legitimate flag may submit an appeal through the Marinade Discord. An appeal does not guarantee removal from the blacklist. Marinade investigates each case independently before making a decision. {% hint style="warning" %} Always get the Discord invite from Marinade's [Official Links](https://docs.marinade.finance/official-links) page. Never use a Discord link sent to you in a direct message. {% endhint %} To submit an appeal, open a ticket in the Marinade Discord server and include: * **The reason for blacklisting:** State the specific behavior and, where you have it, the reason code from `blacklist.csv` (e.g. `SLOW_SLOTS_*`, `MALICIOUS_SM_*`). * **Why it happened:** Provide root cause. Was it intentional, a misconfiguration, a third-party issue, or a fixed bug? * **What has changed:** Describe the corrective action taken and any supporting evidence Marinade can verify. * **Your vote account address**, and the epoch in which the listing appeared. Tickets that simply request removal without supporting information will typically be ignored. ### Removal From the Blacklist * **Unjustified blacklisting:** If an appeal shows the blacklisting was unjustified (e.g. due to misinterpreted performance data), the validator will be removed after review and approval by the team. * **Rightful blacklisting:** If the blacklisting was rightful, removal is possible only after a minimum 1-month observation period of sustained good behavior. The validator must show a clean record of no further policy violations, maintain good uptime, and keep up with network patches. The actual length of the review is determined case by case and may extend beyond one month based on the nature of the original offense and the team's review schedule. * **Team discretion:** All removals are ultimately at the team's discretion. An appeal ticket starts the review process but does not guarantee reinstatement. * **Commission rugs:** Validators blacklisted for commission rugs are permanently excluded. No appeals. * **Repeat offenders:** Repeat offenders are permanently blacklisted and ineligible for Marinade stake. No appeals. Marinade retains discretion to determine what constitutes a repeat offense. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.marinade.finance/marinade-protocol/protocol-overview/stake-auction-market/blacklist-policy.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.