DEV Community: Jayden Cristian

Handling Cryptocurrency Amounts in JavaScript Without Floating-Point Errors

Jayden Cristian — Fri, 23 Oct 2026 17:46:09 +0000

Why a small rounding error matters

Try this in your browser console or Node.js:

console.log(0.1 + 0.2); // 0.30000000000000004

This is expected behavior, not a JavaScript bug. The Number type uses IEEE 754 binary floating-point values, so many decimal fractions cannot be represented exactly.

That usually isn't a problem when you're positioning an element on a page. It becomes a problem when a value represents a cryptocurrency balance, transfer amount, fee, or transaction limit.

For financial amounts, the goal is not to hide floating-point artifacts with formatting. It's to avoid introducing them into the calculation.

Let's build a small JavaScript utility that parses decimal amounts into integer base units, performs exact arithmetic, and formats the results without converting back to Number.

The code below is a standalone educational example, not a description of any particular exchange's production implementation. It handles non-negative amounts and intentionally enforces a limited input format.

Store amounts in the smallest unit

Most crypto assets have a defined number of decimal places. For example:

Asset	Decimal places	Smallest unit example
Bitcoin (BTC)	8	`0.00000001 BTC = 1 satoshi`
Ether (ETH)	18	`0.000000000000000001 ETH = 1 wei`
ERC-20 tokens	Token-specific	Read the token's `decimals` metadata

Instead of storing 0.1 BTC as a floating-point value, store 10,000,000 satoshis as an integer. The decimal separator becomes a concern only when parsing input or displaying output.

The decimal precision is part of the asset definition. Never assume that two tokens—or even versions of an asset on different chains—have the same precision.

Why `BigInt` is useful

JavaScript's Number can represent integers exactly only up to Number.MAX_SAFE_INTEGER (9007199254740991). BigInt supports integer arithmetic without that safe-integer limit.

console.log(Number('9007199254740993'));
// 9007199254740992 — precision has already been lost

console.log(BigInt('9007199254740993'));
// 9007199254740993n — exact

The distinction matters for base-unit quantities, which can grow large even when the human-readable asset amount looks ordinary.

BigInt doesn't store decimal fractions, and that's an advantage here: we convert the decimal string into an integer before doing any arithmetic.

Build two small utilities

Create a file named amounts.mjs:

function validateDecimals(decimals) {
  // Application-level guard for this demonstration.
  if (!Number.isInteger(decimals) || decimals < 0 || decimals > 30) {
    throw new RangeError('decimals must be an integer from 0 to 30');
  }
}

export function parseUnits(value, decimals) {
  validateDecimals(decimals);

  if (typeof value !== 'string' || !/^(0|[1-9]\d*)(?:\.\d+)?$/.test(value)) {
    throw new TypeError('amount must be an unsigned decimal string');
  }

  const [whole, fraction = ''] = value.split('.');
  if (fraction.length > decimals) {
    throw new RangeError(`amount exceeds ${decimals} decimal places`);
  }

  const base = 10n ** BigInt(decimals);
  const fractionalUnits = BigInt(fraction.padEnd(decimals, '0') || '0');
  return BigInt(whole) * base + fractionalUnits;
}

export function formatUnits(units, decimals) {
  validateDecimals(decimals);

  if (typeof units !== 'bigint' || units < 0n) {
    throw new TypeError('units must be a non-negative bigint');
  }

  const base = 10n ** BigInt(decimals);
  const whole = (units / base).toString();
  if (decimals === 0) return whole;

  const fraction = (units % base)
    .toString()
    .padStart(decimals, '0')
    .replace(/0+$/, '');

  return fraction ? `${whole}.${fraction}` : whole;
}

parseUnits() accepts an amount string, never a JavaScript floating-point value. It rejects negative signs, scientific notation, grouping separators, and inputs with more precision than the asset allows. It doesn't silently round or truncate.

formatUnits() does the reverse using integer division and remainder. It removes unnecessary trailing zeros for display but doesn't change the underlying amount.

The 0–30 decimal-place check is a protective limit for this tutorial, not a blockchain-wide rule. A production system must define limits based on the assets and inputs it actually supports.

Add amounts without floating-point math

With eight decimal places:

import { parseUnits, formatUnits } from './amounts.mjs';

const first = parseUnits('0.1', 8);  // 10000000n
const second = parseUnits('0.2', 8); // 20000000n
const total = first + second;        // 30000000n

console.log(formatUnits(total, 8)); // '0.3'

The values are exact because we're adding integers. No Number conversion or toFixed() call is needed.

The same functions handle one satoshi:

parseUnits('0.00000001', 8); // 1n
formatUnits(1n, 8);          // '0.00000001'

They also preserve a base-unit amount larger than JavaScript's maximum safe integer:

const amount = '90071992.54740993';
const units = parseUnits(amount, 8);

console.log(units);                 // 9007199254740993n
console.log(formatUnits(units, 8)); // '90071992.54740993'

Rounding is a business rule, not a formatting trick

Exact integer arithmetic doesn't remove the need for rounding. It makes rounding explicit.

For example, imagine an illustrative fee of 25 basis points (0.25%). If the policy requires rounding the fee up to the nearest smallest unit, for a non-negative amount we can use:

const amountUnits = parseUnits('0.12345678', 8);
const feeBps = 25n; // 25 / 10,000 = 0.25%

const feeUnits = (amountUnits * feeBps + 9_999n) / 10_000n;

console.log(formatUnits(feeUnits, 8)); // '0.00030865'

Why add 9_999n? Integer division truncates the fractional part, so that expression implements ceiling division for non-negative integers. If a fee policy requires rounding down, you'd use a different calculation.

Don't reuse a rounding rule blindly. Trading quotes, displayed estimates, payout amounts, and fees can have different requirements. When converting between assets, also specify the quote's price representation and which side of the conversion is rounded. BigInt alone does not solve exchange-rate arithmetic.

Keep JSON boundaries explicit

JSON.stringify() does not serialize a BigInt directly:

JSON.stringify({ amount: 10000000n });
// Throws TypeError

Instead, define an API format that uses a decimal string for the base-unit integer, plus the asset and precision metadata:

const payload = {
  asset: 'BTC',
  amount_units: total.toString(),
  decimals: 8,
};

const json = JSON.stringify(payload);
// {"asset":"BTC","amount_units":"30000000","decimals":8}

When reading this data, validate the asset, network, precision, and amount string before reconstructing a BigInt. Treat the JSON fields as an explicit contract, not something to guess from the displayed number.

Test the edge cases

Create amounts.test.mjs next to amounts.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';
import { parseUnits, formatUnits } from './amounts.mjs';

test('adds 0.1 and 0.2 exactly', () => {
  const a = parseUnits('0.1', 8);
  const b = parseUnits('0.2', 8);
  assert.equal(formatUnits(a + b, 8), '0.3');
});

test('preserves values beyond Number.MAX_SAFE_INTEGER', () => {
  const amount = '90071992.54740993';
  assert.equal(parseUnits(amount, 8), 9007199254740993n);
  assert.equal(formatUnits(parseUnits(amount, 8), 8), amount);
});

test('supports one satoshi and zero-decimal assets', () => {
  assert.equal(parseUnits('0.00000001', 8), 1n);
  assert.equal(formatUnits(1n, 8), '0.00000001');
  assert.equal(parseUnits('12', 0), 12n);
  assert.equal(formatUnits(12n, 0), '12');
});

test('formats trailing zeros without changing the amount', () => {
  assert.equal(formatUnits(parseUnits('1.2300', 6), 6), '1.23');
});

test('rejects excess precision', () => {
  assert.throws(() => parseUnits('0.000000001', 8), RangeError);
});

test('rejects invalid amount formats', () => {
  assert.throws(() => parseUnits('-1', 8), TypeError);
  assert.throws(() => parseUnits('1e-8', 8), TypeError);
  assert.throws(() => parseUnits(0.1, 8), TypeError);
});

Run them with a modern version of Node.js:

node --test amounts.test.mjs

These cases check exact addition, maximum-safe-integer boundaries, the smallest supported unit, zero-decimal assets, display formatting, and invalid input.

For production use, you'd also want limits on input length, asset metadata validation, explicit overflow rules for external systems, property-based tests, and round-trip tests over a much larger set of values.

Common mistakes worth avoiding

Converting a user-entered amount to Number first. Once precision is lost, a later BigInt conversion cannot recover it.
Using toFixed() as the calculation strategy. It formats a floating-point value; it does not turn previous arithmetic into exact decimal arithmetic.
Assuming all assets use 18 decimals. Precision must come from trusted metadata for the specific asset and network.
Mixing smallest units from different assets. 1000n satoshis and 1000n wei are not comparable amounts.
Ignoring the rounding policy. An exact integer calculation can still implement the wrong fee or conversion rule.
Serializing BigInt as a JSON number. Preserve base-unit counts as strings when exchanging data with systems that may not safely represent large integers.

Key takeaways

A reliable money-handling boundary in JavaScript can be summarized as:

Decimal input string → validated smallest-unit BigInt → integer arithmetic → explicit rounding → decimal output string.

This pattern is straightforward, testable, and avoids accidental floating-point precision loss. It does not replace asset validation, appropriate arithmetic libraries for complex price ratios, or a careful review of financial requirements. But it gives the rest of the application something valuable: exact amounts to work with.

References

AI disclosure: The initial article draft and code examples were generated with AI assistance.

Introducing CryptoDeepApp: Instant Crypto Swaps, Token Analysis, and Portfolio Tools

Jayden Cristian — Wed, 30 Sep 2026 22:02:05 +0000

CryptoDeepApp is a cryptocurrency platform built around one main idea: bring crypto exchange, token research, and portfolio tools together in one place.

The platform started with crypto analytics, but instant cryptocurrency exchange has become one of its core products.

In this post, I want to give a quick overview of what CryptoDeepApp currently provides and how the main parts of the platform fit together.

Instant Crypto Swaps

CryptoDeepApp allows users to exchange cryptocurrencies through a simple swap flow.

Users can:

choose the asset they want to send
choose the asset they want to receive
select supported blockchain networks
enter receiving and refund addresses
choose between floating and fixed exchange rates
review exchange limits and route information before starting

Once an exchange is created, users can track its progress through several stages:

Waiting → Deposit → Exchange → Sending → Success

If the deposit window expires before funds are received, the exchange can move to an Overdue state.

The goal is to make the entire swap process transparent instead of hiding the transaction behind a single loading screen.

Fixed and Floating Rates

CryptoDeepApp supports two exchange modes.

Floating rate

The final exchange amount follows the market rate while the swap is being processed.

This can provide a rate closer to the live market, but the amount received may change as market conditions move.

Fixed rate

The exchange rate is locked for the swap according to the available quote.

This gives the user more certainty about the expected amount they will receive.

Solana Token Analyzer

CryptoDeepApp also includes a token analysis tool for Solana assets.

The analyzer brings together multiple types of information, including:

token overview
token rating
top holders
24-hour activity
liquidity
risk indicators
mint and freeze permissions
developer wallet information
social links
AI-assisted analysis

The purpose is to give users a quick view of a token's structure and market activity before they decide to research it further.

Portfolio Tracking

Users can also save assets to a portfolio and monitor their positions.

Portfolio tools include:

initial and current value
profit and loss
percentage performance
purchase history
target prices
price alerts
performance charts

Supported Solana assets can also be opened directly in the Token Analyzer.

API Integrations

CryptoDeepApp provides API functionality for partners who want to integrate exchange-related features into their own products.

Potential integrations include:

wallets
crypto applications
portfolio tools
aggregators
payment products
other Web3 services

The idea is to make the exchange layer usable both through the CryptoDeepApp interface and through external products.

Affiliate Tools

CryptoDeepApp also includes an affiliate system for partners.

Partners can create referral links, track referred swaps, view earnings, and manage payouts through their dashboard.

This creates another way for crypto communities, creators, and products to integrate with the platform without building a full API integration.

Building the Platform

From a technical perspective, CryptoDeepApp combines several different systems:

frontend web applications
backend APIs
blockchain integrations
exchange infrastructure
real-time transaction states
token data providers
monitoring
portfolio and notification services

That makes reliability and clear state management especially important.

Over time, we plan to use this DEV organization to share more about the technical side of building CryptoDeepApp — including API integrations, exchange workflows, infrastructure, monitoring, and blockchain data processing.

Learn More

CryptoDeepApp is available at:

https://cryptodeep.app

API documentation:

https://cryptodeep.app/api-docs

How the platform works:

https://cryptodeep.app/how-it-works

5 Lessons I Learned Building API-Driven Fintech Products

Jayden Cristian — Wed, 30 Sep 2026 21:37:35 +0000

Modern fintech products often look simple from the user's perspective: choose an asset, enter some details, confirm an action, and wait for the result.

Behind that interface, however, there is usually a lot of API orchestration, state management, error handling, and monitoring.

Here are five practical lessons I’ve learned while working on API-driven web products.

1. Treat external APIs as unreliable by default

Even a stable provider can experience timeouts, rate limits, delayed responses, or temporary outages.

Instead of assuming every request will succeed, design integrations with:

request timeouts
retries with backoff
clear error states
provider health checks
logging and monitoring

A failed API request should not automatically become a failed user experience.

2. Make state transitions explicit

For workflows that involve multiple steps, a clear state model makes the application much easier to maintain.

For example:

waiting → processing → sending → completed

Explicit states help both the frontend and backend understand what is happening and make debugging much easier.

3. Never trust only the frontend

Validation should exist on both sides.

The frontend improves user experience, but the backend should always validate:

required fields
supported assets or networks
numerical limits
addresses and identifiers
authorization
request integrity

Anything coming from the client should be treated as untrusted input.

4. Monitoring is part of the product

Logs are useful, but production systems need more than logs.

It helps to monitor:

API response times
failed requests
provider availability
error rates
background jobs
infrastructure health

The earlier a problem is detected, the easier it is to fix before users notice it.

5. Keep integrations isolated

When possible, avoid spreading provider-specific logic throughout the application.

A better approach is to create a separate integration layer:

Application → Internal Service → External Provider

This makes it easier to replace a provider, add another one, or change API behavior without rewriting the rest of the system.

Final thoughts

Building API-driven fintech products is less about making individual requests and more about designing for uncertainty.

Good architecture should assume that networks fail, providers change, data can be delayed, and unexpected states will eventually happen.

The more of those situations you handle intentionally, the more reliable the product becomes.