Αναίρεση μιας ανταλλαγής

Τέσσερις εντολές επιστρέφουν κεφάλαια χωρίς διακανονισμό: οι Reclaim, Cancel και Reject όσο η ανταλλαγή είναι ανοιχτή και η Recover για μια κατάθεση που φτάνει αφού η ανταλλαγή έχει κλείσει. Καμία από αυτές δεν ελέγχει τη λήξη. Ένας παγωμένος escrow ή ένα mint που έχει αλλάξει μπορεί και πάλι να δεσμεύει ένα σκέλος, όπως περιγράφουν οι σημειώσεις στο τέλος.

Σε κάθε περίπτωση, ο escrow αδειάζει ό,τι περιέχει προς τον συμμετέχοντα του σκέλους: ο escrow A στον token account του user_a για το mint_a, ο escrow B στον token account του user_b για το mint_b, ανεξάρτητα από το ποιος τον χρηματοδότησε. Το memo program account παρέχεται για λογαριασμούς επιστροφής που απαιτούν memo.

Αυτή η σελίδα συνεχίζει από τα προηγούμενα βήματα: ο client και οι υπογράφοντες από την δημιουργία μιας ανταλλαγής, τα userAAtaA και userBAtaB από τη χρηματοδότηση των σκελών, και τα MEMO_PROGRAM_ID και authority από τον διακανονισμό της ανταλλαγής μεταφέρονται εδώ.

Ανάκτηση ενός σκέλους

Η Reclaim επιστρέφει το σκέλος του υπογράφοντος και αφήνει την ανταλλαγή ανοιχτή, ώστε το σκέλος να μπορεί να χρηματοδοτηθεί ξανά. Χρησιμοποιήστε την όταν το πρόβλημα βρίσκεται στο σκέλος του αντισυμβαλλομένου· οι Cancel και Reject κλείνουν ολόκληρη την ανταλλαγή.

import { MEMO_PROGRAM_ADDRESS } from "@solana-program/memo";
import { getReclaimDvpInstruction } from "./dvp";

// The asset-leg party takes its asset back.
const reclaimInstruction = getReclaimDvpInstruction({
  signer: userASigner,
  swapDvp,
  mint: mintA,
  dvpSourceAta: escrowA,
  signerDestAta: userAAtaA,
  tokenProgram: tokenProgramA,
  memoProgram: MEMO_PROGRAM_ADDRESS,
});

await client.sendTransaction([reclaimInstruction]);

Ακύρωση ή απόρριψη

Η Cancel υπογράφεται από την αρχή διακανονισμού και η Reject από οποιοδήποτε μέρος. Και οι δύο επιστρέφουν ό,τι περιέχει κάθε escrow στον συμμετέχοντα του σκέλους και κλείνουν την εγγραφή και τους δύο escrow, με το rent των κλειστών λογαριασμών να πηγαίνει στον υπογράφοντα. Οι δύο εντολές δέχονται τους ίδιους λογαριασμούς· διαφέρει μόνο ο υπογράφων.

import { getCancelDvpInstruction, getRejectDvpInstruction } from "./dvp";

const unwindAccounts = {
  swapDvp,
  mintA,
  mintB,
  dvpAtaA: escrowA,
  dvpAtaB: escrowB,
  userAAtaA,
  userBAtaB,
  tokenProgramA,
  tokenProgramB,
  memoProgram: MEMO_PROGRAM_ADDRESS,
  legAExtrasCount: 0,
};

// Signed by the settlement authority:
const cancelInstruction = getCancelDvpInstruction({
  settlementAuthority: authoritySigner,
  ...unwindAccounts,
});

// Or signed by either party:
const rejectInstruction = getRejectDvpInstruction({
  signer: userBSigner,
  ...unwindAccounts,
});

Οι λογαριασμοί επιστροφής (userAAtaA, userBAtaB) πρέπει να υπάρχουν για κάθε σκέλος που διαθέτει υπόλοιπο· ένας μη αρχικοποιημένος λογαριασμός επιστροφής προκαλεί αποτυχία της μεταφοράς token και αναιρεί την εντολή. Ένα σκέλος που δεν χρηματοδοτήθηκε ποτέ δεν χρειάζεται μεταφορά και ανέχεται έναν λογαριασμό που λείπει.

Ανάκτηση μιας καθυστερημένης κατάθεσης

Οι Settle, Cancel και Reject κλείνουν και τους δύο token account των escrow, επομένως μια απλή μεταφορά σε έναν κλειστό escrow αποτυγχάνει. Μια κατάθεση φτάνει μετά το κλείσιμο μόνο αν κάτι δημιουργήσει ξανά τον escrow πρώτα, για παράδειγμα μια συναλλαγή χρηματοδότησης που περιλαμβάνει μια εντολή create-idempotent associated token account πριν από τη μεταφορά και βρισκόταν σε εξέλιξη όταν ο αντισυμβαλλόμενος έστειλε Reject. Τα tokens βρίσκονται τότε σε έναν escrow του οποίου η ανταλλαγή δεν υπάρχει πια: η εγγραφή έχει διαγραφεί, οπότε η Reclaim δεν μπορεί να τη βρει, και το tombstone του nonce εμποδίζει τη δημιουργία νέας ανταλλαγής στην ίδια διεύθυνση, ώστε να μην παγιδευτεί η κατάθεση.

Για να χρησιμοποιήσει την RecoverDvp, ο συμμετέχων του σκέλους παρέχει τα αρχικά δεδομένα seed (αρχή διακανονισμού, και τα δύο μέρη, και τα δύο mints, nonce). Το πρόγραμμα υπολογίζει εκ νέου τη διεύθυνση της εγγραφής, απαιτεί το tombstone της ως απόδειξη ότι η ανταλλαγή υπήρξε, αδειάζει τον escrow στον δικό του token account του υπογράφοντος και τον κλείνει, επιστρέφοντας το rent του escrow στον υπογράφοντα. Το σκέλος του υπογράφοντος καθορίζεται από το ποιο μέρος υπογράφει: το mint_a για τον user_a, το mint_b για τον user_b.

import { getAddressEncoder, getProgramDerivedAddress } from "@solana/kit";
import { DVP_SWAP_PROGRAM_PROGRAM_ADDRESS, getRecoverDvpInstruction } from "./dvp";

const [nonceTombstone] = await getProgramDerivedAddress({
  programAddress: DVP_SWAP_PROGRAM_PROGRAM_ADDRESS,
  seeds: ["nonce", getAddressEncoder().encode(swapDvp)],
});

const recoverInstruction = getRecoverDvpInstruction({
  signer: userASigner,
  swapDvp,
  nonceTombstone,
  mint: mintA,
  dvpEscrowAta: escrowA,
  signerDestAta: userAAtaA,
  tokenProgram: tokenProgramA,
  memoProgram: MEMO_PROGRAM_ADDRESS,
  settlementAuthority,
  userA,
  userB,
  mintA,
  mintB,
  nonce,
});

await client.sendTransaction([recoverInstruction]);

Η ανάκτηση εξαρτάται από το αν το μέρος διατηρεί τις παραμέτρους δημιουργίας. Ένα σύστημα που χρηματοδοτεί ανταλλαγές αποθηκεύει τα δεδομένα seed με κάθε εντολή μέχρι να κλείσει η ανταλλαγή και να επιβεβαιωθεί ότι τα υπόλοιπα των escrow είναι κενά.

Σημειώσεις

• Παγωμένα σκέλη. Σε ένα mint με περιορισμούς, ένας παγωμένος escrow μπλοκάρει τη μεταφορά token που εκτελούν αυτές οι εντολές μέχρι να τον ξεπαγώσει η αρχή πάγωματος. Δείτε την επισκόπηση.
• Αλλαγές του mint μετά τη δημιουργία. Οι διαδρομές αναίρεσης παραλείπουν τους ελέγχους επεκτάσεων και mint authority, ώστε οι έλεγχοι του ίδιου του προγράμματος να μην εμποδίζουν μια ανάκτηση. Οι κανόνες του ίδιου του token program εξακολουθούν να ισχύουν. Ένα mint μπορεί να κλείσει μόνο με μηδενικό 供应, επομένως δεν μπορεί να αλλάξει ενώ υπάρχει υπόλοιπο στον escrow, αλλά ένα mint που έχει κλείσει και δημιουργηθεί ξανά ως NonTransferable ή με προμήθεια μεταφοράς πριν φτάσει μια καθυστερημένη κατάθεση μπορεί να κάνει την κατάθεση αυτή αδύνατο να μεταφερθεί ή να επιβαρύνεται με προμήθεια. Αυτή είναι η εξάρτηση από το mint authority που αναφέρεται στα υποστηριζόμενα tokens.

Επόμενα βήματα

• Πρόγραμμα DvP: η επισκόπηση, τα υποστηριζόμενα tokens και οι περιορισμοί διαμόρφωσης του mint
• Delivery vs Payment (DvP) με χρήση delegation: η ίδια ανταλλαγή μέσω εξουσιοδοτημένης αρχής, χωρίς πρόγραμμα