This might be controversial, but your transactions should be able to fight back against malicious sandwiching validators. I built a simple program to do exactly that. You can't know at runtime if slippage is natural market movement or a sandwich attack. But if your swap lands on a known malicious validator, you're practically guaranteed to get sandwiched up to your max slippage. This lets you fight back. ✅ On a trusted validator? Your transaction proceeds with your desired slippage (x%). ❌ On a malicious validator? Your transaction’s slippage is adjusted (0%, some fraction of x%, anything you want) Instead of just reverting, your transaction can succeed with tighter constraints when running in a darker forest. When you create and sign your transaction, you don't know exactly what validator it will land on so logic that changes behavior has to be onchain. So how does it work? A Solana program cannot access the current validator, but it can access the current slot. The program takes in a compact representation (14 bytes but can be further reduced) to let the program check if the slot's leader is flagged as malicious. A few ways to use it: (1) You can insert it directly as a simple instruction (<260 CU, most of which is accessing the Clock sysvar). Reverts the entire tx when it lands on a malicious validator (2) You can use it to wrap the Jupiter v6 router. It will call the Jupiter program and dynamically override the `slippage` value but only when it runs on a malicious validator (3) Call it directly via CPI from your own program The list of malicious validators and their upcoming slots can be sourced from our upcoming Sandwiched[dot]me API or from your own data. Keep in mind this prototype is experimental. It's not deployed onchain. Would love to get your feedback and PRs are welcome