Einen Trade rückabwickeln

Vier Anweisungen geben Mittel zurück, ohne abzuwickeln: Reclaim, Cancel und Reject, solange der Trade offen ist, und Recover für eine Einzahlung, die nach dem Schließen eintrifft. Keine davon prüft den Ablauf. Ein eingefrorenes Escrow oder ein geänderter Mint kann ein Leg weiterhin blockieren, wie die Hinweise am Ende beschreiben.

In jedem Fall wird das Escrow vollständig an die Partei des Legs entleert: Escrow A an das token account von user_a für mint_a, Escrow B an das von user_b für mint_b, unabhängig davon, wer es finanziert hat. Das program account des Memo-Programms wird für Konten für die Rückerstattung angegeben, die ein Memo erfordern.

Diese Seite setzt die vorherigen Schritte fort: Der Client und die Signer aus Trade erstellen, userAAtaA und userBAtaB aus Legs finanzieren sowie MEMO_PROGRAM_ID und authority aus Trade abwickeln werden übernommen.

Ein Leg zurückholen

Reclaim gibt das Leg des Signers zurück und lässt den Trade offen, sodass das Leg erneut finanziert werden kann. Verwende es, wenn das Problem beim Leg der Gegenpartei liegt; Cancel und Reject schließen den gesamten Trade.

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 oder Reject

Cancel wird von der Settlement-Authority signiert, Reject von einer der beiden Parteien. Beide erstatten zurück, was jedes Escrow hält, an die Partei des Legs und schließen den Datensatz sowie beide Escrows; die rent der geschlossenen Konten geht an den Signer. Die beiden Anweisungen verwenden dieselben Konten; nur der Signer unterscheidet sich.

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,
});

Die Konten für die Rückerstattung (userAAtaA, userBAtaB) müssen für jedes Leg existieren, das ein Guthaben hält; nicht initialisierte Konten für die Rückerstattung lassen die Token-Überweisung fehlschlagen und setzen die Anweisung zurück. Ein Leg, das nie finanziert wurde, braucht keine Überweisung und toleriert fehlende Konten.

Eine verspätete Einzahlung wiederherstellen

Settle, Cancel und Reject schließen beide Escrow-token accounts, sodass eine einfache Überweisung an ein geschlossenes Escrow fehlschlägt. Eine Einzahlung landet nach dem Schließen nur dann, wenn zuvor etwas das Escrow neu erstellt, zum Beispiel eine Finanzierungstransaktion, die vor der Überweisung eine create-idempotent-Anweisung für ein associated token account enthält und noch in Bearbeitung war, als die Gegenpartei Reject gesendet hat. Die Token liegen dann in einem Escrow, dessen Trade nicht mehr existiert: Der Datensatz ist verschwunden, daher kann Reclaim ihn nicht finden, und der Nonce-Tombstone verhindert, dass an derselben Adresse ein neuer Trade erstellt wird und die Einzahlung abfängt.

Um RecoverDvp zu verwenden, übergibt die Partei des Legs die ursprünglichen seed-Eingaben (Settlement-Authority, beide Parteien, beide Mints, Nonce). Das Programm leitet die Datensatzadresse erneut ab, verlangt deren Tombstone als Nachweis, dass der Trade existierte, entleert das Escrow an das eigene token account des Signers und schließt es, wobei die Escrow-rent an den Signer zurückgeht. Das Leg des Signers wird dadurch bestimmt, welche Partei signiert: mint_a für user_a, mint_b für 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]);

Die Wiederherstellung hängt davon ab, dass die Partei die Erstellungsparameter aufbewahrt. Ein System, das Trades finanziert, speichert die seed-Eingaben zu jeder Order, bis der Trade geschlossen und bestätigt wurde, dass die Escrow-Salden leer sind.

Hinweise

• Eingefrorene Legs. Bei einem gesperrten (gated) Mint blockiert ein eingefrorenes Escrow die Token-Überweisung, die diese Anweisungen ausführen, bis die Freeze Authority es wieder freigibt. Siehe die Übersicht.
• Mint-Änderungen nach der Erstellung. Die Unwind-Pfade überspringen die Prüfungen von Extensions und Mint Authority, damit die eigenen Prüfungen des Programms eine Wiederherstellung nicht blockieren. Die eigenen Regeln des Token Program gelten weiterhin. Ein Mint kann nur bei einem Supply von null geschlossen werden und kann sich daher nicht ändern, solange ein Guthaben im Escrow liegt; ein Mint, der geschlossen und als NonTransferable oder mit einer Transfergebühr neu erstellt wird, bevor eine verspätete Einzahlung eintrifft, kann diese Einzahlung jedoch unbewegbar machen oder mit Gebühren belegen. Das ist die Abhängigkeit von der Mint Authority, die unter unterstützte Token aufgeführt ist.

Nächste Schritte

• DvP-Programm: die Übersicht, die unterstützten Token und die Einschränkungen der Mint-Konfiguration
• Delivery vs Payment (DvP) mit Delegation: derselbe Austausch über delegierte Berechtigung, ohne Programm