Problem Statement

pallet-revive uses two types for balance: a generic Balance (required by Polkadot SDK, typically set to u128) and a U256 (for Ethereum and Solidity compatibility).

The consequence is that when deploying/calling/testing/writing contracts, users have to know about both types and handle both of them.

This can be confusing, as pallet-revive defines a multiplication factor to convert between both types. For Passet Hub that's 100_000_000 (source).

You can find examples throughout all tools and our APIs:

Balance is used when e.g. communicating with a node via the E2E API or setting storage deposit limits.
U256 is used e.g. when the contract queries its own value or in a contract call trace.

Another example where this is visible is the Contracts UI:

Showing the balance of a contract:

Versus passing a "balance" into it:

A pitfall is that there is a Balance: Into<U256> (which is also needed), but I can already see people doing something like

fn transfer(v: U256) { … }

let value: Balance = 1_000;
transfer(value.into()) // this is wrong, it should be `(value * native_to_eth_ratio).into()`

Solutions

A simplification would be to decide on one type and then have ink, ink_e2e, cargo-contract, Contracts UI use only that one, doing the mapping in the background.

Unify to Balance

• ➕ @davidsemakula: "One thing that speaks for Balance as the one type, is that converting from Balance to U256 is presumably infallible, while U256 to Balance is a fallible conversion."

Unify to U256

• ➕ U256 as it allows for a bigger number range (so no precision loss).
• ➕ U256 because when cross-contract calling to Solidity contracts using their native types makes things more seamless for the user.

Leave everything as is

There is the danger of creating a leaky abstraction, we could end up making things even more confusing. E.g. I don't know what PAPI or inkathon do at the moment.