iBoost/Portfolio/Crypto Gateway

Fintech·2026 — now

Crypto Gateway

Custodial multi-chain crypto payment processing: a unique deposit address per invoice, automatic sweeps to the mother wallet, and genuine double-entry accounting.

Our role

Specification, architecture, core, audit

Status

Active development

Period

2026 — now

Platform

Merchant API · dashboard · workers

FINTECH Crypto Gateway 01Invoice anddepositaddress02On-chainpaymentdetection03Sweep to themother wallet04Postings andfeerecognition05Merchantpayout TYPESCRIPT · NODE 18+ · POSTGRESQL 16 · REDIS 7 · VITEST · TRON · TON · EVM IBOOST.UA · 2026 — now

System map · internal perimeter, access under NDA

01

What it is

Crypto processing is not “accept a payment”. It is accounting. Every coin that arrives must be recorded simultaneously as an asset at our address and as a liability to the merchant; every fee must be recognised at the right moment; every payout must be reserved so a parallel request cannot spend the same funds twice. A one-character error in a posting formula costs real money.

So before the first line of code, the specification went through a cold multi-agent audit: five document revisions, real defects found in the canonical postings, a double debit corrected, account classes separated. Platform fees are recognised at sweep — when funds are final — rather than at “paid” status on funds a reorg can still reverse.

02

capabilities

What it does

01

A unique address per invoice

Every payment gets its own deposit address; address statuses are terminal and reuse is forbidden.

02

Multi-chain

USDT on TRON, TON and Ethereum, plus native BTC, ETH, BSC, Polygon, Solana, TRX and XRP. USDT first.

03

Real double-entry

A chart of accounts with asset and liability classes, canonical postings for every event, and materialised balances written in the same transaction as the posting.

04

Atomic payout reserve

An available / pending / locked balance model with row locking. Two parallel payouts cannot spend the same balance.

05

Isolated signer

Keys live in a separate service with a signing policy and idempotency. Key isolation is proven by its own test in the suite.

06

Merchant SaaS layer

Registration, organisations and roles, KYC/KYB, test and live modes on every money table, payout address whitelists, signed webhooks with SSRF protection.

03

architecture

How it works

01

Invoice and deposit address

02

On-chain payment detection

03

Sweep to the mother wallet

04

Postings and fee recognition

05

Merchant payout

Under the hood

  • An npm-workspaces monorepo: ledger, assets, apiauth, chain-adapters, secrets, db, obs — each package with its own tests.
  • Invariants are severity-classified: P0 means loss of funds or key theft and blocks the release; any doubt is a stop.
  • The asset registry verifies decimals on-chain — configuration is not trusted.
  • Reversible secret storage in a KMS envelope instead of hashes.
  • The chain adapter interface is frozen — adding a network does not touch the core.
  • vitest against a live PostgreSQL; typed end to end, with no `any` on money paths.
TypeScriptNode 18+PostgreSQL 16Redis 7vitestTRON · TON · EVMHD-кошельки

04

scale

Numbers

9

networks in the model

5

spec revisions before code

P0

invariant class that blocks release

2

modes: test and live