Program Delivery vs Payment (DvP)

Program DvP adalah program standar untuk delivery versus payment di Solana, dikelola oleh Solana Foundation dan diaudit oleh Cantina. Dua pihak menyepakati sebuah trade, masing-masing mengirim sisinya (leg) ke akun escrow melalui transfer token biasa, lalu otoritas penyelesaian menyelesaikan kedua sisi dalam satu transaksi, sehingga keduanya berpindah atau tidak sama sekali. Otoritas penyelesaian adalah alamat ketiga yang disebutkan dalam trade, seperti venue atau agen yang mengaturnya. Tidak ada pihak yang perlu menulis atau men-deploy program, dan wallet atau kustodian yang dapat mengirim transfer token standar (TransferChecked) dapat mendanai sebuah leg tanpa integrasi khusus DvP. Sebelum penyelesaian, masing-masing pihak dapat menarik kembali legnya sendiri atau membatalkan trade.

Cara kerjanya

Setiap trade mendapatkan satu catatan milik program dan dua akun escrow, satu per leg. Pihak asset-leg (user_a) dan pihak cash-leg (user_b) masing-masing mendanai satu leg dengan mentransfer token ke akun escrow untuk leg tersebut. Otoritas penyelesaian adalah satu-satunya penanda tangan yang dapat menyelesaikan. Penyelesaian mentransfer jumlah yang disepakati dari setiap leg ke pihak lawan, mengembalikan kelebihan apa pun kepada pihak yang memiliki leg tersebut, dan menutup catatan beserta kedua escrow. Sifat atomik berasal dari transaksi Solana: kedua transfer berada dalam satu transaksi, sehingga keduanya berlaku atau tidak sama sekali.

Setiap refund, penarikan kembali, dan pengembalian kelebihan masuk ke associated token account milik pihak tersebut: akun user_a untuk mint_a, akun user_b untuk mint_b. Sistem kustodian atau treasury dapat mendanai sebuah leg dari akunnya sendiri, tetapi apa pun yang dikembalikan masuk ke akun pihak tersebut, bukan kembali ke kustodian. Setiap trade juga meninggalkan akun penanda permanen (lihat State).

Panduan

Halaman langkah membahas satu trade dari pembuatan hingga penyelesaian, dengan TypeScript dan Rust untuk setiap instruksi.

Sebuah demo devnet menjalankan trade dari awal hingga akhir: membuat trade, mendanai kedua escrow dengan transfer token standar, dan menyelesaikan kedua leg dalam satu transaksi.

Memilih antara program dan delegasi

Delivery vs Payment (DvP) menggunakan delegasi menyelesaikan pertukaran yang sama tanpa program: masing-masing pihak mendelegasikan posisinya ke agen penyelesaian, yang memindahkan kedua leg dalam satu transaksi.

• Program tidak memerlukan delegasi, sehingga batas satu delegate per token account tidak berlaku, dan otoritas penyelesaian tidak dapat mengalihkan hasil. Setiap trade bergantung pada program yang dapat di-upgrade dan upgrade authority-nya.
• Pola delegasi tidak memiliki dependensi program dan bekerja dengan mint yang memiliki Scaled UI Amount. Program menolak mint tersebut, yang berarti mengecualikan setiap mint yang dibuat dari template tokenized-security milik Mosaic (lihat batasan konfigurasi mint).

Peran

Program ini bersifat simetris. Dalam antarmukanya, kedua pihak adalah user_a, yang mengirimkan mint_a, dan user_b, yang mengirimkan mint_b. README dan klien yang dihasilkan menyebut mint_a sebagai asset leg dan mint_b sebagai cash leg, dan halaman ini mengikuti konvensi tersebut, tetapi tidak ada ketentuan dalam program yang mengharuskan cash leg berupa instrumen kas. Dua aset, atau dua stablecoin, diselesaikan dengan cara yang sama.

ID Program

dvp34bdbcEm4f4FCUjGV4mDAkDshaQR4LkK8fdcsyZq

Program ini dapat di-upgrade di kedua cluster. Angka di atas adalah yang dilaporkan solana program show pada 2 Oktober 2026; jalankan perintah yang sama untuk mendapatkan nilai terkini. Build devnet lebih lama daripada commit yang menjadi acuan halaman langkah (lihat Install), dengan kumpulan instruksi dan error yang sama.

Siklus hidup

Sebuah trade terbuka sejak CreateDvp hingga salah satu dari Settle, Cancel, atau Reject menutupnya. Pendanaan tidak memiliki instruksi tersendiri: sebuah leg dianggap terdanai ketika akun escrow-nya menyimpan setidaknya jumlah yang disepakati. Reclaim berlaku per leg dan membiarkan trade tetap terbuka, sehingga masalah pada satu leg tidak memaksa pihak lain membatalkan seluruh trade.

State

Setiap trade memiliki satu akun SwapDvp berukuran 458 byte, dimiliki oleh program. Alamatnya diturunkan dari otoritas penyelesaian, kedua pihak, kedua mint, dan sebuah nonce (seed ["dvp", settlement_authority, user_a, user_b, mint_a, mint_b, nonce]). Jumlah dan waktu disimpan di dalam akun dan tidak memengaruhi alamat, sehingga harus dibaca dan tidak boleh diasumsikan. Sebuah akun penanda kecil, nonce tombstone di ["nonce", swap_dvp], dibuat bersama trade dan tidak pernah ditutup, sehingga setiap kombinasi pihak, mint, otoritas, dan nonce hanya dapat digunakan untuk satu trade.

Daftar field diambil dari IDL program pada commit yang disebutkan di bawah Buat trade.

Instruksi

Setiap refund masuk ke associated token account milik pihak tersebut untuk mint leg itu, siapa pun yang mendanai escrow.

Akun dan argumen setiap instruksi tersedia di halaman untuk langkah tersebut.

Error

Event dan indexing

Program ini tidak mengeluarkan event onchain. Indexer atau sistem rekonsiliasi membaca status akun SwapDvp dan saldo token dari kedua escrow, serta menggunakan ref_string untuk mengorelasikan trade dengan order off-chain-nya. Karena catatan ditutup saat settlement, sistem yang membutuhkan ketentuan tersebut setelahnya menyimpannya saat membacanya, atau merekonstruksinya dari transaksi yang membuat trade tersebut.

Token yang didukung

Sebuah trade dapat memasangkan leg SPL Token dengan leg Token-2022; setiap leg membawa token program-nya sendiri. Leg Wrapped SOL didukung.

Biaya transfer akan membuat sisi penerima kekurangan dari jumlah yang disepakati. Interest Bearing dan Scaled UI Amount tidak mengubah jumlah mentah, tetapi rate atau multiplier-nya dapat berubah antara pembuatan dan settlement trade, yang mengubah cara jumlah yang disepakati ditampilkan. NonTransferable akan membuat kedua leg terjebak.

Authority yang diterima dapat memindahkan, membekukan, atau menghentikan token yang di-escrow selama masa berlaku trade (lihat di bawah). Escrow tidak dapat dikonfigurasi untuk menerima transfer rahasia (confidential), sehingga jumlah yang di-escrow dan di-settle pada leg confidential bersifat publik.

Untuk mint dengan hook, klien me-resolve akun tambahan milik hook dan menambahkannya ke Settle, Cancel, Reject, Reclaim, dan Recover. Batas 32 per leg menghitung program hook dan akun validasinya. Jika hook authority memperbesar daftar akun hook melebihi batas tersebut, setiap transfer pada leg itu gagal, termasuk Reclaim, Cancel, Reject, dan Recover, sampai authority membatalkannya. Batas akun transaksi dapat tercapai lebih dulu sebelum batas per leg jika kedua leg memiliki hook.

Ketika akun tujuan atau refund mewajibkan memo, program memanggil program Memo sebelum transfer, itulah sebabnya setiap instruksi yang memindahkan token keluar dari escrow membutuhkan akun memo_program.

Batasan konfigurasi mint

Scaled UI Amount. Template tokenized-security di Mosaic, toolkit penerbitan Solana Foundation, selalu menambahkan Scaled UI Amount, sehingga program ini tidak menerima mint yang dibuat dari template tersebut sebagai leg. Mint yang ditujukan untuk program ini dapat dibuat tanpa ekstensi tersebut (lihat Token Extensions); DvP menggunakan delegasi melakukan settlement melalui otoritas yang didelegasikan dan tidak menerapkan pemeriksaan ini.

Mint yang dibekukan secara default. Escrow setiap trade adalah associated token account yang dimiliki oleh Program Derived Address yang baru untuk trade tersebut. Pada mint dengan Default Account State yang diatur ke frozen, escrow dibuat dalam keadaan frozen, dan transfer pendanaan ke dalamnya gagal sampai di-thaw. Di bawah Token ACL itu berarti penerbit atau transfer agent-nya mengizinkan escrow trade sebelum pendanaan: baik dengan menambahkan alamat catatan trade (pemilik escrow) ke allowlist, sehingga siapa pun dapat men-thaw escrow tersebut jika konfigurasi Token ACL mint mengaktifkan permissionless thaw, atau dengan meminta freeze authority men-thaw-nya secara langsung. Escrow yang dibekukan juga memblokir Settle, Reclaim, Cancel, Reject, dan Recover pada leg tersebut, sehingga freeze authority, dan pada mint dengan hook, hook authority, merupakan pihak tepercaya selama masa berlaku trade. Jalur escrow yang dibekukan dijelaskan di sini dan tidak dijalankan dalam snippet devnet.

Batasan

• Tidak ada pencocokan, penemuan harga, atau order book. Para pihak menyepakati ketentuan di luar ledger dan salah satunya mencatatnya.
• Tidak ada netting, dan hanya bilateral: satu catatan adalah satu trade antara dua pihak.
• Tidak ada partial fill. Settle memindahkan tepat jumlah yang disepakati dari setiap leg dan mengembalikan kelebihan apa pun kepada party leg tersebut.
• Tidak ada leg off-ledger. Kedua leg adalah token account di Solana; leg tunai pada rel yang sudah ada diselesaikan secara terpisah dan direkonsiliasi.
• Tidak ada pemeriksaan kelayakan, allowlist, atau KYC. Kontrol milik mint sendiri yang menegakkan kelayakan pemegang.
• Tidak ada settlement otomatis. Settlement authority harus menandatangani.
• Tidak ada event, dan tidak ada biaya protokol selain biaya transaksi dan rent.

Program ini menghilangkan risiko pokok (principal risk) antara kedua pihak: tidak ada leg yang bergerak kecuali keduanya bergerak. Program ini tidak menghilangkan risiko kredit penerbit atau risiko penebusan pada kedua token, kemampuan freeze, pause, atau permanent delegate authority suatu mint untuk bertindak atas token yang di-escrow (lihat token yang didukung), atau ketergantungan pada ketersediaan settlement authority untuk menandatangani.

Verifikasi sebelum pendanaan dan settlement

CreateDvp bersifat permissionless: hanya payer yang menandatangani, sedangkan para pihak dan settlement authority tidak. Karena itu, siapa pun dapat membuat catatan yang menyebut pihak dan ketentuan apa pun. Sebelum pendanaan, dan lagi sebelum settlement, baca akun SwapDvp dan pastikan:

1. Akun dimiliki oleh program DvP dan berukuran tepat 458 byte. Akun yang tidak dimiliki oleh program dapat diisi dengan byte yang ter-decode seperti catatan asli.
2. user_a, user_b, mint_a, mint_b, dan settlement_authority sesuai dengan trade yang disepakati.
3. amount_a, amount_b, expiry_timestamp, dan earliest_settlement_timestamp sesuai dengan ketentuan yang disepakati.
4. Kedua tujuan settlement adalah alamat yang disepakati. Catatan palsu dapat mengalihkan hasilnya.

Danai leg mencantumkan checked reader dari klien yang dihasilkan dan menunjukkan pemeriksaannya dalam kode.

Anggap sebuah trade telah selesai (settled) ketika transaksi Settle mencapai finalized. Itu adalah tingkat commitment jaringan; apakah itu juga menandai finalitas settlement untuk tujuan hukum bergantung pada perjanjian para pihak dan rezim yang berlaku.

Pembuatan versi

Akun SwapDvp tidak memiliki field versi. Tata letaknya tetap pada 458 byte (SwapDvp::LEN), dan checked reader menolak akun dengan panjang lain. IDL memiliki versinya sendiri, 0.1.0 per 2 Oktober 2026.

Program ini dapat di-upgrade di kedua cluster (lihat Program ID). Catatan trade hanya ada sampai di-settle, dibatalkan, atau ditolak, jadi periksa repositori untuk mengetahui bagaimana upgrade memperlakukan trade yang masih terbuka, dan buat ulang klien dari IDL build yang di-deploy.

Repositori dan audit

Source, IDL, klien yang dihasilkan, dan pengujian ada di solana-foundation/dvp di bawah lisensi MIT. Program ini adalah program Pinocchio no_std; klien dihasilkan dari IDL dengan Codama. Laporan kerentanan disampaikan melalui tautan security advisory repositori, sesuai SECURITY.md-nya.

Program ini telah diaudit oleh Cantina.

Terkait

• Delivery vs Payment (DvP) menggunakan delegasi: pola delegasi tanpa program
• Token ACL: bagaimana mint yang dibatasi berinteraksi dengan akun escrow