This proposal introduces a backward-compatible method to handle decimal precision for Neo N3 tokens (NEP-17) by utilizing the data parameter in transfer and extending balanceOf to accept an optional data argument. This allows for "Virtual Decimals" without disrupting existing Exchanges, Explorers, or Wallets that rely on the current integer-based implementation.
By using a Keyword Opt-in strategy, we can allow advanced users/dapps to interact with decimal values while the rest of the network continues to see standard integers.
Enhanced balanceOf(account, [data])
The standard balanceOf currently takes one argument: account. We propose an overload or an internal check for an optional data parameter.
- Default Behavior: If data is null or empty, return the raw Integer.
- Decimal Behavior: If data contains a specific keyword (e.g., "factor8"), the method returns the value adjusted by the token's decimal factor.
Parameterized transfer(from, to, amount, [data])
The transfer method already includes a data parameter for triggers. We propose utilizing this to change the interpretation of the amount.
- Scenario A (Standard): transfer(A, B, 100, null) → Transfers 100 raw units.
- Scenario B (Virtual Decimals): transfer(A, B, 1, "factor8") → If the token has 8 decimals, the contract interprets "1" as 1.00 \times 10^8 units.
Rationale & Backward Compatibility
- Zero Impact on Exchanges: Exchanges call balanceOf(address) without the extra parameter. They will continue to receive the raw integer, ensuring no accounting errors.
- No Breaking Changes: This does not require a hard fork of the Neo VM, only a standard update to how NEP-17 contracts are written and how SDKs (like neo-line or neon-js) format their requests.
- Opt-in Complexity: Only Dapps that want to handle human-readable decimals in the contract layer need to implement this.
This proposal introduces a backward-compatible method to handle decimal precision for Neo N3 tokens (NEP-17) by utilizing the data parameter in transfer and extending balanceOf to accept an optional data argument. This allows for "Virtual Decimals" without disrupting existing Exchanges, Explorers, or Wallets that rely on the current integer-based implementation.
By using a Keyword Opt-in strategy, we can allow advanced users/dapps to interact with decimal values while the rest of the network continues to see standard integers.
Enhanced balanceOf(account, [data])
The standard balanceOf currently takes one argument: account. We propose an overload or an internal check for an optional data parameter.
Parameterized transfer(from, to, amount, [data])
The transfer method already includes a data parameter for triggers. We propose utilizing this to change the interpretation of the amount.
Rationale & Backward Compatibility