IcyDB - is it worth adding native u256

Developers
1

I asked ChatGPT the question and this is the reply, wondered if anybody had feedback. I do have a plan to get Ethereum devs over to the IC so im not worried about the last bit.

It would remove an important obstacle, but it would not by itself unlock Ethereum developers.

For Ethereum developers, uint256 feels as fundamental as u64 does to a Rust developer. Native U256 in IcyDB would mean they could bring across:

  • Token balances, allowances and total supply.
  • NFT token IDs.
  • DeFi reserves, prices and accounting values.
  • Solidity event data.
  • Numeric indexes, ranges and aggregates over those values.

Without it, they must convert values into blobs, strings or smaller integers and lose normal database arithmetic and ordering. That makes IcyDB feel less naturally suited to Ethereum-derived applications.

But there are three audiences:

Developer Effect of native U256
Rust/Alloy Ethereum developer Strong benefit; familiar values map naturally into IcyDB
DeFi team rebuilding natively on IC Important foundation for financial state and queries
Solidity-only developer Limited benefit; they still need a new language and execution model

To genuinely attract Ethereum developers to native IC development, the broader bridge would need:

  • U256, and later I256, with familiar checked arithmetic.
  • First-class address and bytes32/hash representations.
  • Clean Alloy/Ethereum ABI conversion adapters.
  • Ethereum-wallet signature authentication.
  • Fixed-point and safe full-width mul_div helpers for DeFi.
  • Clear examples showing how an Ethereum contract becomes an IcyDB + Canic application.
  • Tooling that hides Candid and actor-management complexity where possible.

The important strategic distinction is that this should provide familiar crypto data types on the IC’s native actor model, without importing the EVM’s nonce, gas, shared-state and sequential-execution model.

So I would phrase the decision this way:

Do not add U256 speculatively as an isolated database feature. Add it when IcyDB and Canic deliberately ship an Ethereum-to-native-IC developer path.

At that point it becomes foundational rather than overengineering. Until that larger onboarding path exists, U256 alone is unlikely to move adoption much.

2

I agree with this feedback. Needs to be small wasm addition and also 5-20x more efficient than the candid unbounded Int/Nat

My recommended verdict

Build and measure U256. Defer I256 completely unless a real downstream schema requires it.

The strongest possible outcome is not “IcyDB can store Ethereum numbers”—it already can. It is:

IcyDB can execute the common Ethereum numeric domain using one inline, allocation-free, fixed-cost value representation while retaining its existing planner, persistence and query authorities.

If the spike shows approximately 5–20× improvements in value kernels and a meaningful improvement in scan/projection/grouping workloads without damaging index density or unrelated values, native U256 is justified. If it only saves a few percent end-to-end and costs around 100 KiB of Wasm, constrained NatBig plus adapters is probably the better answer.