From empty repository to mainnet in ten days: a market-data platform and post-quantum wallets for a new blockchain
A digital-asset market-data start-up.
- Scale
- 10 days to launch, 3 independent capture regions, ~70-step release gate, 2 post-launch redesigns
- Engagement
- 26 October to 4 November 2026 to mainnet launch (10 days), then continuous releases and managed operations
The challenge
A new blockchain was about to switch on native tokens, NFTs, an on-chain market and a decentralized exchange at one fixed block height. The client wanted the market's reference screen, where traders check prices, charts, liquidity and token safety, to be live and correct from the first block, with wallets that keep keys in the browser and resist harvest-now-decrypt-later attacks. The deadline was set by a block rather than a calendar, history could not be recovered later, and the budget meant modest cloud machines with no exposed servers.
A new blockchain was about to switch on native tokens, NFTs, an on-chain market and an exchange at a single known block height. The client, a digital-asset market-data start-up, wanted the place where traders check prices, charts, liquidity and token safety to be live and correct from the first block, together with wallets that hold keys in the browser and resist harvest-now-decrypt-later attacks. Our senior engineers took the product from an empty repository to mainnet in ten days, and the work is real, not illustrative. They used AI-assisted, human-in-the-loop practices from Claude: parallel work on separate branches, every change reviewed and merged by a senior engineer, every release behind the automated gate and every change to live infrastructure approved by a person first. People decide and sign off; the assistance adds speed. Before the real chain, we ran a private copy of it on our own hardware, with traffic bots and injected faults such as cut connections, a stopped archiver and a replayed reorganization.
The architecture is raw first, derived second. A Rust archiver stores every block's raw bytes, payloads and replaced blocks permanently, and a Rust indexer applies each block to a PostgreSQL database in one transaction, so a block is counted completely or not at all and a reorganization is rewound block by block. A transaction of an unknown shape marks that one block for review instead of stopping the platform. Token images are served only if their hash matches the hash recorded on chain, so nobody can swap a logo after the fact.
Redundancy is built in. Three independent capture points in three regions each run their own node and archiver, so losing a machine or a region loses no data. Serving runs on a primary and a warm standby, and every release goes to the standby first and can be rolled back in one step. No server has a public address: traffic arrives through a tunnel, and administrators reach machines only over an encrypted WireGuard mesh. Three monitoring layers watch the heartbeats, and a real fault phones the on-call engineer. Backups go to write-once offsite storage under client-side encryption.
Speed was measured, not assumed. On a synthetic test database of 100 million trades (160 GB) the slowest heavy query took 37.7 seconds before tuning and 39 milliseconds after, about 970 times faster. On a database of 1 million tokens and 10 million trades, screener lists answer in 3 to 50 milliseconds and a token page in 1 to 3. The look of the product moved as fast: a researched palette, a dense terminal layout, a dark theme with a market heat map and phone and tablet boards, four design versions in two weeks, each kept in version control so the client could switch back.
Security followed the same rule as speed: nothing is waived. The wallets keep keys in the browser, protect the vault with Argon2id, summarize every signing request in plain words and flag look-alike and imitation tokens. Direct messages use a hybrid ML-KEM-768 and X25519 exchange. About seventy automated steps run before any release, and audit rounds alternated with fix rounds. After launch the design team shipped two further redesigns without taking the site down. Load figures come from a test network and synthetic data, not from production traffic.
What our team delivered
- A raw-first design: a Rust archiver stores every block's bytes, payloads and replaced blocks permanently, and a Rust indexer builds a PostgreSQL database that can be rebuilt from that raw store at any time
- One writer and one transaction per block, so a block is applied completely or not at all and a reorganization is rewound block by block
- Three independent capture points in three regions, each with its own node and archiver, plus an outside public node used only for cross-checking
- A primary and a warm standby for serving, with every release checked on the standby first, switched atomically and reversible in one step
- No server with a public address: traffic arrives through a Cloudflare tunnel and administrators reach machines only over an encrypted WireGuard mesh
- Three monitoring layers so no single failure silences them all, including a per-minute edge check that phones the on-call engineer
- A mempool archive that records every pending transaction with its outcome, in hash-chained segments copied to write-once offsite storage
- Query tuning measured on a synthetic database of 100 million trades: the heaviest query went from 37.7 seconds to 39 milliseconds, and list pages answer in 3 to 50 milliseconds
- A Chrome/Brave extension and a built-in browser wallet sharing one core written in Rust and compiled to WebAssembly, with hybrid ML-KEM-768 + X25519 messaging, Argon2id vault protection and plain-language signing prompts
- A release gate of about 70 automated steps (unit, API, real-browser, visual, security and Rust tests) that is fixed, never waived
Result
The reference screen was live and correct from the first block of the new features, with every block and every pending transaction preserved in three regions. The platform runs on a few modest cloud machines, has no exposed servers, calls a person when something is wrong, and was redesigned twice after launch without downtime. Load figures come from the test network and synthetic databases, not production traffic.
What a trader sees
| Pair | Price | 24 h | Volume |
|---|---|---|---|
| Asset A / Base | 1.0842 | +4.2% | 2.1M |
| Asset B / Base | 0.2210 | -1.8% | 880K |
| Asset C / Base | 12.480 | +9.6% | 5.4M |
| Asset D / Base | 0.0391 | -6.3% | 310K |
| Asset E / Base | 3.7150 | +0.7% | 1.2M |
| Asset F / Base | 0.8820 | -0.4% | 640K |
A market-data platform with no single point of failure
Three independent capture points record the chain in three regions, a primary and a warm standby serve visitors behind an edge network with no exposed servers, archives go to write-once storage, and three monitoring layers make sure no single failure can silence the alarm.
From 37.7 seconds to 39 milliseconds
Measured on a synthetic database of 100 million trades (160 GB) on the test network: the slowest heavy query of a market-data screener took 37.7 s before tuning and 39 ms after, about 970 times faster. For scale, list pages on a synthetic 1‑million-token, 10‑million-trade database answer in 3 to 50 ms and a token page in 1 to 3 ms. The time axis is logarithmic. Load figures come from the test network and synthetic data, not from production traffic.
Four designs in two weeks
The design team's iterations for a market-data product, from the first palette on 26 October to the phone and tablet boards on 8 November. Every version was kept in version control so the client could switch back; the dense terminal layout became the only interface within three days, and the next two redesigns shipped without taking the site down.
A hybrid post-quantum TLS handshake
The client offers X25519MLKEM768, which pairs a classical X25519 exchange with ML-KEM-768 from FIPS 203. The server encapsulates to the client's ML-KEM key, both sides join the two secrets and feed them to HKDF, and an attacker has to break both algorithms to read recorded traffic later.
Facing something similar?
Tell us about your environment. We will tell you plainly what we would do and what it would take.