Model opłat sieci Solana ma stać się znacznie bardziej szczegółowy, a na tej zmianie prawdopodobnie nie skorzysta każda aplikacja. Symulacja przeprowadzona przez analityka @MostlyData_ szacuje, co SGP-0003 oznaczałoby dla kosztów transakcji w całej sieci, a jej wyniki wskazują na wyraźnych zwycięzców, wyraźnych przegranych i znacznie wyższe tempo spalania tokenów.

Propozycja zarządcza, wprowadzona 3 sierpnia 2026 r. wraz z SIMD-0553, zastąpiłaby stałą opłatę bazową Solany w wysokości 5 000 lamportów (lamport to najmniejsza jednostka Solany, miliardowa część SOL) strukturą dwuczęściową: stałą opłatą za włączenie do bloku wynoszącą 2 500 lamportów, płaconą liderowi bloku, oraz zmienną opłatą zasobową, która zaczyna się od 0,1 lamporta za żądaną jednostkę obliczeniową i jest w całości spalana.

Co wykazała symulacja

Główny wniosek jest prosty: transakcje w sieci Solana żądają znacznie więcej mocy obliczeniowej, niż faktycznie wykorzystują. Średnio transakcje żądają o około 20% więcej jednostek obliczeniowych, niż zużywają. Ten zapas ma praktyczne uzasadnienie: transakcja Solany, która przekroczy żądany limit obliczeniowy, kończy się niepowodzeniem, dlatego aplikacje zawyżają swoje żądania, aby uniknąć nieudanych transakcji. W obecnym modelu stałych opłat takie zawyżenie nie generuje dodatkowych kosztów. Przy SGP-0003 już tak nie byłoby.

Ta rozbieżność najsilniej dotyka routerów i agregatorów. Symulacja oszacowała średnie wzrosty opłat na około 0,000068 SOL dla Jupiter, 0,00010 SOL dla Titan oraz 0,00012 SOL dla DFlow.

Tylko około 28% transakcji odnotowałoby wzrost opłat o mniej niż 10%, gdyby wycena zasobów ściśle odzwierciedlała rzeczywiste zużycie.

Walidatorzy mogliby odnieść jedną z niewielu bezpośrednich korzyści. Zoptymalizowane transakcje głosowania mogą stać się w proponowanym modelu o około 12,3% tańsze.

Tempo spalania gwałtownie wzrosłoby

Obecnie Solana spala około 648 SOL dziennie z tytułu opłat za podpisy. Symulacja przewiduje, że SGP-0003 mógłby zwiększyć dzienne spalanie do poziomu od 1 500 do 9 000 SOL. Spalanie opłat transakcyjnych jako narzędzie oddziałujące na podaż nie jest rozwiązaniem unikalnym dla Solany: Ethereum niszczy opłatę bazową z każdej transakcji od momentu wprowadzenia tego mechanizmu w ramach aktualizacji London w sierpniu 2021 r.

Propozycja została wprowadzona wraz z odrębną inicjatywą mającą na celu podwojenie wskaźnika dysinflacji Solany z 15% do 30%. Oznaczałoby to, że sieć jednocześnie zwiększyłaby spalanie tokenów i przyspieszyłaby redukcję emisji nowych tokenów.

Aplikacje musiałyby się dostosować

Propozycja w praktyce tworzy karę za nieefektywność. Aplikacje, które precyzyjnie kalibrują żądania obliczeniowe, płaciłyby opłaty zbliżone do obecnej stawki stałej lub potencjalnie niższe. Aplikacje, które rutynowo żądają nadmiarowych jednostek obliczeniowych, płaciłyby więcej za taki bufor bezpieczeństwa.

Animatorzy rynku działający na centralnych księgach zleceń (CLOB) stoją przed szczególnym dylematem. Systemy te przesyłają duże liczby transakcji o znacznych wymaganiach obliczeniowych, a nawet niewielkie zmiany opłat w przeliczeniu na pojedynczą transakcję mogą szybko sumować się w istotne zmiany kosztów. Symulacja wskazuje animację rynku CLOB jako kategorię szczególnie narażoną na proponowane zmiany wyceny.

Routery takie jak Jupiter odpowiadają już za znaczną część przepływu transakcji DeFi w sieci Solana. Nawet umiarkowany wzrost opłaty przy każdej wymianie mógłby przełożyć się na użytkowników końcowych lub obniżyć marże protokołów agregujących.

Żadna z tych zmian nie weszła jeszcze w życie: SGP-0003 pozostaje propozycją zarządczą, a symulacja modeluje jej proponowane parametry, a nie zmiany już przyjęte przez sieć.