Einen Trade rückabwickeln

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

In jedem Fall wird das Escrow mit allem, was es enthält, an die Partei des Legs geleert: 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 Memo-program account wird für Rückerstattungskonten angegeben, die ein Memo erfordern.

Diese Seite setzt die vorherigen Schritte fort: Der Client und die Signer aus Einen Trade erstellen, userAAtaA und userBAtaB aus Die Legs finanzieren sowie MEMO_PROGRAM_ID und authority aus Den 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. Verwenden Sie 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 alles, was das jeweilige Escrow enthält, an die Partei des Legs zurück 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 Rückerstattungskonten (userAAtaA, userBAtaB) müssen für jedes Leg existieren, das ein Guthaben hält; ein nicht initialisiertes Rückerstattungskonto lässt die Token-Überweisung fehlschlagen und setzt die Anweisung zurück. Ein Leg, das nie finanziert wurde, benötigt keine Überweisung und toleriert ein fehlendes Konto.

Eine verspätete Einzahlung wiederherstellen

Settle, Cancel und Reject schließen beide Escrow-token accounts, daher schlägt eine einfache Überweisung an ein geschlossenes Escrow fehl. 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 idempotente Anweisung zum Erstellen eines associated token account enthält und noch unterwegs war, als die Gegenpartei Reject gesendet hat. Die Tokens liegen dann in einem Escrow, dessen Trade nicht mehr existiert: Der Datensatz ist weg, sodass Reclaim ihn nicht finden kann, und der Nonce-Tombstone verhindert, dass ein neuer Trade an derselben Adresse erstellt wird und die Einzahlung abgreift.

Um RecoverDvp zu verwenden, übermittelt die Partei des Legs die ursprünglichen seed-Eingaben (Settlement Authority, beide Parteien, beide Mints, Nonce). Das Programm leitet die Adresse des Datensatzes erneut ab, verlangt dessen Tombstone als Nachweis, dass der Trade existiert hat, leert 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 wurde und die Escrow-Guthaben als leer bestätigt wurden.

Hinweise

• Eingefrorene Legs. Bei einem Mint mit Zugriffsbeschränkung 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 Rückabwicklungspfade ü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, sodass er sich nicht ändern kann, solange ein Guthaben im Escrow liegt. Ein Mint, der jedoch geschlossen und als NonTransferable oder mit einer Transfergebühr neu erstellt wird, bevor eine verspätete Einzahlung eintrifft, kann diese Einzahlung unbeweglich machen oder mit Gebühren belegen. Das ist die Abhängigkeit von der Mint Authority, die unter unterstützte Tokens aufgeführt ist.

Nächste Schritte

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