Program Delivery vs Payment (DvP)

Program DvP to standardowy program do rozliczeń typu dostawa za płatność (delivery versus payment) w Solana, utrzymywany przez Solana Foundation i audytowany przez Cantina. Dwie strony uzgadniają wymianę, każda wysyła swoją nogę na konto escrow zwykłym transferem tokenów, a podmiot rozliczający rozlicza obie nogi w jednej transakcji, więc albo przechodzą obie, albo żadna. Podmiot rozliczający to trzeci adres wskazany w wymianie, na przykład platforma lub agent, który ją zorganizował. Żadna ze stron nie pisze ani nie wdraża programu, a portfel lub custodian, który potrafi wysłać standardowy transfer tokenów (TransferChecked), może sfinansować nogę bez żadnej integracji specyficznej dla DvP. Do czasu rozliczenia każda ze stron może odebrać własną nogę lub wycofać wymianę.

Jak to działa

Każda wymiana otrzymuje rekord należący do programu i dwa konta escrow, po jednym na nogę. Strona nogi aktywa (user_a) i strona nogi gotówkowej (user_b) finansują swoje nogi, przelewając tokeny na konto escrow danej nogi. Podmiot rozliczający to jedyny podpisujący, który może dokonać rozliczenia. Rozliczenie przesyła uzgodnioną kwotę każdej nogi na drugą stronę, zwraca ewentualną nadwyżkę stronie, do której należy dana noga, i zamyka rekord oraz oba konta escrow. Atomowość wynika z transakcji Solana: obie operacje transferu są w jednej transakcji, więc albo obie zostaną wykonane, albo żadna.

Każdy zwrot, odzyskanie środków i zwrot nadwyżki trafia do własnego associated token account strony: konta user_a dla mint_a i konta user_b dla mint_b. Custodian lub system skarbowy może sfinansować nogę ze swojego konta, ale wszystko, co zostanie zwrócone, trafia na konto strony, a nie z powrotem do custodiana. Każda wymiana pozostawia też trwałe konto-znacznik (zob. Stan).

Przewodniki

Strony z kolejnymi krokami prowadzą jedną wymianę od utworzenia do rozliczenia, z kodem w TypeScript i Rust dla każdej instrukcji.

Demo na devnecie pokazuje wymianę od początku do końca: tworzy wymianę, finansuje oba konta escrow standardowymi transferami tokenów i rozlicza obie nogi w jednej transakcji.

Wybór między programem a delegowaniem

Delivery vs Payment (DvP) z użyciem delegowania rozlicza tę samą wymianę bez programu: każda strona deleguje swoją pozycję agentowi rozliczającemu, który przesyła obie nogi w jednej transakcji.

• Program nie wymaga delegowania, więc limit jednego delegata na token account nie ma zastosowania, a podmiot rozliczający nie może przekierować środków. Każda wymiana zależy od programu z możliwością aktualizacji i jego upgrade authority.
• Wzorzec delegowania nie ma zależności od programu i działa z mintami, które mają Scaled UI Amount. Program odrzuca takie minty, co wyklucza każdy mint utworzony z szablonu tokenized-security z Mosaic (zob. ograniczenia konfiguracji mintów).

Role

Program jest symetryczny. W jego interfejsie dwie strony to user_a, który dostarcza mint_a, oraz user_b, który dostarcza mint_b. README i wygenerowane klienty nazywają mint_a nogą aktywa, a mint_b nogą gotówkową, i te strony stosują tę konwencję, ale nic w programie nie wymaga, aby noga gotówkowa była instrumentem gotówkowym. Dwa aktywa lub dwa stablecoiny rozlicza się w ten sam sposób.

Identyfikator programu

dvp34bdbcEm4f4FCUjGV4mDAkDshaQR4LkK8fdcsyZq

Program można aktualizować na obu klastrach. Powyższe wartości to to, co solana program show zwróciło 2 października 2026; uruchom to samo polecenie, aby sprawdzić aktualne dane. Build na devnecie jest starszy niż commit, względem którego pisane są kolejne strony (zob. Instalacja), ale ma ten sam zestaw instrukcji i błędów.

Cykl życia

Wymiana jest otwarta od CreateDvp, dopóki jedna z instrukcji Settle, Cancel lub Reject jej nie zamknie. Finansowanie nie ma własnej instrukcji: noga jest sfinansowana, gdy jej konto escrow zawiera co najmniej uzgodnioną kwotę. Reclaim działa dla każdej nogi osobno i pozostawia wymianę otwartą, więc problem z jedną nogą nie zmusza drugiej strony do anulowania całej wymiany.

Stan

Każda wymiana ma jedno konto SwapDvp o rozmiarze 458 bajtów, należące do programu. Jego adres jest wyprowadzany z podmiotu rozliczającego, obu stron, obu mintów i nonce (seedy ["dvp", settlement_authority, user_a, user_b, mint_a, mint_b, nonce]). Kwoty i czasy są przechowywane wewnątrz konta i nie wpływają na adres, dlatego trzeba je odczytać, a nie zakładać. Małe konto-znacznik, nonce tombstone pod adresem ["nonce", swap_dvp], jest tworzone razem z wymianą i nigdy nie jest zamykane, więc każda kombinacja stron, mintów, podmiotu rozliczającego i nonce może być użyta tylko do jednej wymiany.

Lista pól pochodzi z IDL programu w commicie wskazanym w sekcji Utwórz wymianę.

Instrukcje

Każdy zwrot trafia do własnego associated token account strony dla mintu danej nogi, niezależnie od tego, kto sfinansował escrow.

Konta i argumenty każdej instrukcji opisano na stronie odpowiedniego kroku.

Błędy

Zdarzenia i indeksowanie

Program nie emituje żadnych zdarzeń onchain. Indekser lub system uzgadniający odczytuje stan konta SwapDvp oraz salda tokenów obu escrow i używa ref_string, aby powiązać wymianę z odpowiadającym jej zleceniem off-chain. Ponieważ rekord jest zamykany przy rozliczeniu, system, który potrzebuje warunków po fakcie, zapisuje je w chwili ich odczytu albo odtwarza z transakcji, która utworzyła wymianę.

Obsługiwane tokeny

Wymiana może łączyć nogę SPL Token z nogą Token-2022; każda noga ma własny token program. Nogi Wrapped SOL są obsługiwane.

Opłata transferowa pozostawiłaby stronę odbierającą z kwotą niższą od uzgodnionej. Interest Bearing i Scaled UI Amount nie zmieniają kwot surowych, ale ich stopa lub mnożnik mogą się zmienić między utworzeniem a rozliczeniem wymiany, co zmienia sposób wyświetlania uzgodnionych kwot. NonTransferable zablokowałoby obie nogi.

Akceptowane authority mogą przenosić, zamrażać lub wstrzymywać tokeny w escrow przez cały czas trwania wymiany (patrz niżej). Escrow nie może zostać skonfigurowany do odbierania poufnych transferów, więc kwoty w escrow i rozliczone na nodze confidential są publiczne.

W przypadku mint z hookiem klient ustala dodatkowe konta hooka i dołącza je do instrukcji Settle, Cancel, Reject, Reclaim i Recover. Limit 32 na nogę obejmuje program hooka i jego konto walidacyjne. Jeśli hook authority zwiększy listę kont hooka ponad ten limit, każdy transfer na tej nodze zakończy się niepowodzeniem, w tym Reclaim, Cancel, Reject i Recover, dopóki authority nie cofnie zmiany. Limit kont w transakcji może zadziałać wcześniej niż limit na nogę, gdy obie nogi mają hooki.

Gdy konto docelowe lub konto zwrotu wymaga memo, program wywołuje program Memo przed transferem, dlatego każda instrukcja, która przenosi tokeny z escrow, przyjmuje konto memo_program.

Ograniczenia konfiguracji mint

Scaled UI Amount. Szablon tokenized-security w Mosaic, zestawie narzędzi do emisji od Solana Foundation, zawsze dodaje Scaled UI Amount, więc program nie akceptuje mint utworzonego z tego szablonu jako nogi. Mint przeznaczony dla tego programu można utworzyć bez tego rozszerzenia (zobacz Token Extensions); DvP z użyciem delegowania rozlicza się przez delegowane uprawnienia i nie stosuje tej kontroli.

Mint domyślnie zamrożone. Escrow każdej wymiany to associated token account należące do program-derived address, który jest nowy dla danej wymiany. W przypadku mint z Default Account State ustawionym na frozen escrow jest tworzony jako zamrożony, a transfer finansujący na to konto kończy się błędem, dopóki nie zostanie odmrożone. W ramach Token ACL oznacza to, że emitent lub jego agent transferowy dopuszcza escrow wymiany przed sfinansowaniem: albo dodając adres rekordu wymiany (właściciela escrow) do allowlisty, tak aby każdy mógł odmrozić escrow, jeśli konfiguracja Token ACL dla mint włącza odmrażanie bez uprawnień, albo przez bezpośrednie odmrożenie przez freeze authority. Zamrożone escrow blokuje też Settle, Reclaim, Cancel, Reject i Recover na tej nodze, więc freeze authority, a w przypadku mint z hookiem hook authority, jest zaufaną stroną przez cały czas trwania wymiany. Ścieżka zamrożonego escrow jest opisana tutaj i nie jest wykorzystywana w fragmentach kodu dla devnetu.

Ograniczenia

• Brak dopasowywania zleceń, ustalania cen i arkusza zleceń. Strony uzgadniają warunki poza księgą, a jedna z nich je rejestruje.
• Brak kompensowania (nettingu) i tylko wymiany dwustronne: jeden rekord to jedna wymiana między dwiema stronami.
• Brak częściowych realizacji. Settle przenosi dokładnie uzgodnioną kwotę każdej nogi i zwraca ewentualną nadwyżkę stronie danej nogi.
• Brak nogi poza księgą. Obie nogi to token accounts w Solanie; noga gotówkowa w istniejących systemach rozliczana jest oddzielnie i uzgadniana.
• Brak kontroli uprawnień, allowlisty ani KYC. Uprawnienie posiadaczy egzekwują mechanizmy kontrolne samego mint.
• Brak automatycznego rozliczenia. Settlement authority musi podpisać.
• Brak zdarzeń i brak opłaty protokołowej poza opłatami transakcyjnymi i rent.

Program eliminuje ryzyko kapitałowe między dwiema stronami: żadna noga nie jest przenoszona, chyba że obie są. Nie eliminuje ryzyka kredytowego emitenta ani ryzyka wykupu żadnego z tokenów, możliwości działania freeze, pause lub permanent delegate authority danego mint na tokenach w escrow (zobacz obsługiwane tokeny), ani zależności od dostępności settlement authority do podpisania.

Weryfikacja przed sfinansowaniem i rozliczeniem

CreateDvp nie wymaga uprawnień: podpisuje tylko płatnik, a strony i settlement authority nie. Każdy może więc utworzyć rekord wskazujący dowolne strony i dowolne warunki. Przed sfinansowaniem oraz ponownie przed rozliczeniem odczytaj konto SwapDvp i potwierdź, że:

1. Konto należy do programu DvP i ma dokładnie 458 bajtów. Konto, które nie należy do programu, może zostać wypełnione bajtami dekodującymi się jak prawdziwy rekord.
2. user_a, user_b, mint_a, mint_b i settlement_authority odpowiadają uzgodnionej wymianie.
3. amount_a, amount_b, expiry_timestamp i earliest_settlement_timestamp odpowiadają uzgodnionym warunkom.
4. Oba miejsca docelowe rozliczenia to uzgodnione adresy. Sfałszowany rekord może przekierować środki.

Finansowanie nóg wymienia wygenerowane klienty z funkcjami odczytu z weryfikacją i pokazuje sprawdzenie w kodzie.

Uznaj wymianę za rozliczoną, gdy transakcja Settle osiągnie finalized. Jest to poziom potwierdzenia sieciowego; to, czy oznacza on także ostateczność rozliczenia w sensie prawnym, zależy od umów stron i obowiązujących regulacji.

Wersjonowanie

Konto SwapDvp nie zawiera pola wersji. Jego układ jest stały i wynosi 458 bajtów (SwapDvp::LEN), a funkcje odczytu z weryfikacją odrzucają konto o jakiejkolwiek innej długości. IDL ma własną wersję: 0.1.0 na dzień 2 października 2026.

Program można aktualizować w obu klastrach (zobacz Program ID). Rekord wymiany istnieje tylko do momentu rozliczenia, anulowania lub odrzucenia, więc sprawdź w repozytorium, jak aktualizacja traktuje otwarte wymiany, i wygeneruj klienty ponownie z IDL wdrożonej wersji.

Repozytorium i audyt

Kod źródłowy, IDL, wygenerowane klienty i testy znajdują się w solana-foundation/dvp na licencji MIT. Program jest programem Pinocchio no_std; klienty są generowane z IDL za pomocą Codama. Zgłoszenia podatności należy przesyłać przez link do security advisory repozytorium, zgodnie z SECURITY.md.

Program został zaudytowany przez Cantina.

Powiązane

• Delivery vs Payment (DvP) z użyciem delegowania: wzorzec delegowania bez programu
• Token ACL: jak mint z kontrolą dostępu współdziała z kontami escrow