Fintech & crypto
Systems where a bug costs money directly. Custodial wallets, multi-chain infrastructure and payment integration, built with the accounting discipline that makes them auditable.
- 01Custody, which means being responsible for other people's money
- 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
Custodial wallets
Key handling 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. Here 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
Seedit is a multi-chain crypto tipping bot for Telegram. Every community member gets a custodial wallet, 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 we will ask you
Two questions, early. Who is legally responsible for custody, 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.