How to build a secure project. Free Guide
Read time: 7 - 10 minutes
3 - 6 month.
That’s how long your project will last until it gets hacked.
Let me be clear. Your project sucks at security. Yes, you heard that right. Everything you’re doing right now isn’t working. You will be hacked. Your project will be drained. You will lose money, time, and reputation.
Most people believe that some magic section in their documentation, called “Security Audits,” will save them from Lazarus or other skilled bug hunters.
Don’t be so naive. We are professionals. When we see that a project has gone through multiple audit rounds, our interest spikes—we want to find the critical vulnerability that no one else has spotted before.
“ Hackers want to take all your money. Hackers want to kill you. They don’t care “
But situation can be saved. There are approaches that work.
you want to make a huge cash, receive enormous amount of fees every day and become the wealthy man, you have to think differently. You must take different approach.
Let me show you how to do security correctly.
Part #1
“Success is a balancing act of risk and preservation. Protect first, expand second.”
Don’t be the type of founder who rushes to build a project the moment Bitcoin hits $100K. It will be painful—if not now, then soon.
Yes, the market is growing, and those who build now and survive will become millionaires. But with the current state of security, 8 out of 10 projects will disappear because they’ll get hacked.
Let me show the statistic.
In 2024, 7 out of 10 project which made an audit was hacked. Interesting, isn’t it?
It is terrible numbers. But we live in the tough world. Run or die. If you can’t protect what you have, someone will take it. It is a rule.
You probably asking yourself, why it happens? “Security doesn’t work?”, “There is so many non-professional companies?”, “Who made the mistake, protocol or auditors?”.
Here is some food for thought.
It is just small part of the iceberg, but it already shows a lot.
Projects tends to collaborate only with 1-3 security firms. They want to save money, working only with someone who they know.
No consistent security practice. Let’s be honest, few of the projects implement audits after some feature upgrades.
” It costs money. Why do we need to pay 5k$ for some 200 nSLOC upgrade? ” Everyone from the list above thought in a such way………
You see? You see that? No, it is not enough. Take a look on these projects
Socket Tech. 3.3m$ loss due to adding new, vulnerable module where the arbitrary call can be executed.
Abracadabra money. 6.4m$ loss due to only one security review *even with the strong team.
WOOFi Finance. 8.5m$ loss. Only 2 security review were done…
“Do you recognize yourself? Not yet? In time, you’ll be on the list with these guys too.”
Part #2
All kidding aside, now i want to talk about specific things.
You are reading it not to stop building, but with perspective to build more projects, run them successfully and securely.
Here is your gold time. Pay attention to the information you're about to see. Write it down, save it, send it to your developers. It is your holy book.
DDR Rule
Secure development approach
Secure deployment approach
Secure running approach.
There are core entities that your project will run through. If some mistakes will be made during these stages, you will be fucked up.
“Right now, i will guide through each step of “DDR Rule” and point to the each pitfalls and how to avoid them.”
Secure development approach
IN HOUSE SECURITY
Do you know what differentiate alpha project from the usual one?
Alpha projects do security in-house.
There is few of them. I can count by fingers.
Let’s take for example ZkSync blockchain. They run security in house.
It is the foundation on which everything described below will be layered
If you think developers will build the project, security experts will verify it, and you'll end up with a flawless, secure product—hate to break it to you, but that’s not how it works.
Better security awareness your developers have, better outcome you will have.
“While developing, knowing what the project should do is just as important as knowing what it shouldn’t do.”
Very rarely developers can fully understand the second part of the sentence.
Let’s quickly talk about an in-house security lead. They don’t just review code—they lead the team, teaching developers that every line of code can be a risk. A security lead is responsible for:
Organising brainstorm sessions
Teach developers security
Consult and review the code.
Okay. You don’t have the security lead, and potentially you don’t plan to hire.
How to handle security in house alone? It is ever possible?
Yes. And here is how.
Do brainstorm sessions. Do it often! Make it as a “must have”.
Developers must forget about “building stuff” for some time. They must concentrate on how to “break the stuff”. Indeed, even if they know the codebase very well, it will be hard for them. But it takes some time to get used to.
1️⃣
First, define the contract’s entry points—this is where attackers will focus. You should already have well-documented actors who interact with the system; this is your starting point.
Next, prepare a brainstorming template covering:
Who are the actors? List every entity involved in the logic.
What are their goals? Define their intended outcomes when interacting with the contract.
How do they interact? Map functions, document interactions, and track execution flow.
Once the flow is fully understood, add relevant code snippets for clarity. Then, proceed to the brainstorming session.
2️⃣
Let the minds enter the flow, crazy ideas should constantly appear in your mind. Don’t think in the scope of the project itself, expand the view on blockchain, integrations, malicious users.
The “What if?” question must fly in the air. Be as creative as possible.
Which crazy inputs user can provide? What can it lead to? Can it help bypass the checks?
What if user will be malicious smart contract? Can he exploit the function?
Is there assumptions about external responses? Can they be manipulated somehow?
Job of security researcher consist of such brainstorms. We are constantly asking ourselves what non-intended inputs we can provide and what it can lead to.
““Brainstorms are crucial. It is “must have” practice during development.””
3️⃣
Brainstorms + checklists.
During brainstorms you must be prepared with necessary information, which will not only help you to generate ideas, but also to fuel them.
It is advised to utilise the security checklists.
Checklist that save 2$k on audit.
Eventually, how to organise such sessions correctly?
Each week, make a “security day”.
Run multiple brainstorming sessions and notify developers in advance so they can review security checklists relevant to the project.
1h - 1.5h: Let developers generate as many "What if?" scenarios as possible.
Pause (30-40m)
1h - 1.5h: Push their thinking further—"What if?" again.
Finally, analyze ideas, discard invalid ones, and test those with exploit potential.
By the end, you should have a security documentation—a structured list of all critical checks, requirements, and protections.
Test coverage
Brainstorms worth nothing, if it doesn’t result in comprehensive testing.
You must remember, the basic test coverage is “empty sound” for the security researcher.
Basic tests doesn’t (*or very rarely) cover the complicated attack vectors.
Yes, you've already tested access control logic, zero deposit, and other baby scenarios, but you haven't explored the "what-if" scenarios yet.
Without the brainstorm sessions it is not possible to test you contracts thoroughly, simply because you don’t have the fuel, for such tests.
Thorough testing is what sets a solid protocol apart from a naive one. If you'd like a free checklist of the top 7 most useful Foundry commands, you can find it here: (link)
Sub-topic: YOUR DESIGN IS WRONG
There is no limit to perfection. During the development phase it is never late to slightly redesign the system.
Code simplicity
More invariants your project has , more vulnerable it is.
Don’t fall into the trap. More good intentions you have, the more easily to break you.
Your brilliant idea about some new features can turn into hell. Integrations, leveraging liquidity can lead to the disaster.
Simple code = less vulnerable code = good reputation = more users = more liquidity = more fee
What is better? Short term hype around super-mega cool projects with all possible integrations and all existing DeFi mechanism’s?
Or solid, well-tested code with only necessary functionality?
Writing simple code is hard. But here are a few habits to avoid over-engineering:
🔹 Revisit the code constantly. Question everything—even if you’ve seen it 100 times. That’s the golden rule of a security researcher.
Ask yourself:
What does this line do? Is it necessary? Can it be refactored?
Can I simplify this function? Is there a cleaner way to handle this flow?
What invariants exist? Can some be removed or clarified?
Do I need this check? Or is it redundant?
Can I reuse existing functionality instead of writing new code?
Developers should build the habit of questioning everything. It could save you thousands of dollars in the long run.
“ I don’t state, that developers must become a security auditors in one day. They need at least try to think like security guys ”
Separated Liquidity
It is new era, era of L2’s and new blockchains.
Cheap gas allows to approach project structure differently. In the past, high gas fees made every transaction matter. Now that gas costs are lower, developers can focus on liquidity segmentation instead of pooling everything together.
Many hacked protocols face a complete liquidity drain due to a single vulnerability. This shouldn't be the case.
Specific example:
Recently, “Arsen Security” analyzed the MonoX hack, which led to a $31 million loss. If you have some free time, you can check out the full analysis here. However, I'll break everything down for you below. [link]
In short, the contract logic allowed tokenIn and tokenOut to be the same token during a swap. This meant, for example, that you could swap WETH for WETH, which eventually led to abnormal price inflation.
The MonoX used single virtual pool, instead of “pairs”, like Uniswap does.
Overall, price manipulation of one token, affected the entire system.
It could be prevented, by utilising fund isolation:
Create different contract instance’s for each pair, logic.
Utilise “create” , “create2” opcodes.
“Arsen Security” conducted private audit of the re-staking protocol on Base. It followed the security recommendation and designed the “fund-isolated” system.
The separate “markets” exists for different loanToValue, which result in the staking amount being diversified across different pools, reducing the single point of failure.
Additionally, the classical “individual token pair” approach, like the one used by Uniswap, can also serve as an example.
Overall, fund isolation is not something new. It is already battle tested design approach, which works well.
However, once the protocols try to reinvent the wheel (*code simplicity one more time), they become more and more vulnerable.
Don’t be MonoX. Simplify the logic, isolate the funds.
Pausibility & Upgradability mode
Don’t ever, ever think about skipping the proxy or not implementing Pausable functionality.
What will you do when the critical will be found, and it is already 100k$ of user’s liquidity? How will you handle the transition?
What will you do once you note the active exploit will take place? Correct. You will just observe how your reputation and money fly away.
The key takeaway is that your code must be time-tested. It’s impossible to guarantee bug-free code, even with five audits.
Security is an ongoing process.
Even you read and think like “Oh, man, what do say is so evident”.
But if you are so smart, try to implement the pausability and upgradability patterns correctly, with no bugs.
No one is smart enough.
Arbitrum paid 8 million bounty for un-initialised contract.
Seneca protocol was hacked, and it couldn’t pause the contract because they have not override the _pause function.
Devil is in the details. Don’t be so confident.
Third part integrations:
I enjoy it. I'm curious. I'm excited to work with projects that integrate with other systems—there are so many bugs to find and so much money to be made.
There is nothing bad in leveraging project’s liquidity by integrating other protocols.
“Projects integrate protocols but ignore the integration issues, where the real problems are.”
I don’t know what are in the 99% developers heads, but it seems that they are lazy enough to spend couple hours for reading the docs and source code of the integrated protocol.
If you can just imagine, how much integrations issues are in my audit portfolio…
Let’s take an example.
This vulnerability helped me to secure Top-7 spot on “Olas” competition.
But don’t be scare enough. Here is a brief question’s checklist that would help you to find your next integration issues.
Which protocol am I integrating with, and what common issues might arise during the process?
What specific functionality am I integrating, and what is its main purpose within my project?
What components make up this functionality, and how do they interact with my project?
Which parts should I focus on carefully based on the documentation?
Is there a way for an attacker to manipulate any of these components? What would be the potential consequences?
Can any functions within the integrated protocol interfere with or modify the behavior of my implementation?
Could specific actors within the integrated protocol impact my project in unintended ways? If so, how?
Are there alternative ways to implement this functionality? How do they compare in terms of security, efficiency, and complexity?
Secure Deployment approach
What we've discussed so far are in-house practices. Now, you're presenting your project to the world.
Don’t hurry. Before opening it to users, you must conduct thorough security audits, and here's the tricky part.
As we have seen in the beginning, one, two or even three different security audits by different firms is not enough. There should be a strategic attitude.
How strong, time-tested projects approach security?
Here is audit reports of the AAVE V2. Do you see it? 5 audits from different firms. Feel free to refer back to statistic and make your own judgment…
Let’s consider another example: Pendle Finance. It underwent 8 audits, 5 of which were conducted by private auditors.
“More audits you have conducted, more tightly you can sleep”
There are plenty solo auditors who are provide same, or even better audit quality than some popular security firm.
For sure, most of the projects don’t have so much money to conduct multiple audits from the best firms or the best hackers in the industry.
However, you should aim for the minimum audit standard that can make your project 99.9% secure.
Here the structure of base minimum, if you really care about long run.
Internal Review. Conducted by the projects developers. We have discussed it already.
First Review. Conducted by the strong, solo auditor.
Second Review. Conducted by the strong pair of auditors
Third Review. Conducted by the reliable audit firm.
Fourth Review. Public competition on the popular platform(C4, Cantina, Sherlock)
Fifth Review. Bug bounty launch on Immunefi.
Why the hell do i need 5 audits?
Real Critical’s are very rarely found during the security reviews. Especially in the first stages.
Let me explain why.
🔹 First Round – Solo auditors catch obvious and moderately complex bugs. The sheer volume of issues scatters focus, making deep criticals harder to find.
🔹 Second Round – A duo of auditors pushes harder, hunting for hidden flaws. With fewer distractions, they can explore complex attack vectors. If they struggle to find bugs, that’s a good sign.
🔹 Third Round – A top-tier audit team reviews previous findings like a seasoned mentor. This phase uncovers deeply buried vulnerabilities that earlier rounds missed.
🔹 Fourth Round (Competition) – Open the review to as many experts as possible. Competitive environments drive auditors to dig deeper. A sharp-eyed researcher may spot a high-severity issue overlooked before.
🔹 Fifth Round (Bug Bounty) – A healthy practice. White hats prefer ethical rewards over exploits. A well-structured bounty program ensures critical bugs surface before black hats take advantage.
Bottom Line: If budget is tight, merge rounds two and three—but always prioritize strong auditors. A well-structured security process minimizes risks and keeps you off the Hall of Shame.
“The info i described above can looks overwhelming for your budget. However, the actual exploit and reputation loss will be even more overwhelming.”
I help every of my client to approach the audit strategy correctly.
I guide them what next steps they need to implement. What firm to choose, what contest platform to pick.
If you want receive free consultation “How to receive best security services, and don’t overpay”, i encourage you to book a free consultation
Secure running approach
Don’t be sure that once you go live, all the problems will disappear.
Imagine, you want to add some new feature, or upgrade existing logic.
It is ok, all project are constantly developing, battle tested Uniswap V2 is far away in the past, we have already V4.
It is all about business, isn't it?
On this step we will return back to place where we come from.
Security, security and one more time, security.
Protocol upgrade must be taken even with more cautious that initial building, right now you already have huge liquidity.
You don’t want to be an idiot who wrecked the protocol by your own hands.
Upgrade
New smart-contract logic, you notified user’s about new upgrade. What’s next?
Ensure that all works as expected. ****
Testing framework is your best friend.
Care about storage layout. Many issues happen there. OpenZepellin Upgrade Plugins can help you during the testing it.
Test. Test integrations. Test events. Be sure you are not idiot.
Ensure previously supported logic behaves correctly.
Security review. Yes, one more time. And not only for the upgraded part of the code, but one more time, for the whole system, however, make sure the auditors are clear that the main goal is to test the upgrade integration. (*As much review as possible is better. But it’s enough for now.)
Live monitoring
These technologies definitely worth to be implemented.
Potentially, they can be your live saver.
On-chain monitoring tools observe blockchain activity in real time, identifying various types of transactions and events.
There are different tools that you can utilize,
OpenZeppelin Defender
Phalcon by BlockSec
Forta firewall.
To ensure the monitoring tool works as expected, you must define clear rules that align with your protocol's logic and functionality.
Top 5 activities you want to monitor in your smart contract
Do someone interacts using the flashloan?
Depositor originated from Tornado Cash?
Strange balance fluctuations?
Sudden pice spikes of the Oracle Feed?
Interaction with the Admin privileged funcitons?
However, most of the standard monitoring tool can be hard to customised.
Each contract must be adjusted towards individual monitoring rules
During the security reviews, ask the auditors to help you with that.
They know code well, they know the invariants well.
Auditors can prepare necessary conditions that worth to be monitored.
There is never enough security. All systems are broken. Bugs are everywhere. Sometimes it cost couple hours of fixing. Sometimes it cost millions or even billions.
Less naive you are, less likely you will be fucked by hackers.
Everything cost money. Pay now, or pay later.
Thank you for reading, I hope it helped.
