Πρόγραμμα Παράδοσης έναντι Πληρωμής (DvP)

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

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

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

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

Οδηγοί

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

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

Επιλογή μεταξύ του προγράμματος και της ανάθεσης

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

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

Ρόλοι

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

Program ID

dvp34bdbcEm4f4FCUjGV4mDAkDshaQR4LkK8fdcsyZq

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

Κύκλος ζωής

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

Κατάσταση

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

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

Εντολές

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

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

Σφάλματα

Συμβάντα και indexing

Το πρόγραμμα δεν εκπέμπει onchain συμβάντα. Ένας indexer ή ένα σύστημα συμφωνίας (reconciliation) διαβάζει την κατάσταση του λογαριασμού SwapDvp και τα υπόλοιπα tokens των δύο escrows, και χρησιμοποιεί το ref_string για να αντιστοιχίσει μια ανταλλαγή με την off-chain εντολή της. Επειδή η εγγραφή κλείνει κατά τον διακανονισμό, ένα σύστημα που χρειάζεται τους όρους εκ των υστέρων τους αποθηκεύει όταν τους διαβάζει ή τους ανασυνθέτει από τη συναλλαγή που δημιούργησε την ανταλλαγή.

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

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

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

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

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

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

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

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

Περιορισμοί

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

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

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

Το CreateDvp είναι permissionless: υπογράφει μόνο ο 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. Και οι δύο προορισμοί διακανονισμού είναι οι συμφωνηθείσες διευθύνσεις. Μια πλαστή εγγραφή μπορεί να ανακατευθύνει τα έσοδα.

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

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

Εκδόσεις

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

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

Αποθετήριο και audit

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

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

Σχετικά

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