DEV Community: Dhiraj Chaudhry

Smart Contract Audits in the UK: What FCA-Adjacent Projects Need

Dhiraj Chaudhry — Mon, 18 May 2026 11:30:07 +0000

The UK's relationship with crypto has shifted considerably over the past two years. What was once a regulatory grey zone is now a structured environment where Web3 projects either align with the Financial Conduct Authority's expectations or risk being shut out of the market entirely. For founders building DeFi protocols, tokenisation platforms, or any product touching regulated financial activity, a smart contract audit is no longer optional. It's the difference between launching with confidence and launching with a liability.
This article walks through what FCA-adjacent projects actually need from an audit, what auditors look for, and how to prepare your codebase before bringing in a security reviewer.
Why the UK Market Demands More Rigorous Audits
The FCA doesn't directly certify smart contracts. What it does is set expectations around consumer protection, anti-money laundering controls, and operational resilience. When your protocol handles user funds, issues tokens that resemble securities, or facilitates payments, regulators look at your technical infrastructure as part of your overall risk profile.
A poorly audited contract is a regulatory red flag. It signals weak operational controls, which is one of the fastest ways to attract scrutiny or get denied registration. This is why working with an experienced smart contract auditor early in the development cycle matters more in the UK than in jurisdictions with lighter oversight.
What FCA-Adjacent Projects Typically Include
Projects that fall into the FCA's orbit usually share a few characteristics. They custody user assets, they involve token issuance or transfer, they offer lending or staking returns, or they bridge fiat and crypto rails. Each of these activities introduces specific contract-level risks.
For example, a lending protocol needs airtight collateral logic and oracle handling. A tokenisation platform needs clean role-based access and transfer restrictions. A payment processor needs replay protection and careful handling of stablecoin approvals. A generic audit doesn't cut it for any of these. You need a reviewer who understands both the code and the regulatory shape of what you're building.
The Anatomy of a Proper Audit
A serious audit is not a one-day code skim. It's a structured process that typically runs across several phases.
The first phase is scoping. The auditor reviews your documentation, architecture diagrams, threat model, and the contracts in scope. If your documentation is weak, this is where you'll feel it. Auditors charge more, take longer, and miss context when they're forced to reverse-engineer your intent from the code alone.
The second phase is manual review. This is where experienced eyes go line by line looking for logic flaws, access control mistakes, reentrancy paths, integer issues, oracle manipulation vectors, and protocol-specific exploits. Manual review is where most critical bugs are caught, and it's the hardest part to automate.
The third phase combines static analysis and fuzzing. Tools like Slither, Mythril, and Echidna surface a different class of issues than human review. Good auditors use them as a complement, not a replacement.
The fourth phase, which the strongest teams insist on, is formal verification for critical invariants. If your protocol has properties that must always hold true, such as total supply never exceeding a cap or user balances summing correctly, formal methods can mathematically prove those guarantees rather than rely on testing.
The final phase is reporting and remediation. You get a report classifying findings by severity. You fix them. The auditor reviews your fixes. Anyone who skips the remediation review is selling you a checkbox, not a security service.
Common Vulnerabilities That Still Slip Through
Even in 2026, certain bug classes appear over and over in audited code. Reentrancy is still alive and well, particularly in protocols that integrate with external contracts they don't control. Access control mistakes, especially around upgradeable proxies, remain a top cause of high-severity findings. Oracle manipulation continues to drain protocols that use thin liquidity pools as price sources.
Newer categories have emerged too. Cross-chain message replay attacks, signature malleability in account abstraction flows, and unsafe assumptions about ERC-4626 vault accounting are all showing up in recent post-mortems. An auditor who hasn't been actively shipping work in the last twelve months will miss these. This is one reason founders increasingly look at active practitioners rather than legacy firms, and why platforms like Upwork have become a real channel for finding hands-on Solidity security reviewers.
How to Prepare Your Codebase
The cheapest way to get a good audit is to show up prepared. Freeze the code before the audit begins. Auditing a moving target is expensive and ineffective. Write thorough NatSpec comments on every external and public function. Include a clear specification document describing what each contract is supposed to do and what invariants must hold. Run your own static analysis first and fix the obvious issues so the auditor can spend their time on what actually matters.
Test coverage matters too. If your unit and integration test coverage is below eighty percent, auditors will assume you haven't thought hard enough about edge cases, and they'll be right. Tools like Foundry's invariant testing and Hardhat's coverage reports are now standard, and you can find working examples and templates on developer profiles like this GitHub.
What a Good Audit Report Looks Like
A useful report does more than list bugs. It explains the threat model the auditor worked from, the assumptions they made, and the areas they couldn't fully cover. It classifies findings by severity using a clear framework, usually Critical, High, Medium, Low, and Informational. Each finding includes a description, a reproduction path, an impact analysis, and a recommended fix.
The report should also include a section on code quality and architectural observations. These aren't bugs, but they often point to fragility that will become a bug six months later. Founders who only care about the Critical and High sections miss this, and then wonder why their second audit finds the same patterns dressed in new clothes.
Costs and Timelines in 2026
A meaningful audit for a UK-facing project typically runs between fifteen thousand and eighty thousand pounds, depending on codebase size and complexity. Lightweight reviews for small contracts can come in lower, and deep audits of complex DeFi systems with formal verification can run well into six figures. Timelines range from one week for simple reviews to six weeks or more for full protocol audits with remediation rounds.
Beware of pricing that seems too good. A two thousand pound audit is not an audit. It's a code review with a logo on it. If your protocol handles real user funds, the cost of cutting corners on security is always higher than the cost of doing it properly. You can compare structured audit packages and scopes through providers who publish their methodology openly, including options listed on profiles like dhirajlochib.com.
Choosing the Right Auditor for an FCA-Adjacent Project
Look for three things. First, recent work in your specific protocol category. A NFT auditor is not a DeFi auditor. Second, transparent methodology. If they can't tell you exactly what their process looks like, they don't have one. Third, willingness to engage with your regulatory context. An auditor who treats FCA considerations as someone else's problem will miss issues that matter to your compliance posture.
References matter too. Ask for sample reports. Ask which findings they're proudest of catching. Ask what they would have done differently on their last engagement. The answers tell you more than any marketing page will.
Final Thoughts
For UK and FCA-adjacent projects, a smart contract audit is part security exercise, part regulatory hygiene, and part founder due diligence. Done well, it surfaces problems before users do, gives regulators confidence in your operational discipline, and lets you ship with conviction. Done poorly, it's an expensive piece of theatre that protects no one.
If you're planning a launch in the next quarter and haven't started the audit conversation yet, start it now. Good auditors are booked out, and the worst time to find one is the week before mainnet.

The Web3 Recovery Bug Wasn’t in the Smart Contract

Dhiraj Chaudhry — Sat, 09 May 2026 06:41:29 +0000

I recently worked on a crypto recovery flow where users could recover tokens sent to the wrong chain or unsupported wallet/account setup.

At first, the flow looked simple:

Detect the user wallet
Select the chain
Select the token
Check token balance
Enter recovery address
Build recovery transaction
Let the user sign and recover funds

The smart contract side was not the hardest part.

The harder part was handling all the small assumptions around chains, token contracts, account factories, RPCs, and user expectations.

The problem with “same address, same wallet”

In EVM chains, the same address can exist across Ethereum, Polygon, BNB Chain, Arbitrum, Base, etc.

But that does not mean the account behaves the same everywhere.

One address can have:

a smart account deployed on one chain
no contract deployed on another chain
a different factory on another chain
token balance on one network
zero balance on another
different gas requirements
different token contract mappings

So this assumption is dangerous:

`// bad assumption
const account = await detectAccount(userAddress);

A better approach is always chain-aware:

const account = await detectAccount({
address: userAddress,
chainId: selectedChain.id,
rpcUrl: selectedChain.rpcUrl,
});`

It looks small, but this kind of difference matters a lot in Web3 apps.

The bug: hardcoded chain detection

One issue I ran into was factory detection being tied to the wrong chain.

The app was checking an older smart account factory using Ethereum mainnet logic, then applying that result to other chains like BNB.

That created a weird failure:

Ethereum detection worked
BNB recovery failed
balance checks looked inconsistent
the UI made it seem like the user had no recoverable funds

The fix was tiny: use the selected chain’s RPC when detecting the factory.

`const provider = new JsonRpcProvider(selectedChain.rpcUrl);

const factory = await detectFactory({
provider,
accountAddress,
chainId: selectedChain.id,
});`

The lesson was simple:

Do not let one default RPC quietly control multi-chain logic.

Token symbols are not reliable

Another problem was token mapping.

Users often say:

I sent USDT.

But “USDT” does not always mean the same contract address on every chain.

For example, USDT on Ethereum and USDT on BNB Chain are different token contracts.

So this is not enough:

`if (token.symbol === "USDT") {
// fetch balance
}

You need chain-specific token mapping:

const TOKENS = {
ethereum: {
USDT: "0xdAC17F958D2ee523a2206206994597C13D831ec7",
USDC: "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
},
bnb: {
USDT: "0x55d398326f99059fF775485246999027B3197955",
USDC: "0x8AC76a51cc950d9822D68b83fE1Ad97B32Cd580d",
},
};
`
The user sees a symbol.

The app must care about the actual contract address.

“$0 balance” is not always zero balance

This was another annoying edge case.

Sometimes the app showed $0 balance, but the real issue was not that the user had no funds.

It could be:

RPC rate limit
wrong chain selected
unsupported token contract
old factory mismatch
failed balance fetch
bad provider response
token list missing a contract address

Showing all of these as “0 balance” is bad UX.

A better pattern is to separate states clearly:

type BalanceState = | { status: "loading" } | { status: "success"; balance: string } | { status: "zero" } | { status: "rpc_error"; message: string } | { status: "unsupported_token" } | { status: "unsupported_chain" };

This makes debugging easier and prevents users from thinking their funds disappeared.

Keep signing local

For recovery flows, trust matters a lot.

Users are already nervous because money is involved. The app should be very clear about what happens locally and what goes to the backend.

My preferred approach:

backend can provide config
backend can provide supported chains/tokens
backend can prepare payload details
frontend handles wallet connection
signing stays local in the browser
sensitive signing material is never sent to the backend

The product message should be simple:

The app helps build the recovery transaction, but it does not custody your funds.

That line matters.

What I would do differently next time

If I were building this again from scratch, I would spend more time on the configuration layer before touching the UI.

Things I would define early:

supported chains
supported token contracts per chain
old vs new factory logic
RPC fallback strategy
balance state handling
account detection per chain
recovery failure logs
advanced debug info for support/admins

Most Web3 bugs are not dramatic.

A lot of them are boring configuration bugs with expensive consequences.

Final takeaway

The biggest lesson from this recovery flow was that a Web3 product can have clean contracts and still feel broken.

The smart contract may be correct.

But if the app:

checks the wrong chain
maps the wrong token
hardcodes the wrong RPC
hides real errors behind “$0 balance”
assumes addresses behave the same everywhere

then users will still think the product failed.

For multi-chain Web3 apps, the infrastructure around the contract is just as important as the contract itself.

Sometimes the bug is not in Solidity.

Sometimes it is just one hardcoded chain check.

How I Built a Production-Ready USDT Escrow System Using Solidity + Node.js

Dhiraj Chaudhry — Wed, 06 May 2026 07:19:33 +0000

Most blockchain payment tutorials focus only on sending transactions.

Production systems are very different.

A real crypto payment platform needs:

escrow protection
dispute handling
transaction consistency
wallet synchronization
backend reliability
scalable infrastructure

Recently, I worked on building a USDT-based escrow payment platform designed for secure global crypto transfers with real-time transaction processing and dispute protection.

My role:
Lead Full-Stack & Smart Contract Developer

Tech Stack:

Solidity
Node.js
PostgreSQL
Redis
web3.js
Docker
AWS
Next.js
Nginx

The goal was to create a secure payment infrastructure where users could:

send USDT globally
protect payments using escrow
handle disputes securely
process transactions reliably in real time

The biggest challenge wasn’t transferring crypto.

It was building a system that could safely handle edge cases at scale.

System Architecture

The platform was divided into two main layers.

Smart Contract Layer

Responsible for:

escrow custody
release conditions
dispute triggers
transaction state management
settlement execution

Backend Infrastructure

Responsible for:

transaction monitoring
authentication
wallet management
dispute workflows
payment validation
event synchronization

This separation improved scalability while keeping payment settlement transparent on-chain.

The Real Problem: Dispute Handling

Most escrow systems work correctly on the happy path:

Buyer pays
Seller delivers
Funds release

The difficult part is handling failures and disputes.

For example:

delayed blockchain confirmations
duplicate webhook events
wallet synchronization issues
conflicting transaction states
invalid delivery confirmations

To reduce inconsistent states, I implemented:

retry-safe transaction processing
backend-side validation checkpoints
time-locked escrow releases
blockchain event synchronization
transaction state verification

This significantly improved reliability during concurrent transaction activity.

Backend Scaling Challenges

Crypto systems generate asynchronous events constantly.

One transaction may trigger:

blockchain confirmations
websocket updates
webhook callbacks
database writes
user notifications

Without proper synchronization, race conditions appear quickly.

To improve consistency:

Redis queues were introduced
event processing was isolated
retry-safe workers were implemented
PostgreSQL transaction handling was optimized

This reduced duplicate transaction states and improved processing reliability.

Smart Contract Security

Security was one of the highest priorities during development.

Important protections included:

reentrancy prevention
restricted access control
transaction validation checks
safe withdrawal handling
escrow timeout protection

Every transaction state transition was validated before execution.

Frontend & Infrastructure

The frontend was built using React and Next.js with a component-driven architecture focused on maintainability and performance.

Frontend stack:

React
Next.js
Tailwind CSS
shadcn/ui

Infrastructure:

Nginx reverse proxy
Ubuntu servers
Dockerized deployment
Redis queue handling
PostgreSQL transactional storage

Monitoring:

Sentry
backend event logging
transaction monitoring systems

Lessons Learned

Building blockchain systems is not just about deploying smart contracts.

The hardest problems usually appear in:

backend synchronization
infrastructure scaling
transaction recovery
event consistency
production reliability

A secure Web3 platform requires strong coordination between smart contracts and backend infrastructure.

Final Thoughts

Building production-ready blockchain infrastructure requires much more than writing Solidity contracts.

Real-world crypto systems need:

scalable backend architecture
secure transaction handling
event consistency
infrastructure reliability

Projects like this taught me that production engineering is where most blockchain complexity actually lives.

If you're building infrastructure-heavy Web3 or backend systems, feel free to connect.

GitHub:
https://github.com/dhirajlochib

Upwork:
https://www.upwork.com/freelancers/dhirajlochib

blockchain #web3 #solidity #node