Wszyscy zaangażowani w dyskusję na temat ograniczeń prędkości w DeFi kilka lat temu mieli rację, że potrzebne są dodatkowe mechanizmy bezpieczeństwa. Jednak głównym i często ukrytym założeniem tych rozmów było to, że same protokoły DeFi będą musiały wprowadzić te zabezpieczenia. W dużej mierze nie widzieliśmy, aby ta wizja przyszłości się zrealizowała. Może w przyszłości, gdy TradFi pojawi się w większym rozrachunku, wszystkie transakcje będą wymagały podpisu zaufanej trzeciej strony, aby móc wykonać je na łańcuchu, jak @0xPredicate. Odpowiednie miejsce dla tego rodzaju zabezpieczeń dotyczących limitów prędkości i opóźnień jest po stronie użytkownika końcowego, a nie w samym protokole. W ten sposób każdy użytkownik może wybrać opóźnienia i limity prędkości, które preferuje (jeśli w ogóle) z ich portfela. To jest problem, który rozwiązuje @KleidiWallet, każdy użytkownik może wybrać swój model zagrożeń i skonfigurować swój portfel w sposób, który maksymalizuje ich zdolność do określenia swoich preferencji. Jedynym wyjątkiem od tej zasady byłby @phylaxsystems, ponieważ pozwala deweloperom wprowadzać dodatkowe zasady i invariaty do swojego protokołu za pośrednictwem sekwencera na L2. Ich system nie opiera się na ograniczeniach prędkości, lecz na invariatach. Na razie ograniczenia prędkości w DeFi są martwe. Może w następnym cyklu...