Fintech & crypto
Systems where a bug costs money directly. Wallet infrastructure, multi-chain systems and payment integration, built with the accounting discipline that makes them auditable.
- 01Holding keys and balances on behalf of other people, without ever losing either
- 02Chain reorganisations, dropped transactions and confirmations that never arrive
- 03Balances that have to reconcile exactly, forever, across every path
- 04Each blockchain having its own model, fee mechanics and failure modes
- 05Payment providers whose retries will double-charge if you let them
Wallet infrastructure
Key handling, key export and balance management for large user bases, with the operational procedures around them.
Multi-chain architecture
A chain-agnostic core with per-chain adapters, so a new chain is an adapter rather than a fork.
Idempotent accounting
Append-only ledgers and idempotency keys, so a retried callback or a double tap never moves money twice.
Payment integration
Card providers and crypto side by side, with reconciliation against the provider rather than trust.
High-volume messaging
Queue-based processing that survives a chain going quiet and then delivering everything at once.
Correctness before features
In most products a bug is an annoyance. In a system that holds money it is a balance that is wrong, and every hour it stays wrong makes it harder to unwind. That changes how the system gets built: the ledger is designed before the features, every external call assumes it will be retried, and reconciliation runs whether or not anyone is watching.
None of this is exotic. It is ordinary discipline, applied consistently, which is mostly a matter of deciding to do it at the start rather than after the first incident.
What we have built
A multi-chain crypto wallet for Telegram communities. Every member gets a wallet whose private keys they can export at any time, and tipping, airdrops and peer-to-peer trading happen with a single chat command. It runs across TRON, Ontology, Binance DEX and Solana from one codebase, built as a monorepo splitting a chain-agnostic core from the Telegram layer, on Node.js with Postgres, Redis and RabbitMQ.
More than a million wallets were created across the network. At that volume the interesting problems stop being blockchain problems and start being queueing, idempotency and support-load problems.
What do you need from us before any code?
Two answers, early. Who holds the keys, and what happens when a user disputes a balance? If neither has a clear answer yet, that is the first thing to fix, before any code.
Tell us the one thing it has to do.
If it's sharp enough to prove in a week, we'll say so and give you a date. If it isn't, we'll tell you that too, along with what we'd build first instead.