Detta kan vara kontroversiellt, men dina transaktioner bör kunna slå tillbaka mot skadliga valideringstekniker. Jag byggde ett enkelt program för att göra just det. Du kan inte veta vid körning om glidning är naturlig marknadsrörelse eller en smörgåsattack. Men om ditt byte landar på en känd skadlig validerare, är du praktiskt taget garanterad att bli inklämd upp till din maximala glidning. På så sätt kan du slå tillbaka. ✅ Använder du en betrodd validerare? Din transaktion fortsätter med din önskade glidning (x%). ❌ På en illvillig validerare? Din transaktions glidning justeras (0 %, en bråkdel av x, vad du vill) Istället för att bara gå tillbaka kan din transaktion lyckas med strängare begränsningar när du kör i en mörkare skog. När du skapar och signerar din transaktion vet du inte exakt vilken validerare den kommer att landa på, så logik är att ändringsbeteendet måste finnas i kedjan. Så hur fungerar det? Ett Solana-program kan inte komma åt den aktuella valideraren, men det kan komma åt den aktuella platsen. Programmet tar in en kompakt representation (14 byte men kan minskas ytterligare) för att låta programmet kontrollera om platsens ledare är flaggad som skadlig. Några sätt att använda den: (1) Du kan infoga den direkt som en enkel instruktion (<260 CU, varav det mesta är att komma åt Clock sysvar). Återställer hela tx när den landar på en skadlig validerare (2) Du kan använda den för att linda in Jupiter v6-routern. Det kommer att anropa Jupiter-programmet och dynamiskt åsidosätta värdet för "glidning", men bara när det körs på en skadlig validerare (3) Ring det direkt via CPI från ditt eget program Listan över skadliga validerare och deras kommande slots kan hämtas från vårt kommande Sandwiched[dot]me API eller från dina egna data. Tänk på att den här prototypen är experimentell. Den distribueras inte i kedjan. Skulle gärna få din feedback och PR är välkomna