Intencja to zlecenie, które mówi, jaki wynik chcesz otrzymać, a nie jakie transakcje należy wysłać. Podpisujesz je, konkurujący solverzy licytują prawo do dostarczenia wyniku, a warstwa rozliczeniowa płaci temu, kto to zrobił. Trasowanie, gaz i czekanie między łańcuchami przechodzą z użytkownika na profesjonalnego kontrahenta, a w zamian pojawia się inny zestaw pytań: kto może licytować, według jakiej miary się go ocenia, co stoi za jego obietnicą i co dzieje się z twoimi pieniędzmi, gdy nikt nie licytuje.
Zlecenie deklaratywne: czym naprawdę jest intencja
Zwykła transakcja jest imperatywna. Wskazuje kontrakt, funkcję, argumenty i gaz, a podpis autoryzuje dokładnie jedną ścieżkę obliczeniową na danym stanie. Wszystko jest przesądzone przed podpisem, a wszystko, czego nie przewidziano, jest twoim problemem.
Intencja jest deklaratywna. To podpisany zestaw ograniczeń opisujący wynik, który zaakceptujesz, i dopuszcza każdą ścieżkę wykonania, która te ograniczenia spełnia. Transakcja mówi: „zrób A, potem B, zapłać dokładnie C i odbierz X”, a intencja mówi: „chcę X i jestem gotów zapłacić najwyżej C”. W tym ujęciu transakcja jest szczególnym przypadkiem intencji, dopuszczającym dokładnie jedno przejście stanu.
Praktyczny skutek jest taki, że podpisując i rozsyłając intencję, dajesz stronie trzeciej prawo wyboru ścieżki obliczeniowej za ciebie. Stąd bierze się wygoda i stąd bierze się każde ryzyko opisane dalej.
Sam pomysł nie jest nowy. Zlecenia z limitem ceny, płacenie prowizji tokenem, który już masz, agregatory obiecujące najlepszą trasę po kilku miejscach obrotu — wszystko to ma kształt intencji: użytkownik podaje warunek, ktoś inny dobiera wykonanie. Nowe jest to, że buduje się z tego ogólną infrastrukturę i że jedno zlecenie może obejmować kilka łańcuchów.
Cztery role w systemie intencji
Rozpisany jako cykl życia, ten wzorzec ma cztery części. Użytkownik wyraża intencję wobec aplikacji; aplikacja zamienia ją w zlecenie konkretnego protokołu; zlecenie trafia do strumienia zleceń, w którym widzą je solverzy; solver ocenia je, wykonuje wymagane kroki, a procedura rozliczeniowa płaci solverowi.
Ten słownik warto opanować, bo trafił już do standardu. Zlecenie to oferta zapłaty w zamian za spełnienie zestawu wymagań. Solver, nazywany też fillerem, to podmiot, który te wymagania spełnia. Zapłata domyka pętlę: solver najpierw wykonuje pracę, a pieniądze dostaje przy rozliczeniu.
Chodzi o standard ERC-7683, czyli intencje międzyłańcuchowe (Cross Chain Intents). To ERC ze ścieżki Standards Track, utworzony w kwietniu 2024 roku, a w chwili pisania wciąż ma status Draft, czyli projekt. Został przy tym mocno przebudowany: wcześniejsza wersja standaryzowała kodowanie zleceń, strumień zleceń w łańcuchu, depozyt i funkcję wykonania, a obecny tekst standaryzuje wyłącznie interfejs, przez który solver czyta zlecenie, zostawiając protokołom swobodę w tworzeniu zleceń, autoryzacji, wycenie i rozliczeniu. Opiera się na ERC-7930, formacie adresów międzyłańcuchowych, który ma status Review.
Status projektu znaczy tu więcej niż zwykle, bo to nie jedyna propozycja w tym obszarze: ERC-7521 opisuje ogólne intencje dla portfeli opartych na smart kontraktach i również pozostaje projektem. Nie traktuj tego jako przesądzonego. Pole statusu każdego ERC stoi na początku jego strony w repozytorium Ethereum ERCs, a bieżąca dyskusja toczy się we wskazanym tam wątku na Ethereum Magicians, więc sprawdź aktualny etap sam.
Dlaczego to solver wykłada pieniądze
Pod intencjami międzyłańcuchowymi leży niewygodny fakt: dwa łańcuchy nie rozliczają się atomowo, ktoś musi ruszyć pierwszy. W typowym rozwiązaniu środki użytkownika zostają zablokowane w kontrakcie na łańcuchu źródłowym w momencie utworzenia zlecenia, żeby solver miał pewność, że pieniądze istnieją, zanim zaangażuje własny kapitał po drugiej stronie.
Następnie solver dostarcza wynik z własnych zapasów: ma aktywo na łańcuchu docelowym, wysyła je tobie, a zwrot dostaje dopiero później, z zablokowanych środków, poprzez procedurę rozliczeniową. W jednym z działających rozwiązań wykonania zbiera się w paczki, a zwroty następują w cyklu liczonym w godzinach, nie w sekundach — dlatego solver potrzebuje kapitału obrotowego, a nie tylko szybkiego bota.
Transakcje wysyła również solver, czyli to on płaci gaz. Na tym polega mechanizm przepływów intencji reklamowanych jako bezgazowe: koszt nie zniknął, został przeniesiony do ceny, którą solver ci podaje.
Luka między wydatkiem a zapłatą to dokładnie miejsce, w którym mieszka ryzyko solvera. Sekcja bezpieczeństwa samego standardu mówi to wprost: solver jest wystawiony od chwili, gdy zaangażuje kapitał, zgody lub transakcje, aż do momentu, gdy oczekiwana zapłata stanie się ostateczna i dostępna. Wszystko, co może się w tym oknie wydarzyć — reorganizacja łańcucha, dostarczenie wiadomości, zmiana stanu protokołu — jest już wliczone w kwotowanie, które widzisz.
Jak konkurencja ustala cenę, którą dostajesz
Skoro użytkownik przestał wskazywać trasę, cenę musi wytworzyć konkurencja. Rozwiązania różnią się sposobem: gdzieś działa aukcja holenderska, w której poprzeczka do pobicia przesuwa się w czasie; gdzieś cena pochodzi z wyroczni; gdzieś prowizja jest stała, a solverzy ścigają się wyłącznie na szybkość.
Aukcje pakietowe są wersją najbardziej jawną. Zlecenia zbiera się w krótkim oknie, solverzy składają całe rozwiązania, każde rozwiązanie ocenia się mniej więcej według nadwyżki, jaką daje użytkownikom w paczce, i wygrywa rozwiązanie z najwyższą oceną. Zwycięzcom płaci się według reguły drugiej ceny, więc nagroda zależy od przewagi nad kolejną najlepszą ofertą, a nie od tego, co zwycięzca sam sobie policzył.
Konkurencja pomaga tylko wtedy, gdy istnieje punkt odniesienia. Jeden z opublikowanych zbiorów reguł wymaga, by ceny solvera były nie gorsze niż to, co użytkownik dostałby z wyznaczonej listy bazowych źródeł płynności, i wymaga jednolitych cen rozliczeniowych: dwa zlecenia na tej samej parze w tym samym kierunku muszą dostać tę samą cenę. Bez czegoś takiego najlepsze wykonanie znaczy tyle, ile powie zwycięski solver.
To także uczciwa odpowiedź na pytanie, dlaczego intencje wygrywają z ręcznym trasowaniem. Solver może skojarzyć twoje zlecenie z przeciwstawnym zleceniem innego użytkownika, spakować kilka wykonań w jedną transakcję i wybrać do zwrotu ten łańcuch, który kosztuje go najmniej. Oszczędności są prawdziwe, ale trafiają do ciebie w takim stopniu, w jakim wymusza to konkurencja i reguła punktacji.
Co naprawdę stoi za obietnicą solvera
Podpisanie intencji daje komuś pole manewru. Nadużyciom zapobiega nie podpis, lecz warstwa odpowiedzialności zbudowana wokół zbioru solverów — a ta wygląda inaczej w każdym systemie, co większość wyjaśnień pomija.
Pierwszym mechanizmem jest zwykle wejście. W jednym z opublikowanych zbiorów reguł solver musi trafić na białą listę, zanim w ogóle wyśle rozliczenie; operatorzy prowadzą monitoring, który sprawdza każde rozliczenie w łańcuchu i oznacza podejrzane; systematyczne łamanie reguł bywa karane, aż po slashing.
Drugim mechanizmem jest weryfikacja z oknem sporu. Zamiast dowodzić każdego wykonania w łańcuchu, jedno z rozwiązań rozliczeniowych pozwala uczestnikowi zgłosić paczkę wyników wraz z kaucją, a paczka zostaje przyjęta, jeśli nikt nie zakwestionuje jej w ustalonym czasie. Użytkownik dostaje szybkość od razu, dowód przychodzi później.
Trzecim mechanizmem jest sama granica zaufania, a standard nietypowo szczerze mówi, gdzie ona przebiega. ERC-7683 standaryzuje sposób opisania zlecenia solverom; nie standaryzuje ani nie gwarantuje bezpieczeństwa protokołu, który ostatecznie je rozlicza. Od solverów oczekuje się, że sami zweryfikują kontrakt tłumaczący im zlecenia i potwierdzą założenia, których ten kontrakt nie jest w stanie sprawdzić. Użytkownikowi standard nie obiecuje niczego o systemie rozliczeniowym pod spodem.
Koncentracja, cenzura i droga powrotu twoich pieniędzy
Ryzyko strukturalne modelu intencji polega na tym, że krąg podmiotów widzących i mogących wykonać twoje zlecenie robi się wąski. Jeśli dostęp do przepływu intencji jest reglamentowany, a lista dobrana niestarannie, przepływ zleceń się koncentruje, a ten, kto kontroluje jego dużą część, może pobierać rentę, a w skrajnym przypadku cenzurować.
Otwarta propagacja nie naprawia tego automatycznie. Węzeł, który potrafi zyskownie wykonać intencję, nie ma interesu w przekazywaniu jej konkurentom, a w pełni publiczna pula intencji wystawia zlecenia na tę samą ekstrakcję co publiczny mempool. Dlatego wiele systemów kończy na rozwiązaniach reglamentowanych lub hybrydowych i dlatego praktyczne pytanie brzmi nie o to, czy jest to zdecentralizowane, lecz kto jest na liście i kto o tym decyduje.
Powiązanym kosztem jest nieprzejrzystość. W najgorszej wersji podpisujesz coś, to znika i wraca jako transakcja, po której nie widać, kto ją złożył ani jakie warianty odrzucono. Jakość wykonania, której nie da się skontrolować, to jakość wykonania przyjmowana na wiarę.
Dalej jest najzwyklejszy przypadek awarii, częstszy niż te egzotyczne: nikt nie licytuje. Zlecenie ma termin wykonania. Jeśli minie bez wykonania i bez wykonania częściowego, zlecenie wygasa, a zablokowane środki wracają — zwykle na adres wskazany w zleceniu i domyślnie na łańcuchu źródłowym. Przyczyny są prozaiczne: nietypowo duża kwota, rzadka para tokenów albo chwilowy przestój solverów.
Ten zwrot nie jest jednak natychmiastowy. Pieniądze wracają tą samą paczkową procedurą rozliczeniową, która płaci solverom, więc normalne wykonanie trwa sekundy, a wygaśnięcie potrafi rozwijać się godzinami. Gdy dobierasz wielkość zlecenia albo budujesz produkt na intencjach, termin wykonania i droga zwrotu to dwa parametry warte przeczytania przed prowizją.
Podsumowanie
Intencje przenoszą pracę wykonawczą z użytkownika na licytującego: podpisujesz wynik, którego chcesz, solverzy konkurują o jego dostarczenie, wykładają kapitał i gaz, a warstwa rozliczeniowa płaci temu, kto zadanie wykonał. Zysk na efektywności jest prawdziwy i wymiana też jest prawdziwa, bo oddajesz stronie trzeciej swobodę decydowania, jak wykonać twoje zlecenie, a chroni cię nie podpis, tylko reguły aukcji, miara, według której ocenia się oferty, zasady wejścia i monitoring wokół zbioru solverów oraz termin, który zwraca ci pieniądze, gdy nikt nie licytuje. Standard zleceń międzyłańcuchowych ERC-7683 wciąż jest projektem i już raz został przeprojektowany, więc każdy jego opis, łącznie z tym, traktuj jak migawkę i przed budowaniem na nim sprawdź pole statusu.
Zastrzeżenie: ten artykuł to treść edukacyjna Bitbase Academy, wyłącznie w celach informacyjnych. Nie stanowi porady inwestycyjnej, handlowej, podatkowej ani finansowej. Kryptoaktywa są zmienne — samodzielnie oceń ryzyko. Napisano w sierpniu 2026 r.; sprawdzaj aktualne oficjalne informacje.
Źródła
[1] ERC-7683: Cross Chain Intents eips.ethereum.org
[2] ERC-7930: Interoperable Addresses eips.ethereum.org
[3] ERC-7521: General Intents for Smart Contract Wallets eips.ethereum.org
[4] Intent-Based Architecture and Their Risks paradigm.xyz
[5] What are Crosschain Intents? docs.across.to
[6] Intent Lifecycle in Across docs.across.to
[7] Refunds docs.across.to
[8] Solver competition rules docs.cow.fi
