Skip to main content
The x/precisebank module from cosmos/evm extends the standard x/bank module from 6 to 18 decimal precision for EVM compatibility.
For conceptual understanding of precision handling and mathematical proofs, see Precision Handling.

Overview

The module acts as a wrapper around x/bank, providing:
  • 18 decimal precision for EVM (10^18 sub-atomic units)
  • Backward compatibility with 6 decimal Cosmos operations
  • Transparent conversion between precision levels
  • Fractional balance tracking for sub-test amounts
Developed with contributions from the Kava team.

State

The module maintains fractional balances and remainder (source):

Balance Representation

Full balance calculation:
Where:
  • test_balance: Stored in x/bank (6 decimals)
  • fractional_balance: Stored in x/precisebank (0 to 10^12-1)
  • atest_balance: Full 18-decimal precision

Keeper Interface

The module provides a bank-compatible keeper (source):

Extended Coin Support

Automatic handling of “atest” denomination:
  • Converts between test and atest transparently
  • Maintains fractional balances for sub-test amounts
  • Ensures consistency between x/bank and x/precisebank

Operations

Transfer

Handles both integer and fractional components:
Algorithm:
  1. Subtract from sender (update b(sender) and f(sender))
  2. Add to receiver (update b(receiver) and f(receiver))
  3. Update reserve based on carry/borrow
  4. Remainder unchanged (mathematical guarantee)

Mint

Creates new tokens with proper backing:
Algorithm:
  1. Add to account (update b(account) and f(account))
  2. Decrease remainder (tokens enter circulation)
  3. Update reserve for consistency

Burn

Removes tokens from circulation:
Algorithm:
  1. Subtract from account (update b(account) and f(account))
  2. Increase remainder (tokens leave circulation)
  3. Update reserve for consistency

Events

Standard bank events with extended precision amounts:

Transfer Events

Mint/Burn Events

Queries

gRPC

CLI

Integration

For EVM Module

Replace bank keeper with precisebank keeper in app.go:

For Other Modules

Query extended balances through standard interface:

Reserve Account

The reserve account maintains backing for fractional balances:

Monitoring Reserve

Invariants

Critical invariants maintained by the module:

Best Practices

Chain Integration

  1. Reserve Monitoring
    • Track reserve balance for validation
    • Set up alerts for invariant violations
    • Regular audits of fractional sums
  2. Migration Path
  3. Testing

dApp Development

  1. Balance Queries
  2. Precision Handling

Security Considerations

Overflow Protection

  • All arithmetic uses checked math
  • Fractional values bounded to [0, 10^12)
  • Integer overflow impossible by design

Atomicity

  • Balance updates are atomic
  • Reserve adjustments in same transaction
  • No intermediate states visible

Precision Guarantees

  • No precision loss during operations
  • All fractional amounts preserved
  • Rounding only at display layer

Performance

Storage Impact

  • Additional O(n) storage for accounts with fractional balances
  • Most accounts have zero fractional balance (no storage)
  • Reserve account: single additional balance

Computation

  • Constant time operations for all transfers
  • Single addition/multiplication for balance queries
  • ~10% gas overhead for fractional updates

Optimization

  • Lazy initialization (fractional balances start at zero)
  • Sparse storage (only non-zero fractions stored)
  • Batch operations maintain efficiency

Troubleshooting

Common Issues

Validation Commands

References

Source Code