Case Study Details
Client: Early-stage Web3 startup (name withheld under NDA)
Industry: Web3 / DeFi
Service: Web3 & Blockchain Engineering
Engagement length: 5 weeks audit + remediation, plus mainnet launch support
The Problem
They came to us with a mainnet launch date already public and a contract they believed was ready to ship. The core smart contracts — handling user deposits, staking, and reward distribution — had been built roughly a year earlier by a freelance developer who was no longer reachable. There had never been a formal, independent audit. The team's internal confidence came mostly from the fact that the contracts had been running without incident on testnet, which, as their technical co-founder later admitted, had given them a false sense of security.
"We'd been testing it for months and nothing had gone wrong, so we assumed it was solid. What we didn't understand is that testnet doesn't try to rob you. Nobody's incentivized to find the holes until real money is sitting there."
A prospective investor doing technical diligence ahead of a funding round asked a simple question the team couldn't confidently answer: had the contract ever been professionally audited? It hadn't. That question was the reason they reached out to us, with a launch date roughly a month away and real user funds about to flow through code nobody had independently verified.
What We Did First: Full Audit Before Touching Anything
We treated the existing codebase as untrusted until proven otherwise, which is the only responsible starting point for a contract that's about to hold real funds. Our audit process combined automated static analysis with manual, line-by-line review from engineers experienced specifically in the failure patterns that have caused major losses across the industry — reentrancy, access control gaps, unchecked external calls, and flawed reward-accounting logic being the categories we scrutinize most closely, since they account for a large share of real-world exploits.
The audit surfaced several issues of varying severity. Two were serious enough that, left unaddressed, they could have allowed a bad actor to drain funds from the contract under specific conditions. We don't detail the specific mechanics of vulnerabilities we find in our case studies, even resolved ones — the responsible practice in this industry is to describe impact and remediation, not to publish exploit details, even after a fix is live. What we can say plainly: these were not exotic, theoretical issues. They were the kind of flaws that show up regularly in post-mortems of real hacks, and they were present in code that was weeks away from holding user funds.
We delivered a full written audit report to the team within the first week, categorized by severity, with each finding explained in plain language alongside its technical detail — so their team understood not just what to fix, but why it mattered.
What We Built
Rather than patching individual lines around the existing structure, we made the call to rebuild the highest-risk sections of the contract from the ground up using established, battle-tested patterns rather than custom logic reinvented from scratch. In security-critical code, "clever and custom" is a liability, not a feature — the safest contract logic is usually the logic that has already been used, attacked, and hardened across thousands of other deployments.
Specifically:
- Rebuilt the fund-handling logic using well-established, widely-audited patterns for deposits and withdrawals, rather than the original custom implementation.
- Tightened access control across all administrative functions, closing gaps where permissions were broader than they needed to be.
- Rebuilt the reward-distribution accounting to eliminate the rounding and ordering issues the original implementation had, which could have caused incorrect payouts under real-world usage patterns.
- Added circuit-breaker functionality, giving the team the ability to pause specific contract functions in an emergency without needing a full contract migration — a safety net the original version had no equivalent of.
Every change was accompanied by an expanded automated test suite, including tests specifically designed to try to reproduce the original vulnerabilities and confirm they were actually closed, not just theoretically patched.
Supporting a Secure Launch
We didn't hand back a fixed contract and step away. We pushed the revised contracts to testnet again, ran an internal re-audit against our own fixes — treating our own work with the same scrutiny as the original code — and only then supported the team through a phased mainnet deployment: an initial launch with a deposit cap in place, monitored closely for the first 72 hours, before the cap was lifted once behavior in production matched expectations.
We also recommended, and helped coordinate, a follow-up audit from an independent third-party firm after our remediation was complete — deliberately not just taking our own word for the fix. That's a step we recommend on every security-critical engagement, because a single audit team, however careful, is still one perspective.
The Impact
- Launched on a revised but still tight timeline, without the deposit-related incidents, the original contract had been vulnerable to
- The independent third-party audit came back clean, with no critical or high-severity findings — validating both our remediation and the team's decision to invest in the extra scrutiny before going live
- Zero fund-related security incidents in the period since launch
- The prospective investor whose diligence question started this whole process completed their investment, citing the completed audit trail as a key factor in their confidence
"We almost launched without knowing what we didn't know. The scariest part looking back isn't what they found — it's how close we came to finding out the hard way, with real users' money on the line instead of in an audit report."
— Technical Co-Founder
This case study reflects a real client engagement. The client's name and identifying details have been withheld in accordance with a confidentiality agreement; the Technical Co-Founder's title is used in place of a name for the same reason. Specific vulnerability details have been withheld as a matter of responsible security practice.