PreciseBank

Extended precision wrapper for x/bank enabling 18 decimal support

The x/precisebank module from Ontomir 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](/docs/evm/next/documentation/concepts/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 Ontomir operations

  • Transparent conversion between precision levels

  • Fractional balance tracking for sub-test amounts

Developed with contributions from the [Kava](https://www.kava.io/) team.

State

The module maintains fractional balances and remainder :

Object
Key
Value
Description

FractionalBalance

0x01 + address

math.Int

Account fractional balance (0 to 10^12-1)

Remainder

0x02

math.Int

Uncirculated fractional amount

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 :

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

Event
Attributes
Description

transfer

sender, recipient, amount

Full atest amount

coin_spent

spender, amount

Extended precision

coin_received

receiver, amount

Extended precision

Mint/Burn Events

Event
Attributes
Description

coinbase

minter, amount

Minted with 18 decimals

burn

burner, amount

Burned with 18 decimals

Queries

gRPC

CLI

```bash Query-Total # Query total fractional balances evmd query precisebank total-fractional-balances

Example output:

total: "2000000000000atest"

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:

Invariant
Formula
Description

Supply

Total_atest = Total_test × 10^12 - remainder

Total supply consistency

Fractional Range

0 ≤ f(n) < 10^12

Valid fractional bounds

Reserve Backing

Reserve × 10^12 = Σf(n) + r

Full backing guarantee

Conservation

Δ(Total_atest) = Δ(Total_test × 10^12)

No creation/destruction

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

Issue
Cause
Solution

"fractional overflow"

Fractional > 10^12

Check calculation logic

"insufficient balance"

Including fractional

Verify full atest balance

"invariant violation"

Supply mismatch

Audit reserve and remainder

Validation Commands

最后更新于