DEV Community: CryptoDeepApp

Modeling Blockchain Deposit Workflows with a State Machine in Node.js

Jayden Cristian — Fri, 30 Oct 2026 17:51:24 +0000

The duplicate delivery problem

Imagine a Node.js worker processing a blockchain deposit confirmation. It receives an event, updates a swap to exchange, and schedules the next operation.

The worker commits the update—but crashes before acknowledging the message. The queue delivers the event again. Another observer might even publish a new event ID for the same deposit confirmation.

If the handler simply performs an update and queues another job on every delivery, one deposit can trigger multiple exchange operations.

This is why idempotency matters: processing the same logical action more than once should not create additional business effects.

In this tutorial, we'll model two separate protections:

Event deduplication: recognize a delivery that has already been recorded.
Business idempotency: recognize that a workflow has already performed the requested transition, even when a new event ID is used.

We'll add a transactional outbox so the state change and the intention to perform the next operation are committed together.

Scope: This is a standalone educational example, not CryptoDeepApp's production architecture. A dependency-free in-memory model lets us test the behavior; a separate MongoDB adapter illustrates durable multi-document transactions. We do not connect to blockchain nodes or send real funds. Confirmation events are assumed to come from a trusted verifier that already checked the chain, destination, asset, amount, and confirmation/finality policy.

Two identities, two different jobs

A delivery ID and a business-operation ID are not interchangeable.

Identifier	Example	Purpose
Event ID	`chain-watcher:event-001`	Detect replay of the same delivered event
Deposit reference	`btc-mainnet:tx-abc:vout-0`	Identify the specific on-chain transfer
Workflow ID	`swap-42`	Identify the business process being updated
Outbox operation ID	`start-exchange:swap-42`	Prevent scheduling the same logical next operation twice

A transaction hash alone may be insufficient to identify a deposit. Bitcoin transactions can have multiple outputs; other chains may require a log or instruction index. The example treats depositRef as a prevalidated, chain-specific identifier.

Consider this already-observed deposit:

const workflow = {
  id: 'swap-42',
  status: 'deposit',
  depositRef: 'btc-mainnet:tx-abc:vout-0',
  amountUnits: '12500000', // Integer base units, never a floating-point amount.
  revision: 3,
};

const event = {
  eventId: 'chain-watcher:event-001',
  workflowId: 'swap-42',
  type: 'DEPOSIT_CONFIRMED',
  depositRef: 'btc-mainnet:tx-abc:vout-0',
  amountUnits: '12500000',
};

The workflow has already reached deposit: funds were observed, but the application's confirmation policy was not yet satisfied. A verified DEPOSIT_CONFIRMED event may move it to exchange.

We deliberately do not allow that event to jump from waiting or overdue straight to exchange. If a late deposit appears, its observation and any required review belong to a separate step.

Why a processed-events check alone is not enough

This code has a race condition:

// Unsafe pseudocode — don't use it as an idempotency guarantee.
if (!(await processedEvents.findOne({ eventId }))) {
  await updateTransaction();
  await processedEvents.insertOne({ eventId });
}

Two workers can both read "not processed" before either inserts anything. And if the first update succeeds but the process crashes before inserting the receipt, the next delivery repeats the update.

A durable design needs database-enforced uniqueness and an atomic relationship between receiving an event, changing the workflow, and recording the next action.

Build a testable model in plain Node.js

First, we'll make the behavior easy to test without MongoDB. Create idempotent-events.mjs:

// Educational in-memory implementation; NOT durable or distributed.
export function validateEvent(event) {
  if (!event || typeof event !== 'object' || event.type !== 'DEPOSIT_CONFIRMED') {
    throw new TypeError('Expected a DEPOSIT_CONFIRMED event');
  }
  for (const field of ['eventId', 'workflowId', 'depositRef']) {
    if (typeof event[field] !== 'string' || !event[field].trim()) {
      throw new TypeError(`${field} must be a non-empty string`);
    }
  }
  if (typeof event.amountUnits !== 'string' || !/^[1-9]\d*$/.test(event.amountUnits)) {
    throw new TypeError('amountUnits must be a positive integer string');
  }
}

export function fingerprint(event) {
  return JSON.stringify([
    event.type, event.workflowId, event.depositRef, event.amountUnits,
  ]);
}

export function planDepositConfirmation(workflow, event) {
  if (!workflow) throw new Error('Unknown workflow; reconcile before acknowledgement');
  if (workflow.depositRef !== event.depositRef ||
      workflow.amountUnits !== event.amountUnits) {
    throw new Error('Deposit identity or amount mismatch; needs reconciliation');
  }
  if (workflow.status === 'deposit') return 'advance';
  if (['exchange', 'sending', 'success'].includes(workflow.status)) {
    return 'already-applied';
  }
  throw new Error(`Cannot confirm deposit from status ${workflow.status}`);
}

export class InMemoryStore {
  #data;
  #tail = Promise.resolve();

  constructor(workflows = []) {
    const keyed = new Map();
    for (const workflow of workflows) {
      if (keyed.has(workflow.id)) throw new Error('Duplicate workflow ID');
      keyed.set(workflow.id, structuredClone(workflow));
    }
    this.#data = { workflows: keyed, inbox: new Map(), outbox: new Map() };
  }

  async transaction(fn) {
    // Serializes calls in THIS Node.js process. Not a real database transaction.
    const previous = this.#tail;
    let unlock;
    this.#tail = new Promise((resolve) => { unlock = resolve; });
    await previous;
    try {
      const draft = structuredClone(this.#data);
      const result = await fn(draft);
      this.#data = draft; // Simulated all-or-nothing commit.
      return result;
    } finally {
      unlock();
    }
  }

  snapshot() {
    return structuredClone(this.#data);
  }
}

export async function processDepositConfirmed(store, event) {
  validateEvent(event);
  const identity = fingerprint(event);

  return store.transaction(async (data) => {
    const previous = data.inbox.get(event.eventId);
    if (previous) {
      if (previous.fingerprint !== identity) {
        throw new Error('Event ID reused with different payload');
      }
      return { outcome: 'duplicate-delivery' };
    }

    const workflow = data.workflows.get(event.workflowId);
    const plan = planDepositConfirmation(workflow, event);
    data.inbox.set(event.eventId, { fingerprint: identity, outcome: plan });

    if (plan === 'already-applied') return { outcome: plan };

    const operationId = `start-exchange:${event.workflowId}`;
    if (data.outbox.has(operationId)) {
      throw new Error('Outbox operation already exists; reconcile conflict');
    }
    data.workflows.set(event.workflowId, {
      ...workflow, status: 'exchange', revision: workflow.revision + 1,
    });
    data.outbox.set(operationId, {
      id: operationId,
      type: 'START_EXCHANGE',
      workflowId: event.workflowId,
      status: 'pending',
    });
    return { outcome: 'applied', operationId };
  });
}

There are three important decisions in this code:

A repeated event ID returns duplicate-delivery. If the same ID appears with different meaningful fields, the handler rejects it rather than silently trusting the new payload.
A different event ID describing a confirmation already reflected by the workflow returns already-applied. This prevents a second business transition.
The workflow state and a uniquely named outbox record are written in the same simulated unit of work. Errors discard the draft instead of leaving half-applied changes.

The model serializes simulated transactions inside one process. It does not provide persistence, cross-process locking, crash recovery, or database isolation. Its purpose is to verify the rules before translating them to real storage.

Test duplicates and concurrent deliveries

Node.js includes a built-in test runner. Create idempotent-events.test.mjs:

import test from 'node:test';
import assert from 'node:assert/strict';
import { InMemoryStore, processDepositConfirmed } from './idempotent-events.mjs';

const workflow = {
  id: 'swap-42', status: 'deposit', revision: 3,
  depositRef: 'btc-mainnet:tx-abc:vout-0', amountUnits: '12500000',
};
const event = {
  eventId: 'chain-watcher:event-001', workflowId: 'swap-42',
  type: 'DEPOSIT_CONFIRMED',
  depositRef: 'btc-mainnet:tx-abc:vout-0', amountUnits: '12500000',
};

test('replayed event does not create another outbox operation', async () => {
  const store = new InMemoryStore([workflow]);
  const first = await processDepositConfirmed(store, event);
  const replay = await processDepositConfirmed(store, event);
  assert.equal(first.outcome, 'applied');
  assert.equal(replay.outcome, 'duplicate-delivery');
  assert.equal(store.snapshot().outbox.size, 1);
});

test('a new event ID cannot repeat the business transition', async () => {
  const store = new InMemoryStore([workflow]);
  await processDepositConfirmed(store, event);
  const second = await processDepositConfirmed(store, {
    ...event, eventId: 'chain-watcher:event-002',
  });
  assert.equal(second.outcome, 'already-applied');
  assert.equal(store.snapshot().workflows.get('swap-42').revision, 4);
});

test('25 concurrent deliveries still schedule one operation', async () => {
  const store = new InMemoryStore([workflow]);
  const results = await Promise.all(Array.from({ length: 25 }, (_, i) =>
    processDepositConfirmed(store, { ...event, eventId: `source:event-${i}` })
  ));
  assert.equal(results.filter(r => r.outcome === 'applied').length, 1);
  assert.equal(store.snapshot().outbox.size, 1);
});

Run:

node --test idempotent-events.test.mjs

The downloadable example includes 19 unit tests. All passed on Node.js 22.16.0. They also cover missing workflows, mismatched deposit references, changed amounts, invalid states, conflicting event IDs, and simulated rollback. These are in-memory behavioral tests—not MongoDB integration tests or throughput benchmarks.

Move the guarantee into MongoDB

For a real multi-worker service, the uniqueness and atomicity must be enforced by a shared durable store.

A possible MongoDB data model is:

workflows
  _id: swap-42
  status: deposit
  revision: 3
  depositRef: btc-mainnet:tx-abc:vout-0
  amountUnits: "12500000"

event_inbox
  _id: chain-watcher:event-001
  fingerprint: [canonical event fields]

event_outbox
  _id: start-exchange:swap-42
  type: START_EXCHANGE
  status: pending

MongoDB provides a unique index on _id by default. That gives us uniqueness for event receipts and outbox operation IDs. A conditional update can additionally check that the workflow still has the expected status and revision.

The official MongoDB Node.js driver supports withSession() and withTransaction() for operations that need to commit across multiple collections. Here is the core pattern, with validateEvent(), fingerprint(), and planDepositConfirmation() imported from the previous example:

export async function processDepositConfirmedMongo(client, db, event) {
  validateEvent(event);
  const fp = fingerprint(event);
  const inbox = db.collection('event_inbox');
  const workflows = db.collection('workflows');
  const outbox = db.collection('event_outbox');

  try {
    return await client.withSession(async (session) =>
      session.withTransaction(async () => {
        await inbox.insertOne({
          _id: event.eventId,
          fingerprint: fp,
          workflowId: event.workflowId,
        }, { session });

        const workflow = await workflows.findOne({ _id: event.workflowId }, { session });
        const plan = planDepositConfirmation(workflow, event);
        if (plan === 'already-applied') return { outcome: plan };

        const result = await workflows.updateOne({
          _id: event.workflowId,
          status: 'deposit',
          revision: workflow.revision,
          depositRef: event.depositRef,
          amountUnits: event.amountUnits,
        }, {
          $set: { status: 'exchange' },
          $inc: { revision: 1 },
        }, { session });
        if (result.modifiedCount !== 1) {
          throw new Error('Concurrent state change; retry or reconcile event');
        }

        const operationId = `start-exchange:${event.workflowId}`;
        await outbox.insertOne({
          _id: operationId,
          type: 'START_EXCHANGE',
          workflowId: event.workflowId,
          status: 'pending',
        }, { session });
        return { outcome: 'applied', operationId };
      }, {
        readConcern: { level: 'snapshot' },
        writeConcern: { w: 'majority' },
      })
    );
  } catch (error) {
    if (error?.code !== 11000) throw error;
    // A unique-outbox collision is NOT necessarily a duplicate event.
    const existing = await inbox.findOne({ _id: event.eventId });
    if (!existing) throw error;
    if (existing.fingerprint !== fp) {
      throw new Error('Event ID reused with different payload');
    }
    return { outcome: 'duplicate-delivery' };
  }
}

This adapter is an architectural illustration; it was not integration-tested against a MongoDB instance. It requires a supported MongoDB deployment for multi-document transactions (typically a replica set or sharded cluster), appropriately provisioned collections, and a compatible official Node.js driver.

The important properties are:

Insert an inbox receipt with a unique event ID.
Validate the existing workflow and perform a compare-and-set update using its status and revision.
Insert a uniquely identified outbox operation in the same transaction.
Commit them together—or roll them all back.

The driver can retry transaction callbacks for certain transient errors. For this reason, do not call an external exchange, send a notification, or transfer funds inside the transaction callback. Such a side effect could run again even if the database work was rolled back and retried.

An outbox record is not an exactly-once payout

The outbox solves a specific failure window:

Database commit succeeds
        ↓
Process crashes before publishing next job

Because the intended next action is already stored in event_outbox, another worker can discover it later.

However, that worker could send a request to an external provider, lose the response, and retry. A unique outbox record prevents the creation of duplicate logical jobs, not necessarily repeated external execution.

A production outbox consumer needs an atomic claim/lease strategy, recovery from expired claims, bounded retries, and a stable operation ID. Whenever possible, the external provider must support an idempotency contract for that ID. Otherwise, the worker needs an explicit reconciliation path before attempting the side effect again.

Do not describe this combination as universal "exactly-once delivery." The realistic goal is at-least-once delivery with idempotent effects where the contracts permit it.

Edge cases worth designing before production

Same event ID, different payload. Treat this as an integrity conflict. A replay must not silently redefine the amount or deposit reference.

Same deposit, different event IDs. The inbox cannot catch this by itself. Your workflow transition and unique business-operation key must prevent another exchange from starting.

Out-of-order events. If a confirmation arrives before the deposit is associated with a workflow, don't pretend the transition is valid. Retry, reconcile, or investigate according to the system's event-ordering guarantees.

Reorganizations and reversals. A confirmation policy is chain-specific. A reorg or revoked upstream event may need a separate compensating workflow; the code here does not implement that.

Multiple valid deposits. Never assume one transaction hash means one transfer. Multiple outputs, transfers, or partial deposits need explicit models and reconciliation rules.

Inbox retention. Deleting old receipts changes what can be recognized as an identical delivery. Plan retention relative to replay windows, and keep independent business-level guards.

Transaction conflicts. A failed conditional update or duplicate outbox ID might be a concurrency conflict, not a safe duplicate. Log it with the relevant IDs and retry or reconcile according to a bounded policy.

Performance. Multi-document transactions and indexes have costs. For simpler problems, an atomic single-document update can be sufficient. Use a transactional outbox when multiple collections must commit together.

Key takeaways

Idempotency is not just an if check in a message handler.

Use event IDs to deduplicate exact deliveries.
Use business identifiers and state guards to prevent repeating the logical operation under a new event ID.
Enforce critical invariants with unique indexes and conditional writes.
Use a transactional outbox when the state update and next-action record must commit atomically.
Assume the worker or provider can retry; exactly-once external effects are not guaranteed without an appropriate downstream contract.
Test duplicate, concurrent, conflicting, and out-of-order inputs—not only the happy path.

A duplicated event should be uneventful. Getting there requires clear identities, explicit state rules, and storage guarantees that survive more than one process.

References

AI disclosure: This educational draft and its sample code were prepared with AI assistance. The in-memory example passed local tests; the MongoDB adapter has not been validated against a live database. Review and adapt the material before publication.

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

DEV Community: CryptoDeepApp

Modeling Blockchain Deposit Workflows with a State Machine in Node.js

The duplicate delivery problem

Two identities, two different jobs

Why a processed-events check alone is not enough

Build a testable model in plain Node.js

Test duplicates and concurrent deliveries

Move the guarantee into MongoDB

An outbox record is not an exactly-once payout

Edge cases worth designing before production

Key takeaways

References

Handling Cryptocurrency Amounts in JavaScript Without Floating-Point Errors

Why a small rounding error matters

Store amounts in the smallest unit

Why BigInt is useful

Build two small utilities

Add amounts without floating-point math

Rounding is a business rule, not a formatting trick

Keep JSON boundaries explicit

Test the edge cases

Common mistakes worth avoiding

Key takeaways

References

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

Instant Crypto Swaps

Fixed and Floating Rates

Floating rate

Fixed rate

Solana Token Analyzer

Portfolio Tracking

API Integrations

Affiliate Tools

Building the Platform

Learn More

Why `BigInt` is useful