Case study — Flashy Finance
A rail under inherited code, not a rewrite over it
- Scale
- Three repositories, each carrying inherited 2022–2023 source alongside a new rail-first module — landed as open branches awaiting human review.
- Legacy archives kept as provenance
- 7, across 3 repositories
- Tests passing across the three new rail-first modules
- 135 (52 + 43 + 40)
- Staking tiers published
- 4
The challenge
Three legacy projects arrived as zip archives: an original username-resolution contract and client, a staking front end for two chains, and a bridge whose relayer server signed transactions with its own held private key — the exact self-built-bridge design the group’s own security posture refuses. Rewriting any of them to be audit-ready before shipping anything would mean waiting on an audited on-chain contract for every feature. The alternative was to keep the inherited code as provenance, prove it safe to keep rather than merely describe it as safe, and put a small new surface in front of it that works today against infrastructure the platform already trusts.
The approach
Scan the committed bytes, not the file names or a description of them
Each repository’s credentials.test.mjs runs on every push as a CI gate, not a documentation claim. It walks every tracked source file for credential shapes — a PEM private key, an AWS or Google API key, an Infura project id in a URL — refusing to pass on an empty walk, then opens every committed .zip and reads every member byte-for-byte, nested archives included. It found a real one: the previous owner’s Infura project id, live in a commented-out provider in life-platform/src/App.js and compiled into the built bundle’s source map. It was blanked in the source and left, documented as burned, in the archive — because emptying a committed secret is not rotation, and the archive is the record of what arrived.
Build the new surface beside the old code, never through it
None of the three new modules — StakingService in life-staking, the purchase flow in life-username-platform, BridgeRouter in life-bridge — imports the inherited Solidity or React source. Each depends only on a small RailPort interface matching Flashy Rails’ real RailsClient method-for-method, with an InMemoryRailPort standing in for tests and demos; swapping the real client in changes nothing above the call site.
Earmark rather than move, until the audited chain path exists
Flashy Staking’s four published tiers — flex-30 at 3% APR, standard-90 at 6%, loyalty-180 at 10%, loyalty-365 at 15%, each with its own minimum — lock Gold the rail has already credited without moving a ledger entry; only the yield, paid at close, is a real write through the rail’s earn(). Flashy Bridge’s router refuses every execute() unconditionally today, because the one audited WDK bridge protocol evaluated so far names mainnet chains only and no testnet route exists yet to exercise it against.
The outcome
All three modules pass their own test suites in full — 52 tests in life-staking, 43 in life-username-platform, 40 in life-bridge — and all three landed as open branches, each ahead of main by a handful of commits, awaiting the same human review and merge every cross-org connection on this platform requires before it becomes real. The inherited archives — seven of them across the three repositories — stay committed as provenance, scanned on every push, edited by nobody.
The platforms this evidences
Considering something similar?
The capability above is licensable independent of this engagement — see the platform page for what is and is not white-labelled.