Πρόγραμμα Delivery vs Payment (DvP)

Το πρόγραμμα DvP είναι το τυπικό πρόγραμμα για παράδοση έναντι πληρωμής (delivery versus payment) στο Solana, συντηρείται από το Solana Foundation και έχει ελεγχθεί από την Cantina. Δύο μέρη συμφωνούν σε μια ανταλλαγή, το καθένα στέλνει το σκέλος του σε έναν λογαριασμό escrow με μια συνηθισμένη μεταφορά token, και μια αρχή διακανονισμού διακανονίζει και τα δύο σκέλη σε μία συναλλαγή, ώστε ή να μετακινηθούν και τα δύο ή να μην μετακινηθεί κανένα. Η αρχή διακανονισμού είναι μια τρίτη διεύθυνση που ορίζεται στην ανταλλαγή, όπως ο χώρος διαπραγμάτευσης ή ο πράκτορας που την οργάνωσε. Κανένα από τα μέρη δεν γράφει ούτε αναπτύσσει πρόγραμμα, και ένα πορτοφόλι ή ένας θεματοφύλακας που μπορεί να στείλει μια τυπική μεταφορά token (TransferChecked) μπορεί να χρηματοδοτήσει ένα σκέλος χωρίς καμία ενσωμάτωση ειδική για το DvP. Μέχρι τον διακανονισμό, κάθε μέρος μπορεί να πάρει πίσω το δικό του σκέλος ή να αναιρέσει την ανταλλαγή.

Πώς λειτουργεί

Κάθε ανταλλαγή αποκτά μια εγγραφή που ανήκει στο πρόγραμμα και δύο λογαριασμούς escrow, έναν για κάθε σκέλος. Το μέρος του σκέλους περιουσιακού στοιχείου (user_a) και το μέρος του σκέλους μετρητών (user_b) χρηματοδοτούν το καθένα ένα σκέλος μεταφέροντας token στον λογαριασμό escrow του συγκεκριμένου σκέλους. Η αρχή διακανονισμού είναι ο μόνος υπογράφων που μπορεί να διακανονίσει. Ο διακανονισμός μεταφέρει το συμφωνημένο ποσό κάθε σκέλους στην άλλη πλευρά, επιστρέφει τυχόν πλεόνασμα στο μέρος στο οποίο ανήκει το σκέλος, και κλείνει την εγγραφή και τους δύο λογαριασμούς escrow. Η ατομικότητα προκύπτει από τις συναλλαγές του Solana: και οι δύο μεταφορές βρίσκονται σε μία συναλλαγή, οπότε ή ισχύουν και οι δύο ή καμία.

Κάθε επιστροφή χρημάτων, ανάκτηση και επιστροφή πλεονάσματος πηγαίνει στον δικό του associated token account του μέρους: στον λογαριασμό του user_a για το mint_a, του user_b για το mint_b. Ένα σύστημα θεματοφύλακα ή ταμείου μπορεί να χρηματοδοτήσει ένα σκέλος από τον δικό του λογαριασμό, αλλά ό,τι επιστρέφεται καταλήγει στον λογαριασμό του μέρους και όχι πίσω στον θεματοφύλακα. Κάθε ανταλλαγή αφήνει επίσης έναν μόνιμο λογαριασμό-δείκτη (δείτε Κατάσταση).

Οδηγοί

Οι σελίδες βημάτων οδηγούν μια ανταλλαγή από τη δημιουργία έως τον διακανονισμό, με TypeScript και Rust για κάθε εντολή.

Ένα demo στο devnet εκτελεί μια ανταλλαγή από άκρη σε άκρη: δημιουργεί την ανταλλαγή, χρηματοδοτεί και τους δύο λογαριασμούς escrow με τυπικές μεταφορές token και διακανονίζει και τα δύο σκέλη σε μία συναλλαγή.

Επιλογή ανάμεσα στο πρόγραμμα και την ανάθεση

Το Delivery vs Payment (DvP) με χρήση ανάθεσης διακανονίζει την ίδια ανταλλαγή χωρίς πρόγραμμα: κάθε πλευρά αναθέτει τη θέση της σε έναν πράκτορα διακανονισμού, ο οποίος μετακινεί και τα δύο σκέλη σε μία συναλλαγή.

• Το πρόγραμμα δεν απαιτεί ανάθεση, επομένως το όριο ενός εξουσιοδοτημένου ανά token account δεν ισχύει, και η αρχή διακανονισμού δεν μπορεί να ανακατευθύνει τα έσοδα. Κάθε ανταλλαγή εξαρτάται από ένα αναβαθμίσιμο πρόγραμμα και την αρχή αναβάθμισής του.
• Το μοτίβο ανάθεσης δεν έχει εξάρτηση από πρόγραμμα και λειτουργεί με mint που φέρουν Scaled UI Amount. Το πρόγραμμα απορρίπτει αυτά τα mint, γεγονός που αποκλείει κάθε mint που δημιουργείται από το πρότυπο tokenized-security του Mosaic (δείτε περιορισμούς διαμόρφωσης του mint).

Ρόλοι

Το πρόγραμμα είναι συμμετρικό. Στη διεπαφή του τα δύο μέρη είναι ο user_a, που παραδίδει το mint_a, και ο user_b, που παραδίδει το mint_b. Το README και οι δημιουργημένοι clients αποκαλούν το mint_a σκέλος περιουσιακού στοιχείου και το mint_b σκέλος μετρητών, και αυτές οι σελίδες ακολουθούν τη σύμβαση αυτή, αλλά τίποτα στο πρόγραμμα δεν απαιτεί το σκέλος μετρητών να είναι μέσο μετρητών. Δύο περιουσιακά στοιχεία ή δύο stablecoin διακανονίζονται με τον ίδιο τρόπο.

ID προγράμματος

dvp34bdbcEm4f4FCUjGV4mDAkDshaQR4LkK8fdcsyZq

Το πρόγραμμα είναι αναβαθμίσιμο και στα δύο cluster. Οι τιμές παραπάνω είναι αυτές που ανέφερε το solana program show στις 2 Οκτωβρίου 2026· εκτελέστε την ίδια εντολή για τις τρέχουσες τιμές. Η έκδοση στο devnet είναι παλαιότερη από το commit με βάση το οποίο έχουν γραφτεί οι σελίδες βημάτων (δείτε Εγκατάσταση), με το ίδιο σύνολο εντολών και σφαλμάτων.

Κύκλος ζωής

Μια ανταλλαγή είναι ανοιχτή από το CreateDvp μέχρι να την κλείσει μία από τις εντολές Settle, Cancel ή Reject. Η χρηματοδότηση δεν έχει δική της εντολή: ένα σκέλος χρηματοδοτείται όταν ο λογαριασμός escrow του κρατά τουλάχιστον το συμφωνημένο ποσό. Το Reclaim γίνεται ανά σκέλος και αφήνει την ανταλλαγή ανοιχτή, ώστε ένα πρόβλημα με το ένα σκέλος να μην αναγκάζει το άλλο μέρος να ακυρώσει όλη την ανταλλαγή.

Κατάσταση

Κάθε ανταλλαγή έχει έναν λογαριασμό SwapDvp 458 byte, που ανήκει στο πρόγραμμα. Η διεύθυνσή του προκύπτει από την αρχή διακανονισμού, τα δύο μέρη, τα δύο mint και ένα nonce (τα seed ["dvp", settlement_authority, user_a, user_b, mint_a, mint_b, nonce]). Τα ποσά και οι χρόνοι αποθηκεύονται μέσα στον λογαριασμό και δεν επηρεάζουν τη διεύθυνση, γι' αυτό πρέπει να διαβάζονται και όχι να συνάγονται. Ένας μικρός λογαριασμός-δείκτης, το nonce tombstone στο ["nonce", swap_dvp], δημιουργείται μαζί με την ανταλλαγή και δεν κλείνει ποτέ, ώστε κάθε συνδυασμός μερών, mint, αρχής και nonce να μπορεί να χρησιμοποιηθεί για μία μόνο ανταλλαγή.

Η λίστα πεδίων προέρχεται από το IDL του προγράμματος στο commit που αναφέρεται στην ενότητα Δημιουργία ανταλλαγής.

Εντολές

Κάθε επιστροφή χρημάτων πηγαίνει στον δικό του associated token account του μέρους για το mint του συγκεκριμένου σκέλους, ανεξάρτητα από το ποιος χρηματοδότησε το escrow.

Οι λογαριασμοί και τα ορίσματα κάθε εντολής βρίσκονται στη σελίδα του αντίστοιχου βήματος.

Σφάλματα

Συμβάντα και ευρετηρίαση

Το πρόγραμμα δεν εκπέμπει onchain συμβάντα. Ένας indexer ή σύστημα συμφιλίωσης διαβάζει την κατάσταση του λογαριασμού SwapDvp και τα υπόλοιπα token των δύο escrow, και χρησιμοποιεί το ref_string για να αντιστοιχίσει μια ανταλλαγή με την εντολή της εκτός αλυσίδας. Επειδή η εγγραφή κλείνει κατά τον διακανονισμό, ένα σύστημα που χρειάζεται τους όρους εκ των υστέρων τους αποθηκεύει κατά την ανάγνωσή τους ή τους ανακατασκευάζει από τη συναλλαγή που δημιούργησε την ανταλλαγή.

Υποστηριζόμενα tokens

Μια ανταλλαγή μπορεί να συνδυάζει ένα σκέλος SPL Token με ένα σκέλος Token-2022· κάθε σκέλος φέρει το δικό του token program. Τα σκέλη Wrapped SOL υποστηρίζονται.

Μια προμήθεια μεταφοράς θα άφηνε την πλευρά που λαμβάνει με λιγότερα από το συμφωνηθέν ποσό. Τα Interest Bearing και Scaled UI Amount δεν αλλάζουν τα ακατέργαστα ποσά, αλλά το επιτόκιο ή ο πολλαπλασιαστής τους μπορεί να αλλάξει μεταξύ της δημιουργίας και του διακανονισμού μιας ανταλλαγής, γεγονός που αλλάζει τον τρόπο εμφάνισης των συμφωνηθέντων ποσών. Το NonTransferable θα εγκλώβιζε και τα δύο σκέλη.

Οι αποδεκτές authorities μπορούν να μετακινήσουν, να παγώσουν ή να σταματήσουν τα token σε escrow καθ' όλη τη διάρκεια της ανταλλαγής (βλ. παρακάτω). Το escrow δεν μπορεί να ρυθμιστεί ώστε να λαμβάνει εμπιστευτικές μεταφορές, επομένως τα ποσά σε escrow και τα ποσά διακανονισμού σε ένα εμπιστευτικό σκέλος είναι δημόσια.

Για ένα mint με hook, ο client επιλύει τους επιπλέον λογαριασμούς του hook και τους προσθέτει στα Settle, Cancel, Reject, Reclaim και Recover. Το όριο των 32 ανά σκέλος περιλαμβάνει το πρόγραμμα του hook και τον λογαριασμό επικύρωσής του. Αν η hook authority αυξήσει τη λίστα λογαριασμών του hook πέρα από αυτό το όριο, κάθε μεταφορά σε αυτό το σκέλος αποτυγχάνει, συμπεριλαμβανομένων των Reclaim, Cancel, Reject και Recover, μέχρι η authority να το αναιρέσει. Το όριο λογαριασμών της συναλλαγής μπορεί να ισχύσει πριν από το όριο ανά σκέλος όταν και τα δύο σκέλη έχουν hooks.

Όταν ένας λογαριασμός προορισμού ή επιστροφής απαιτεί memos, το πρόγραμμα καλεί το Memo program πριν από τη μεταφορά, γι' αυτό κάθε εντολή που μετακινεί token εκτός escrow δέχεται έναν λογαριασμό memo_program.

Περιορισμοί ρύθμισης του mint

Scaled UI Amount. Το πρότυπο tokenized-security στο Mosaic, το εργαλειοσύνολο έκδοσης του Solana Foundation, προσθέτει πάντα Scaled UI Amount, επομένως το πρόγραμμα δεν δέχεται mint που δημιουργήθηκε από αυτό το πρότυπο ως σκέλος. Ένα mint που προορίζεται για αυτό το πρόγραμμα μπορεί να δημιουργηθεί χωρίς την επέκταση (βλ. Token Extensions)· το DvP με χρήση delegation διακανονίζεται μέσω εξουσιοδοτημένης authority και δεν εφαρμόζει αυτόν τον έλεγχο.

Mints παγωμένα από προεπιλογή. Το escrow κάθε ανταλλαγής είναι ένας associated token account που ανήκει σε μια program-derived address η οποία είναι νέα για αυτή την ανταλλαγή. Σε ένα mint με Default Account State ορισμένο σε frozen, το escrow δημιουργείται παγωμένο και μια μεταφορά χρηματοδότησης προς αυτό αποτυγχάνει μέχρι να ξεπαγώσει. Υπό το Token ACL αυτό σημαίνει ότι ο εκδότης ή ο transfer agent του εγκρίνει το escrow της ανταλλαγής πριν από τη χρηματοδότηση: είτε προσθέτοντας τη διεύθυνση της εγγραφής ανταλλαγής (τον ιδιοκτήτη του escrow) στην allowlist, ώστε οποιοσδήποτε να μπορεί να ξεπαγώσει το escrow όταν η ρύθμιση Token ACL του mint ενεργοποιεί το permissionless thaw, είτε αφήνοντας τη freeze authority να το ξεπαγώσει απευθείας. Ένα παγωμένο escrow μπλοκάρει επίσης τα Settle, Reclaim, Cancel, Reject και Recover σε αυτό το σκέλος, επομένως η freeze authority, και σε ένα mint με hook η hook authority, είναι έμπιστο μέρος για τη διάρκεια της ανταλλαγής. Η διαδρομή του παγωμένου escrow περιγράφεται εδώ και δεν εκτελείται στα αποσπάσματα κώδικα devnet.

Περιορισμοί

• Χωρίς αντιστοίχιση, ανακάλυψη τιμής ή βιβλίο εντολών. Τα μέρη συμφωνούν τους όρους εκτός καθολικού και ένα από αυτά τους καταγράφει.
• Χωρίς συμψηφισμό (netting) και μόνο διμερής: μία εγγραφή είναι μία ανταλλαγή μεταξύ δύο μερών.
• Χωρίς μερική εκτέλεση. Το Settle μετακινεί ακριβώς το συμφωνηθέν ποσό κάθε σκέλους και επιστρέφει οποιοδήποτε πλεόνασμα στο μέρος του σκέλους.
• Χωρίς σκέλος εκτός καθολικού. Και τα δύο σκέλη είναι token accounts στο Solana· ένα σκέλος μετρητών σε υπάρχουσες υποδομές διακανονίζεται ξεχωριστά και συμφιλιώνεται.
• Χωρίς έλεγχο επιλεξιμότητας, allowlist ή KYC. Οι δικοί του έλεγχοι του mint επιβάλλουν την επιλεξιμότητα των κατόχων.
• Χωρίς αυτόματο διακανονισμό. Η settlement authority πρέπει να υπογράψει.
• Χωρίς συμβάντα και χωρίς προμήθεια πρωτοκόλλου πέρα από τα τέλη συναλλαγής και το rent.

Το πρόγραμμα εξαλείφει τον κίνδυνο κεφαλαίου μεταξύ των δύο μερών: κανένα σκέλος δεν μετακινείται εκτός αν μετακινηθούν και τα δύο. Δεν εξαλείφει τον πιστωτικό κίνδυνο του εκδότη ή τον κίνδυνο εξαγοράς σε κάποιο από τα token, τη δυνατότητα της freeze, pause ή permanent delegate authority ενός mint να ενεργήσει στα token σε escrow (βλ. υποστηριζόμενα tokens), ούτε την εξάρτηση από τη διαθεσιμότητα της settlement authority να υπογράψει.

Επαλήθευση πριν από τη χρηματοδότηση και τον διακανονισμό

Το CreateDvp δεν απαιτεί άδεια: υπογράφει μόνο ο payer, ενώ τα μέρη και η settlement authority όχι. Επομένως, οποιοσδήποτε μπορεί να δημιουργήσει εγγραφή με οποιαδήποτε μέρη και όρους. Πριν από τη χρηματοδότηση, και ξανά πριν από τον διακανονισμό, διαβάστε τον λογαριασμό SwapDvp και επιβεβαιώστε ότι:

1. Ο λογαριασμός ανήκει στο πρόγραμμα DvP και έχει ακριβώς 458 bytes. Ένας λογαριασμός που δεν ανήκει στο πρόγραμμα μπορεί να γεμιστεί με bytes που αποκωδικοποιούνται σαν πραγματική εγγραφή.
2. Τα user_a, user_b, mint_a, mint_b και settlement_authority ταιριάζουν με τη συμφωνημένη ανταλλαγή.
3. Τα amount_a, amount_b, expiry_timestamp και earliest_settlement_timestamp ταιριάζουν με τους συμφωνημένους όρους.
4. Και οι δύο προορισμοί διακανονισμού είναι οι συμφωνημένες διευθύνσεις. Μια πλαστή εγγραφή μπορεί να ανακατευθύνει τα έσοδα.

Η ενότητα Χρηματοδότηση των σκελών παραθέτει τους checked readers των παραγόμενων clients και δείχνει τον έλεγχο σε κώδικα.

Θεωρήστε μια ανταλλαγή διακανονισμένη όταν η συναλλαγή Settle φτάσει στο finalized. Αυτό είναι επίπεδο δέσμευσης του δικτύου· το αν επισημαίνει επίσης την οριστικότητα του διακανονισμού για νομικούς σκοπούς εξαρτάται από τις συμφωνίες των μερών και τα ισχύοντα καθεστώτα.

Διαχείριση εκδόσεων

Ο λογαριασμός SwapDvp δεν διαθέτει πεδίο έκδοσης. Η διάταξή του είναι σταθερή στα 458 bytes (SwapDvp::LEN) και οι checked readers απορρίπτουν λογαριασμό με οποιοδήποτε άλλο μήκος. Το IDL διαθέτει τη δική του έκδοση, 0.1.0 από τις 2 Οκτωβρίου 2026.

Το πρόγραμμα είναι αναβαθμίσιμο και στα δύο clusters (βλ. Program ID). Μια εγγραφή ανταλλαγής υπάρχει μόνο μέχρι να διακανονιστεί, ακυρωθεί ή απορριφθεί, γι' αυτό ελέγξτε στο repository πώς μια αναβάθμιση αντιμετωπίζει τις ανοιχτές ανταλλαγές, και δημιουργήστε ξανά τους clients από το IDL της αναπτυγμένης έκδοσης.

Repository και έλεγχος ασφαλείας

Ο πηγαίος κώδικας, το IDL, οι παραγόμενοι clients και τα τεστ βρίσκονται στο solana-foundation/dvp με την άδεια MIT. Το πρόγραμμα είναι ένα πρόγραμμα no_std Pinocchio· οι clients παράγονται από το IDL με το Codama. Οι αναφορές ευπαθειών γίνονται μέσω του συνδέσμου security advisory του repository, σύμφωνα με το SECURITY.md του.

Το πρόγραμμα έχει ελεγχθεί από την Cantina.

Σχετικά

• Delivery vs Payment (DvP) με χρήση delegation: το μοτίβο delegation χωρίς πρόγραμμα
• Token ACL: πώς ένα gated mint αλληλεπιδρά με τους λογαριασμούς escrow