Token SPL dan akun token di SSP

Kalau Anda pernah memakai token ERC-20 di Ethereum, model token Solana akan terasa akrab selama kira-kira tiga puluh detik lalu berhenti masuk akal. Di Ethereum, kontrak token menyimpan catatan siapa memiliki apa, dan alamat Anda muncul sebagai satu baris di catatan itu. Di Solana, alamat Anda sama sekali tidak muncul dalam catatan token tersebut. Sebagai gantinya, sebuah akun terpisah dibuat untuk menampung saldo Anda atas token tertentu itu — milik Anda, tetapi berbeda dari alamat utama Anda.

Satu keputusan desain itu menjelaskan hampir semua kejutan yang orang temui dengan token SPL: mengapa mengirim token ke orang baru lebih mahal daripada mengirim ke orang yang sudah memegangnya, mengapa dompet bisa menampilkan saldo nol untuk alamat yang belum pernah menyentuh token itu, dan mengapa desimal di sini lebih penting daripada di mana pun. Artikel ini menelusuri modelnya sebagaimana SSP mengimplementasikannya.

Mengapa Solana perlu akun terpisah untuk setiap token

Aturan inti Solana adalah segalanya merupakan akun, dan setiap akun punya pemilik, ukuran, serta setoran sewa yang sebanding dengan ukuran itu. Tidak ada yang namanya kontrak yang diam-diam menumbuhkan pemetaan internal seiring bertambahnya pengguna — penyimpanan harus berada di suatu akun, dan seseorang harus membayarnya.

Maka program SPL Token membagi tugasnya. Akun mint menyimpan fakta tentang token itu sendiri: total pasokan, desimal, dan siapa yang boleh menerbitkan lagi. Setiap pemegang mendapat akun token-nya sendiri, akun kecil berukuran tetap yang mencatat satu saldo untuk satu mint dan menyebut satu pemilik. Saldo SOL Anda tinggal di alamat Anda; saldo USDC Anda tinggal di akun token yang dikendalikan alamat Anda.

Kelebihan desain ini adalah keterdugaan — setiap saldo token berbentuk sama dan berbiaya sama untuk disimpan. Konsekuensinya, memegang token baru menuntut menghadirkan akun baru. Dokumentasi token Solana adalah sumber primer kalau Anda ingin spesifikasinya alih-alih ringkasannya.

Akun token terasosiasi, dan siapa yang membayarnya

Kalau setiap pemegang perlu akun token, dan siapa pun bisa membuat akun, Anda akan berakhir dengan beberapa akun token per orang per mint tanpa cara mengetahui harus mengirim ke yang mana. Akun token terasosiasi — ATA — adalah konvensi yang membereskannya: untuk pemilik tertentu dan mint tertentu, ada satu alamat kanonis, diturunkan secara deterministik dari keduanya. Dompet bisa menghitungnya, jadi tak seorang pun perlu menerbitkannya.

Ganjalannya adalah sewa. Akun token berukuran sekitar 165 byte, setara kira-kira 0,002 SOL yang ditahan sebagai setoran sewa selama akun itu ada. Setoran itu bisa ditarik kembali saat akun ditutup, tetapi harus dibayar di muka, dan harus dibayar oleh seseorang yang punya SOL — yang menurut definisinya mungkin tidak dimiliki penerima transfer token pertamanya.

SSP menangani ini seperti menangani biaya Solana lainnya. Ketika Anda mengirim token SPL kepada seseorang yang ATA-nya belum ada, transaksi itu menyertakan instruksi idempoten untuk membuatnya, dan paymaster SSP membayar sewanya. Vault Anda mengganti biaya paymaster di dalam transaksi yang sama, dan itulah sebabnya transfer pertama ke penerima baru berbiaya sekitar 0,0025 SOL lebih mahal daripada transfer berulang ke orang yang sama. "Idempoten" adalah kata pentingnya: kalau ternyata akunnya sudah ada, instruksi itu berhasil dan tidak melakukan apa-apa, alih-alih menggagalkan seluruh transfer.

Perhatikan bahwa instruksi pembuatan ini berada di luar proposal multisig. Membuat akun token milik orang lain tidak memindahkan dana Anda dan tidak memerlukan otorisasi dari vault Anda, jadi ia tidak termasuk bagian yang ditandatangani kedua perangkat Anda. Penggantian biaya, yang memang memindahkan dana Anda, berada di dalam proposal.

Apa yang didukung SSP secara bawaan

SSP hadir dengan SOL asli, mint USDC resmi milik Circle, dan FLUX di Solana. Token SPL lain yang muncul di vault Anda akan dikenali dan ditampilkan berdampingan dengannya.

Satu batasan yang disengaja layak dinyatakan terus terang: transfer Solana di SSP dibangun di atas program SPL Token klasik. Token yang diterbitkan di bawah Token-2022, program yang lebih baru dengan transfer hook, transfer rahasia, dan berbagai ekstensi lain, saat ini bukan bagian dari jalur pengiriman. Ini keputusan cakupan, bukan kelalaian: ekstensi Token-2022 dapat mengubah apa yang dilakukan sebuah transfer, dan mendukungnya berarti mengaudit tiap ekstensi terhadap jaminan dekode di perangkat yang dijelaskan di bawah.

Bagaimana transfer token sebenarnya disusun

Ketika Anda mengirim token SPL dari SSP, transaksi yang ditandatangani memuat, berurutan:

1. Membuat ATA penerima bila perlu — idempoten, dibayar paymaster, di luar proposal.
2. TransferChecked — memindahkan saldo dari akun token vault Anda ke milik penerima, diotorisasi oleh vault.
3. Mengganti biaya paymaster — transfer SOL biasa dari vault Anda, di dalam proposal.

Semuanya mendarat sebagai satu transaksi atomik. Tidak ada langkah persetujuan terpisah, tidak ada proposal tertunda yang menganggur di rantai, dan tidak ada keadaan di mana akun penerima sudah dibuat tetapi transfernya belum terjadi. Entah semuanya dieksekusi, atau tidak sama sekali.

Akun sumbernya adalah ATA milik vault Anda sendiri — diturunkan dengan cara deterministik yang sama, dengan alamat program vault sebagai pemiliknya. Karena vault adalah alamat turunan program dan bukan pasangan kunci, penurunan itu secara eksplisit mengizinkan pemilik yang berada di luar kurva ed25519. Kalau Anda ingin detail dasarnya tentang mengapa alamat vault bekerja demikian, multisig Solana yang memulai dirinya sendiri membahasnya.

Desimal adalah bagian dari tanda tangan

Inilah bagian yang layak diperlambat, karena di sinilah sebuah token bisa berbohong kepada Anda.

Sebuah mint menyatakan berapa tempat desimal yang dipakai tokennya. USDC memakai enam; banyak token memakai sembilan; tidak ada aturannya. Kalau dompet menampilkan "100 USDC" tetapi menyusun transfer untuk sejumlah unit mentah yang mengandaikan desimal yang salah, Anda bisa mengirim seribu kali lipat dan tidak melihat apa pun yang janggal di layar.

SSP memakai TransferChecked alih-alih instruksi transfer polos. Bedanya, TransferChecked menanamkan alamat mint dan byte desimal langsung ke data instruksi yang ditandatangani. Dari situ lahir tiga pemeriksaan terpisah:

• Ekstensi Anda mendekode byte-nya dan membandingkannya dengan yang ditampilkan.
• SSP Key mendekode byte yang sama secara independen di ponsel Anda dan membandingkannya dengan metadata token yang diberikan ekstensi.
• Program SPL Token on-chain membandingkan desimal dalam instruksi dengan desimal sebenarnya milik mint, dan menolak transaksi bila berbeda.

Pemeriksaan ketiga itulah yang tidak bisa diakali dengan kata-kata. Mint yang mengklaim desimal berbeda dari yang dimilikinya tidak menghasilkan transfer yang keliru — ia menghasilkan transaksi yang gagal.

Menerima token

Menerima lebih sederhana, dengan satu kerutan. Berikan kepada pengirim alamat dompet Anda — yang ditampilkan SSP di layar terima — bukan alamat akun token. Apa pun yang mereka kirim, ATA yang benar diturunkan dari alamat Anda dan mint-nya, dan dompet pengirim akan membuatnya bila perlu.

Kalau vault Anda belum pernah memegang token itu, akunnya belum akan ada sampai transfer pertama tiba, dan sewanya dibayar oleh siapa pun yang mengirim kepada Anda. Ini normal dan tidak menuntut apa pun dari Anda. Artinya memang penjelajah blok tidak akan menampilkan akun token untuk token yang dijanjikan tetapi belum Anda terima — itu akunnya yang belum ada, bukan transfer yang hilang.

Jebakan yang sering terjadi

Mengirim ke alamat akun token alih-alih alamat dompet. Sebagian penjelajah menampilkan ATA secara menonjol. Mengirim token ke akun token dan bukan ke pemiliknya adalah cara yang terkenal untuk kehilangan dana di Solana. SSP mengharapkan alamat dompet pemilik dan menurunkan sisanya sendiri.

Menganggap token asing itu aman karena ia muncul di dompet Anda. Siapa pun bisa membuat mint dan mengirimkannya kepada Anda, dan mint bisa memakai nama yang meniru token sungguhan. Munculnya sebuah token di vault Anda bukan rekomendasi. Verifikasi alamat mint terhadap sumber resmi sebelum memperlakukan sebuah saldo sebagai nilai nyata.

Mengharapkan persetujuan bergaya Ethereum. Token SPL punya mekanisme delegasi, tetapi pola tunjangan permanen yang membuat persetujuan ERC-20 jadi risiko berulang bukanlah cara kebanyakan aplikasi Solana dibangun. Kalau Anda datang dari Ethereum, persetujuan token: izin yang terus Anda berikan menjelaskan kebiasaan yang sedang Anda tanggalkan, dan Ethereum di SSP memuat perbandingannya.

Melupakan tambahan biaya pengiriman pertama. Tambahan ~0,0025 SOL pada transfer pertama ke penerima baru itu sewa, bukan biaya yang dipungut SSP. Ia mengendap di akun token penerima dan bisa mereka tarik kembali kalau suatu saat menutupnya.

Untuk mekanika langkah demi langkah sebuah transfer nyata, lihat mengirim Solana dengan SSP. Untuk bagaimana SSP menyimpan vault yang mendasarinya dalam multisig 2-dari-2 tanpa pembuat, mulailah dari Solana di SSP.