Een trade ongedaan maken

Vier instructies geven fondsen terug zonder af te wikkelen: Reclaim, Cancel en Reject zolang de trade open is, en Recover voor een storting die binnenkomt nadat de trade is gesloten. Geen van deze instructies controleert de vervaldatum. Een bevroren escrow of een gewijzigde mint kan nog steeds een leg vasthouden, zoals de notities aan het einde beschrijven.

In elk geval wordt de escrow geleegd, en wat deze bevat gaat naar de partij van de leg: escrow A naar het token account van user_a voor mint_a, escrow B naar dat van user_b voor mint_b, ongeacht wie het heeft gefinancierd. Het memo program account wordt meegegeven voor terugbetalingsaccounts die een memo vereisen.

Deze pagina vervolgt de eerdere stappen: de client en ondertekenaars uit een trade aanmaken, userAAtaA en userBAtaB uit de legs financieren, en MEMO_PROGRAM_ID en authority uit de trade afwikkelen worden overgenomen.

Een leg terugvorderen

Reclaim geeft de leg van de ondertekenaar terug en laat de trade open, zodat de leg opnieuw kan worden gefinancierd. Gebruik dit wanneer het probleem bij de leg van de tegenpartij ligt; Cancel en Reject sluiten de hele 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]);

Annuleren of afwijzen

Cancel wordt ondertekend door de afwikkelingsautoriteit en Reject door een van beide partijen. Beide betalen terug wat elke escrow bevat aan de partij van de leg en sluiten het record en beide escrows, waarbij de rent van de gesloten accounts naar de ondertekenaar gaat. De twee instructies gebruiken dezelfde accounts; alleen de ondertekenaar verschilt.

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

De terugbetalingsaccounts (userAAtaA, userBAtaB) moeten bestaan voor elke leg met een saldo; een niet-geïnitialiseerd terugbetalingsaccount laat de tokenoverdracht mislukken en maakt de instructie ongedaan. Een leg die nooit is gefinancierd heeft geen overdracht nodig en verdraagt een ontbrekend account.

Een late storting terughalen

Settle, Cancel en Reject sluiten allemaal beide escrow token accounts, dus een gewone overdracht naar een gesloten escrow mislukt. Een storting komt alleen na het sluiten binnen als iets eerst de escrow opnieuw aanmaakt, bijvoorbeeld een financieringstransactie die een create-idempotent associated token account-instructie vóór de overdracht bevat en onderweg was toen de tegenpartij Reject verstuurde. De tokens staan dan in een escrow waarvan de trade niet meer bestaat: het record is verdwenen, dus Reclaim kan het niet vinden, en de nonce-tombstone voorkomt dat een nieuwe trade op dranzelfde adres wordt aangemaakt en de storting overneemt.

Om RecoverDvp te gebruiken, levert de partij van de leg de oorspronkelijke seed-invoer (afwikkelingsautoriteit, beide partijen, beide mints, nonce). Het programma leidt het recordadres opnieuw af, vereist de tombstone als bewijs dat de trade bestond, leegt de escrow naar het eigen token account van de ondertekenaar en sluit deze, waarbij de escrow-rent naar de ondertekenaar terugkeert. De leg van de ondertekenaar wordt bepaald door welke partij ondertekent: mint_a voor user_a, mint_b voor 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]);

Herstel hangt ervan af dat de partij de aanmaakparameters bewaart. Een systeem dat trades financiert, slaat de seed-invoer bij elke order op totdat de trade is gesloten en de escrowsaldi als leeg zijn bevestigd.

Notities

• Bevroren legs. Bij een gated mint blokkeert een bevroren escrow de tokenoverdracht die deze instructies uitvoeren totdat de freeze authority deze ontdooit. Zie het overzicht.
• Mintwijzigingen na aanmaak. De ongedaanmakingspaden slaan de extensie- en mint-authority-controles over, zodat de eigen controles van het programma een herstel niet blokkeren. De eigen regels van het token program blijven gelden. Een mint kan alleen worden gesloten bij nul supply, dus deze kan niet veranderen zolang er een saldo in escrow staat, maar een mint die is gesloten en opnieuw aangemaakt als NonTransferable of met een transactiekost voordat een late storting binnenkomt, kan die storting onverplaatsbaar maken of kosten laten dragen. Dat is de mint-authority-afhankelijkheid die wordt vermeld onder ondersteunde tokens.

Volgende stappen

• DvP-programma: het overzicht, de ondersteunde tokens en de configuratiebeperkingen van de mint
• Delivery vs Payment (DvP) via delegatie: dezelfde uitwisseling via gedelegeerde autoriteit, zonder programma