Lompat ke konten
Financial Context Wiki

Cara memverifikasi desimal token

Verifikasi decimals ERC-20 dari kontrak dan blok yang benar, lalu rekonsiliasi saldo mentah, transfer, persetujuan, dan konversi bridge tanpa galat floating-point.

Diperbarui

Hanya untuk tujuan edukasi; bukan nasihat investasi atau keamanan. Nilai desimal tidak membuktikan identitas, nilai, dukungan aset, atau keamanan token.

Jawaban langsung

Untuk token ERC-20, decimals() adalah metadata opsional yang memberi tahu antarmuka cara menampilkan unit token berbentuk bilangan bulat. Jika mengembalikan d, jumlah tampilan konvensional ialah raw / 10^d. Nilai ini tidak mengubah aritmetika kontrak dan tidak mengautentikasi token. Sebelum memercayainya, verifikasi chain, alamat kontrak yang tepat, kode atau implementasi proxy, dan blok.

Baca decimals() langsung melalui RPC independen pada blok tertentu, dekode hasil ABI sebagai uint8, lalu bandingkan dengan registri kontrak resmi penerbit dan explorer tepercaya. Setelah itu uji skala dengan nilai mentah balanceOf, transfer, persetujuan, receipt, dan event. Jangan diam-diam mengasumsikan 18 ketika panggilan tidak ada, revert, mengembalikan data cacat, atau bertentangan dengan bukti lain.

Cara kerja

ERC-20 menyimpan dan memindahkan jumlah sebagai bilangan bulat tanpa tanda. Lapisan tampilan menyisipkan tanda desimal; kontrak tetap menerima bilangan bulat. Konversikan input dengan string desimal atau bilangan bulat presisi arbitrer, bukan floating-point biner. Jumlah hanya dapat direpresentasikan bila perkalian dengan 10^d menghasilkan bilangan bulat.

Karena decimals() opsional, token yang sesuai standar boleh tidak memilikinya. Implementasi khusus atau yang dapat di-upgrade juga bisa mengembalikan nilai tak terduga atau berubah setelah upgrade. Untuk proxy ERC-1967, periksa alamat proxy, implementasi atau beacon, admin, dan event upgrade; baca status token pada alamat proxy dan tetapkan semua perbandingan pada blok yang sama.

Allowance dan nilai ERC-2612 permit juga merupakan bilangan bulat mentah. Transfer yang ditampilkan dengan benar tidak membuktikan bahwa persetujuan, minimum router, jumlah bridge, atau basis data akuntansi memakai skala yang sama. Kontrak bridge sumber dan tujuan dapat memakai desimal berbeda; bandingkan nilai yang terbaca dan unit mentah di setiap sisi berdasarkan aturan konversi dan pembulatan yang terdokumentasi.

Gunakan alur ini:

  1. Tetapkan ID chain atau domain, kontrak token, nomor blok, endpoint RPC, dan waktu pengamatan.
  2. Konfirmasi alamat melalui registri resmi penerbit; jangan anggap nama, simbol, ikon, atau hasil pencarian sebagai bukti berwenang.
  3. Periksa kode yang di-deploy dan apakah alamat merupakan proxy; catat implementasi atau beacon, admin, dan upgrade terbaru.
  4. Panggil decimals(), dekode uint8 melalui ABI, dan catat sukses, revert, kosong, atau output cacat tanpa mengganti dengan nilai bawaan.
  5. Baca balanceOf, totalSupply, allowance, calldata transaksi, receipt, dan event mentah pada blok yang kompatibel; format dengan skala yang diamati.
  6. Hitung ulang transfer, persetujuan, kuotasi, dan bridge dengan aritmetika bilangan bulat, termasuk biaya, pembulatan, sisa, rebase, atau pajak transfer.
  7. Simulasikan dan kirim transaksi kecil, lalu rekonsiliasi saldo mentah sebelum dan sesudah; berhenti jika antarmuka, RPC, event, atau saldo tidak cocok.

Contoh

  • Satu nilai mentah, dua skala. Dengan raw = 123456789, d = 6 menampilkan 123.456789; dengan d = 18, tampilannya 0.000000000123456789. Perbedaannya sebesar 10^12.
  • Keterwakilan itu penting. Dengan d = 6, 1.25 token menjadi 1250000 unit mentah. 0.0000001 token lebih kecil dari satu unit mentah dan harus ditolak atau dibulatkan menurut aturan eksplisit.
  • Skala persetujuan keliru. Allowance 100 token dengan d = 6 ialah 100000000. Jika dikodekan dengan d = 18, hasilnya 100000000000000000000, yaitu 10^12 kali lebih besar dari niat awal.
  • Penskalaan ulang bridge. Jika rute terdokumentasi 1:1 mengubah token sumber dengan d = 6 menjadi representasi tujuan dengan d = 18, nilai mentah 2500000 mewakili 2.5 token dan 2500000000000000000 di tujuan juga mewakili 2.5. Biaya, batas, sisa, dan saldo yang benar-benar diterima tetap harus diperiksa.

Risiko

  • Alamat yang benar ditanyakan pada chain yang salah.
  • Nama, simbol, atau ikon tiruan menyembunyikan kontrak lain.
  • Implementasi proxy atau beacon berubah setelah pemeriksaan sebelumnya.
  • RPC atau explorer menyajikan status lama, belum final, atau tidak konsisten.
  • Metadata yang hilang atau cacat diam-diam diganti dengan 18.
  • Konversi floating-point biner membulatkan jumlah besar atau presisi.
  • Dompet memformat transfer dengan benar tetapi salah memformat allowance atau permit.
  • Basis data mencampur unit mentah dengan jumlah yang terbaca manusia.
  • Bridge mengasumsikan desimal sama atau tidak mengungkap pembulatan sisa.
  • Fee-on-transfer, rebase, mint, burn, pause, atau freeze merusak rekonsiliasi sederhana.
  • Calldata transaksi, event, receipt, dan perubahan saldo aktual tidak sama.
  • Pemeriksaan desimal disalahartikan sebagai bukti penerbit, cadangan, likuiditas, atau keamanan.

Kesalahpahaman umum

  • Semua token ERC-20 memiliki 18 desimal. Metadata ini opsional dan implementasi dapat mengembalikan nilai lain.
  • Desimal adalah bit presisi yang dipakai EVM. Ini konvensi tampilan berbasis sepuluh; aritmetika token tetap berupa bilangan bulat.
  • Saldo terformat di explorer adalah konfirmasi independen. Explorer mungkin bergantung pada panggilan metadata yang sama dan berbagi galatnya.
  • Simbol dan desimal yang sama mengidentifikasi aset yang sama. Chain yang benar, kontrak yang tepat, dan bukti penerbit juga diperlukan.
  • Transfer kecil yang berhasil memvalidasi semua integrasi. Persetujuan, router, bridge, bursa, dan akuntansi dapat mengatur skala secara terpisah.

Topik terkait

Sumber

Navigasi

Cari di wiki...