﻿---
title: "Cara memverifikasi desimal token"
description: "Verifikasi decimals ERC-20 dari kontrak dan blok yang benar, lalu rekonsiliasi saldo mentah, transfer, persetujuan, dan konversi bridge tanpa galat floating-point."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cara memverifikasi desimal token

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

<a id="answer"></a>

## 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.

<a id="mechanism"></a>

## 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.

<a id="example"></a>

## 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.

<a id="risks"></a>

## 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.

<a id="misconceptions"></a>

## 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.

<a id="related"></a>

## Topik terkait

- [Verifikasi kontrak token](/crypto/token-contract-verification/)
- [Dekode calldata dompet](/crypto/calldata-decoding-wallet/)
- [Verifikasi token bridge](/crypto/bridge-token-verification/)
- [Risiko token fee-on-transfer](/crypto/fee-on-transfer-token-risk/)
- [Kontrak proxy](/crypto/proxy-contract/)

<a id="sources"></a>

## Sumber

- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (diakses: 2026-08-21)
- [ERC-20](https://docs.openzeppelin.com/contracts/5.x/erc20) - OpenZeppelin Docs (diakses: 2026-08-21)
- [JSON-RPC API](https://ethereum.org/developers/docs/apis/json-rpc/) - ethereum.org (diakses: 2026-08-21)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (diakses: 2026-08-21)
- [ERC-2612: Permit Extension for EIP-20 Signed Approvals](https://eips.ethereum.org/EIPS/eip-2612) - Ethereum Improvement Proposals (diakses: 2026-08-21)

Source: https://wiki.fcontext.com/id/crypto/token-decimals-verification/index.mdx
