Crypto methodology

The Crypto clusterconverts between three Ethereum denominations — Wei (atomic), Gwei (gas-price unit), and ETH (user-facing). The math is trivial in concept (powers of ten) and tricky in implementation (numbers exceed JavaScript’s native precision). This page explains the implementation choices.

The unit relationships

1 ETH = 10⁹ Gwei = 10¹⁸ Wei

The EVM stores all balances and arithmetic in Wei as unsigned 256-bit integers. ETH and Gwei are purely human-facing labels with no on-chain representation — they’re division-by-power-of-ten conventions for display.

Why BigInt is mandatory

JavaScript’s Number type uses IEEE 754 double precision: ~15-17 significant decimal digits. Number.MAX_SAFE_INTEGER is 2⁵³ − 1 ≈ 9.007 × 10¹⁵. A 9 ETH balance is roughly 9 × 10¹⁸ Wei — three orders of magnitude past the precision floor.

Concretely: if you store 1.234567890123456789 ETH in a Number and convert to Wei, the last several digits get rounded. If you accept that string as input from a wallet and pass it to a smart contract, the contract receives a different number than the user thought they sent.

Production crypto libraries (ethers.js, viem, web3.js) all use BigInt or a BigNumber wrapper for Wei amounts. Our converter uses native BigInt throughout. Inputs accept decimal strings; the conversion parses them carefully to avoid premature Number coercion.

The decimal-string parsing path

For a user input like 1.234 ETH:

1. Split on the decimal point. Integer part: 1; fractional part: 234.
2. Pad the fractional part to 18 digits (ETH’s precision): 234000000000000000.
3. Concatenate: 1234000000000000000.
4. Construct a BigInt from the result.
5. To convert to Gwei, divide by 10⁹ (BigInt division is integer division — this is correct because Gwei has 9 fewer decimal places than Wei).

Conversions to ETH for display reverse the process: divide the BigInt by 10¹⁸ to get the integer part, modulo 10¹⁸ for the fractional part, format as a decimal string with leading zeros where needed. Trailing zeros are stripped for readability.

Round-trip guarantee

Any conversion through our calculator round-trips exactly. Specifically:

• ETH → Wei → ETH preserves all 18 fractional digits.
• Gwei → Wei → Gwei preserves all 9 fractional digits.
• Wei → ETH → Wei is exact because Wei amounts are integers.

Inputs with more precision than the unit supports (e.g., “1.5 Wei”) get truncated, not rounded — sub-Wei amounts don’t exist.

Algorithm details: the BigInt path end-to-end

The converter is a pure-function pipeline; the same inputs always produce the same outputs. Pseudocode for the ETH-to-Wei direction:

function ethToWei(input: string): bigint {
  const [intPart, fracPartRaw = ""] = input.split(".");
  if (fracPartRaw.length > 18) throw new Error("over-precise");
  const fracPart = fracPartRaw.padEnd(18, "0");
  return BigInt(intPart) * 10n ** 18n + BigInt(fracPart);
}

Every step uses BigInt arithmetic — no Number coercion. The padding-then-concatenation pattern avoids any floating-point intermediate, which is the only way to preserve the full 18 fractional decimal digits ETH allows.

Wei-to-display uses the reverse trick:

function weiToEth(wei: bigint): string {
  const intPart = wei / 10n ** 18n;
  const fracPart = wei % 10n ** 18n;
  const fracStr = fracPart.toString().padStart(18, "0").replace(/0+$/, "");
  return fracStr.length === 0 ? intPart.toString() : `${intPart}.${fracStr}`;
}

The same template generates Gwei (divide by 10⁹) and BTC ↔ satoshi (divide by 10⁸ — fits in a regular Number but the library uses BigInt for consistency).

Sources & references

The Wei / Gwei / ETH unit hierarchy is normative in the Ethereum Yellow Paper. EIP-1559 standardised the base-fee and priority-fee display conventions our calculator mirrors. JavaScript’s arbitrary-precision integer type is specified in ECMA-262; the precision floor we work around is from IEEE 754. Bitcoin’s 8-decimal precision comes from the original whitepaper. Full citations in the Sources block below.

Assumptions & limitations

• Pure arithmetic, no network. The calculator never reads a chain RPC or wallet balance — inputs are user-provided strings, outputs are formatted strings.
• Sub-Wei amounts are truncated, not rounded. An input of 0.5 Weiresolves to 0 Wei. Sub-atomic units don’t exist on Ethereum.
• Display formatting strips trailing zeros. 1.230000…0 ETH displays as 1.23 ETH. Smart contracts care about the BigInt, not the display string, so this is purely cosmetic.
• No live ETH/USD price. Fiat conversion uses a separate cached price service in the currency cluster — see the currency methodology for refresh cadence. The crypto unit converter is price-free.
• EVM-chain native tokens only.ERC-20 tokens have configurable decimals (USDC has 6, DAI has 18); use the token contract’s decimals() value, not the ETH 18, for those.
• No transaction signing, broadcasting, or custody. Use a wallet (Metamask, Rabby) for any movement; the converter only shows numbers.
• BigInt locale formatting is opt-in. Outputs use a plain decimal point; thousands separators are applied by the UI layer for ETH but not for raw Wei (a 50-digit number with commas is harder to copy than one without).

What we don’t do

• Live ETH price. Coming in Wave 2 (CoinGecko API + ISR cache).
• Other chains. Most EVM-compatible chains use the same Wei/Gwei/native-token hierarchy — replace the “ETH” label with MATIC, BNB, ARB, etc., and the math is identical.
• Bitcoin denominations. 1 BTC = 100,000,000 satoshi fits in a 64-bit integer comfortably; BigInt isn’t needed. Our underlying library supports BTC ↔ satoshi conversion; the UI tool ships in a later batch.
• Transactions. We don’t submit anything to any network.