Instead of giving you the usual AI slop opener (like most of you do...) I would rather jump strait into the bugs. Enjoy:

Redstone going back in time

When working with Redstone (not the minecraft one) you will most likely use the pull based mechanics (else you would use ChainLink), like this one:

Pretty simple. Users can updatePrice with the new prices in msg.data, which getOracleNumericValuesFromTxMsg uses to verify and return the price. Since Redstone validates that the data must be at least 3 min old (and no more than 1 min into the future) we don't need any validations here.

However there is still an issue here. We can travel in back and forth in time (figuratively speaking).

Since we do no checks here, we can technically update the price to be up to now, then update it again to be now - 3min. For example:

1. ETH is 3k at T = now (I wish D:)

2. Borrower borrows up to their max

3. Liquidator updates the price to be 2.9k for when T - 3min

4. Liquidates the user

The current price was $3000 and our borrower should not be liquidatable, but we did liquidate him.

Staking feeds

Some projects use interesting token connections. For this example our project was lending/borrowing and 2 of the assets were BTC and UNI.

At first it sounds really simple, just denominate BTC in UNI, or UNI in BTC and decide how much each costs compared to the other. However that is not so simple, since ChainLink does not have a feed that reports BTC price in UNI, or UNI price in BTC. It has BTC/ETH and UNI/ETH.

So we must use 2 feeds, why is that a problem? It's not if you know how to handle it (as every issue out there). However it is if you didn't know about it.

The problem here is that 2, or in our case 3 feed wBTC -> BTC -> ETH -> UNI. We start with wBTC → BTC, because we are on ETH and don't have access to BTC directly and shouldn't assume 1 BTC == 1 wBTC.

The deviation threshold expands with each feed. Where in total we would have 4.5% deviation:

• wBTC/BTC - 0.5%

• BTC/ETH - 2%

• UNI/ETH - 2%

Where that becomes a problem?

When you don't know that the total deviation can stack and set too tight liquidation margins. With a 4.5% compounded deviation (4% more realistically since BTC doesn't often deviate from wBTC), the oracle price can be up to 4.5% stale compared to the real market price in either direction.

This creates two problems:

1. Phantom solvency — A borrower whose position is underwater at real market prices still looks healthy to the protocol because the oracle hasn't crossed its deviation threshold yet. By the time the feed updates, the position is deep in bad debt and liquidators can't cover it profitably.

2. Wrongful borrowing — A user deposits collateral and the oracle overvalues their collateral relative to the market. They borrow more than they should be able to. When the next update lands, they're instantly liquidatable.

The worst part is that neither are an "attack", but can and will happen on occasion.

The fix is really simple. Make sure you check all deviations and lower the LTV by them. Also I will recommend to not allow borrowers to borrow up to the max LTV, but leave a gap (so they won't get liquidated in the next update).

The boring one

See anything interesting here? Yes? No?

I had to include it. It's 2026 and even now I see people do it... AI knows to not write it like this so why do developers do it?

If you don't know what I am talking about it's the fact that feed may have different staleness timestamps. Some might have a few hours and others 24h. However if you use 1 for all, then you are either using stale data (for feeds that have smaller time allowance than the one you give) or marking perfectly fine data as stake (for feeds that have bigger allowance).

The solution? Just use a map and set each feed to it's own staleness.

Pyth confidence

We are back to Pyth and it's "mysterious" ways of working. Most people will assume since Pyth is instant, and they are pulling the price themselves, that the price is what it's returned. Simple right?

Not exactly. Pyth has confidence (unlike you) where the confidence is a +/- bracket where the price can be.

Simplest example is when you get the price of ETH at $2000 and Pyth returns $2000 with confidence of +/- 50. Now the price can be 2k, or 1950, or 2050, or 1967 (1969 for you old folks...). Ok, ok, but what's the issue here?

The issue is that your project will assume the price is X and allow things to happen based on that X price, be it a liquidation, or allowed borrowing, or let you 50x on your YES position on "will dickbut will rise by 6.7% by the end of week" (I spend too much time on X D:).

Where in fact the price was not X, but X+y or X-y... So how do you fix it?

Assume the worst case scenario. When borrowing the project should assume the coll token price is X-y and the borrow token price is X+y, aka. always favor the project over the user.

1 USDC/USDT == 1 USD

Did you happen to use stablecoins in your vault? If so how do you price them? Of course it's 1$, it's a stable coin after all! Why would you need a oracle for it?

It's 2026 and bugs like this still exist (some Morpho vaults can confirm).

The problem here is that you are either skipping an oracle all together or using one that essentially hardcodes the vaults of stable coins to 1 USD. And don't get me wrong, this will work 99.99% of the time, however when it fails is when you will get wrecked.

The correct way to do it is to assume everything will change it's price some time in the future. Assets will rise and fall in value, stable assets will depeg, everything that can happen will.

oracle setups that require 2+ feeds but also need to support single-feed assets like rETH → ETH

Only for builders

Building anything that deals with oracles?

If you have a mainnet launch, upgrade, or token event in the next 60 days and your contracts haven’t been re‑audited, you’re running on luck.

Book a security audit review call with us here:

https://phagesecurity.com/request-audit

or hit me up in my TG at @Pyro3b.

What I would say is to audit while hot, so go and increase your AC temperatures, because it will help!

go on, do it before you continue reading, just trust me

...

Now for all of you who trusted me, thanks... and never trust anyone (especially me) because that's not what I meant by auditing hot.

By auditing hot I mean to have X time of auditing (be it a few hours or a day or 2) before you are "hot", and when you are hot you would notice an improvement in your ability to understand and break code.

Sales

This may seem a bit off topic, but trust me it's important to know it.

In sales you have the term "hot" and it's when your sales guy gets into the mood of selling and he is performing at it's best. His close rate increase, by 20%, 30% sometimes 50% or even 2x and he becomes a "selling machine".

But why is that?

There are multiple factors and multiple prerequisites in order for this to happen, each playing a different role. But it usually goes like:

1. Bob has a good sales call, he feels confident in the product and himself

2. He tries to sell the product a bit more, he asks more questions and fights more no's

3. Bob gets the sale

4. Bob is now even more confident in what he is doing, he truly knows he is doing gods work

5. You can notice that in the tone he uses, the words, the amount of questions he ask, the hunger to make the sale

Where am I getting with this...?

Well it is the same here, usually how it goes is:

1. You find something interesting

2. You think it's an issue and you start diving deeper

3. You find a High or an interesting Med and adrenaline hits you

4. You are now more curious and start looking further and further

5. You find a few more interesting edge cases, the spiral continues

Sounds familiar ?

Do you know how to ruin your streak? Take a break after the first finding since "you've earned it". And if you are the one that would take the break, then try not to do it

Taking a few days off

Similarly you may have noticed that if you break your audit with a break for 2 or maybe 3 days then the code feels off, the issues don't pop out, you are slower or even tired. You think to yourself "I've already looked at this" or even if you dive deeper it still takes you more time (to find something interesting) than before the break.

Maybe it's my terrible memory, but if you have felt this after taking a few days off then you know exactly what I mean. The context you built up in your head - the relationships between contracts, the assumptions you were questioning, the edge cases you were tracking - all of it fades. And rebuilding that context is never as fast as building it the first time.

But do you know what the worst part is? Some of those questions you had in mind before the break, you may have explored them to a point and your brain will think they are answered... however that is never the case. The hard to find, interesting bugs come from constant back and forth pushing between you and the code.

You go for the bug, but X stops you, you try another path, but Y stops you, you try to configure Y and move past it and you do, but Z stops you... The difference between finding something rare and thinking this path is secure is the ability to push forward, challenge obstacles and overcome them.

A junior will check and step after the first require or if. A senior will always try to find a way to move past it. And due to this "break" your brain may think that since X was there then this bug is invalid...

So the advice here is simple. Don't take multi-day breaks during an active audit. If you have a 2-week audit, treat it like a 2-week sprint, not a marathon with rest stops. The "hot" state is fragile, and a 3-day break in the middle can cost you more time than the break saved you.

How to take a break

So I just told you not to take breaks, but let's be real... You probably can't audit for 2 weeks straight without breathing (unless you are like me of course, cuz I am better). You are a human, not a machine. So how do you take a break without killing your streak?

Half days.

Wake up early, get your focused hours in while your brain is fresh and you actually have the will to do it. This is when you are sharpest. No distractions, no fatigue, just you and the code.

After that, the rest of the day is yours. Go outside, touch some grass (or women, consensually of course), do whatever you want. If someone sends you a message you can always respond, but don't go opening Cursor and start verifying that edge case "real quick". That's not a break, that's a half ass audit session.

Why mornings? Because your brain is fresh and you actually want to work. Try auditing at 9pm after a full day of hiking or going out. You'll be reading the same function 3 times and still not getting it. Your focus is a limited resource, spend it when you have the most of it.

Finding bugs

This is where it all comes together.

When you find your first bug in a codebase, something shifts. Before that first finding, you're reading code. After it, you're hunting. The code is no longer "probably fine", it's proven to be breakable. And if it broke once, it can break again.

That's the confidence boost that makes you hot. You stop giving the developer the benefit of the doubt. You stop skimming over that weird edge case because "they probably handled it". You start pulling on every thread because you've already proven that threads lead somewhere. You start digging deeper and deeper and maybe coming back to old invalid issues with a new knowledge of how everything moves around.

The more bugs you find, the hungrier you get. Bug number one makes you curious. Bug number two makes you suspicious. By bug number three you are looking at every function like it owes you money. The code didn't change, you did.

This is why auditing while hot matters so much. It's not about being smarter or knowing more. It's about being in the state where your confidence and curiosity are both maxed out, and every line of code feels like it's hiding something from you.

So what do you do with this?

Next time you find something interesting, don't reward yourself with a break. Reward yourself by going deeper. That first finding is not the finish line, it's the starting gun.

Stay in the code. Stay suspicious. Stay hot.

Because at the end of the day, it's not how many bugs you find. It's how many are left after you.

Thanks for reading this far and as always a shameless plug:

Founders and builders if you are looking for an audit you can check us out at: https://phagesecurity.com/

Both of them are wrong.

If you audit too early, you are paying for feedback on code that might change next week. The report doesn't provide a lifetime guarantee. If you launch without one, the market will audit for you and cost you your TVL.

This binary view of security, where you are either "audited and safe" or "unaudited and reckless," is the biggest driver of preventable hacks. Security is not something you only care about right before launch. It is a maturity curve that has to grow alongside your product from the ideation phase to full grown protocol.

This article is the roadmap for the security evolution that needs to take place in every Web3 project.

## The Maturity Levels

## Level 0: The Prototype

You're early and still working on the overall architecture of your project and how you want it to look. The product surface is still being explored and discovered. Your team is learning what should be on chain vs off chain, what should be configurable, what your immediate priority is, and what is still experimental. Clarity is what matters the most in this stage.

Your job here is to get a clear understanding of your system on:

• The core user flows

• How funds and critical states change

• What assumptions you are making

Write those as a living doc the team updates as the project evolves. This is also where you list likely "future upgrades" so you are prepared and making adjustments for them.

This is also the stage where many people forget about basic key management. While some devs are actively committing secret API keys or private wallet keys to GitHub, others are using their degen wallet to deploy their app. It's fine if it's just your closed-source beta, but some tend to forget and run with it until someone catches it.

When to level up: When the core architecture stops changing every week and you are building something you can stabilize, test, and review seriously.

## Level 1: Launch Hygiene

As you grow from the basic MVP to adding more features, you enter Level 1. It is the phase where you are continuously working on programming and adding new features to your smart contract. Your codebase is getting bigger, as is your attack surface.

It is also the phase where you need to focus on extra work making the code clean, stable, and understandable. Most early hacks are not sophisticated ones; they come from minor mistakes that were overlooked because of messy code where basic behavior is unclear, edge cases are not considered, and intent is not documented for every new feature that is added.

- Complexity hides bugs — Develop the habit of refactoring code, using clean naming and proper structure. Simplicity is crucial when coding in any language, especially when deploying on the EVM where hacks are everywhere.

- Pick proven patterns — and well-used libraries, especially for sensitive stuff like auth, roles, and upgrades. OZ and Solady exist for a reason.

- Write a small set of tests — that prove the core flows work as intended and that the obvious fail cases revert. Simple function tests without malicious intent (deposit, claim, withdraw), simple user paths (deposit => withdraw, stake => claim => withdraw), and basic access control checks.

- Treat deploy and admin keys as high risk — You don't need a multisig yet, but keep them separate from everyday wallets. If the key you deploy with is the same one you're aping memecoins with, you have a problem.

The goal here is not to be sure there are no vulnerabilities in your codebase. It is to make sure your codebase and your approach are solid, so when the time for deeper testing comes, the team doesn't waste time on basic stuff.

When to level up: When the code is stable enough that you can freeze scope for a bit and start trying to break it on purpose.

## Level 2: Audit Ready

Now that the scope is stable enough, the team can perform various in-house tests and call for an external auditor to review the security implementation. Security in this level should be thought about from the perspective of an attacker who would be trying to make your code do unintended things.

- Document the attack surface — Have a clear understanding of which parts of your product are most likely to be prone to security threats. Document the flows, assumptions, edge cases, and failure scope. If you are doing integrations, make sure you've followed their best practices and thoroughly read their docs.

- Add fuzzing and invariant tests — on the modules that matter most. Coverage is an inaccurate stat. It simply determines if your tests go through a given path, skipping the fact that you might have tested it wrongly or with the best possible conditions. 100% coverage of happy path tests is worse than 50% coverage that actually tries to break your protocol.

- Implement mutation testing — where it fits, so you can prove your tests actually catch broken logic. Mock tests will give you mock results. Stick to the real implementations.

- Work closely with integration partners — to validate your assumptions by reading their docs and, if possible, getting the team to sanity-check your integration. If you are doing heavy integrations, reach out to them, they know their code best and have seen many projects integrate beforehand.

- Run an internal review — where devs are actively trying to break the product they make. They are the ones who know their code best. Set a time window that would force about 300-400 nSLOC per day. During that time, the only goal is to break code. Don't fix bugs the moment you find them; make GitHub issues and continue breaking.

Only after you have done your tests and reviews do you pay for an external audit.

With your internal testing, you should now have a properly defined scope for the external audit. Get only logic contracts in scope. Interfaces can be removed to reduce the nSLOC and the price. The external audit works best when you have reduced most of the noise and are letting experts focus on breaking your assumptions and finding edge cases that you somehow missed.

One more thing, the firm doesn't do the audit, the auditors do. Brands are a big thing in cybersecurity, but the brand is 80% client communication and 20% delivering results. Most firms work with contractors, the same team of 3 can be one price at firm X and 2x more expensive at firm Y, for the exact same guys. Look at the individual auditors, their contest wins, their past experience, and ask for people familiar with the project type you are building.

When to level up: You have a final report. You ship the reviewed version, resolve meaningful findings properly, and the product version that is live is the one you audited.

## Level 3: Production Hardened

Level 3 is the shift from "securing smart contracts" to "securing the protocol" as a whole. You are live, you are seeing your product used and functioning exactly as intended, and nothing is breaking. Now that your code is secure, your team is growing, and the attack surface is not just the code but the entire system.

This is where the biggest failures stop being purely contract mistakes and start being control failures. It's about securing the humans, the machines, and the procedures.

- Introduce multisigs — and move ownership and high-stakes operational powers behind them. High-impact changes like upgrades, treasury moves, and role changes should require a higher threshold. Require hardware wallets for all signers.

- Allow single roles to pause — Create friction and stop attackers. It is easier to explain downtime to users than to explain why their funds are gone.

- Simulate before signing — Develop a habit of transaction simulation and avoid blind signing for high-value actions. Spoofing happens quite a lot.

- Treat your frontend, DNS, and dependency chain as part of the protocol — One hijacked domain or poisoned dependency update can drain users even when the contracts are fine.

This is also the phase where you start having real social media and community presence. As the team grows, this opens up possibilities for social engineering attacks. It is necessary to have your entire team be very informed about these types of attacks, as the trust of your entire protocol lies there too. It is very common for attacks to originate from a team member who got compromised. Assume the worst and have processes for it.

When to level up: When you have good security policies in place and weird behavior triggers a calm process, not chaos. You can coordinate quickly, execute safely, and ship fixes without worsening the problem.

## Level 4: Continuous Security

Now, security is part of the process and not some sort of milestone you are trying to achieve. With every new change and every new update, you follow the security procedures to keep the whole system free from security threats.

However, as you ship changes regularly and the integration surface keeps expanding, drift becomes the main enemy. Small changes over time can create blind spots, and eventually, something might slip through. Level 4 is all about not letting that happen, or catching it before it causes any big damage.

- Continual internal reviews and a retainer with external auditor — to make sure every new update or feature you ship is audited and safe. Move from "one-off audits" to a continuous relationship. A retainer is cheaper than scrambling for availability before every release.

- Active automated monitoring — of on-chain and off-chain changes, splitting the alerts by team and authority level. Implement monitoring that alerts you to invariant violations (e.g., solvency check fails) rather than just "large transactions." Consider building a bot that can automatically pause the contract if it detects a critical invariant failure.

- Introduce a bug bounty program — so any security researcher can have a crack at your system and notify you about any flaws before threat actors find them. The more eyes, the better. A $50k bounty is cheaper than a $10M hack.

- Keep a lightweight integration drift check — so when oracles, bridges, routers, or other key partners change behavior, you re-validate your assumptions.

Monitoring here doesn't mean alert on everything. It's about sending the right info to the right person or team so they can react in time and aren't buried in noise all the time. This is where good teams start catching problems in private, through follow-up reviews, bounties, and monitoring, instead of learning the hard way in public.

Building a vault

1. First depositor attack

2. Being first pays too well

3. Front running bad debt

4. Gaming the lock up with 1 wei

5. How dust becomes insolvency

Integrating with Vaults

1. Your withdraw order is killing your yield

2. convertToAssets + convertToShares == wrecked

3. Tokens sitting there, unclaimed, forever

4. Idle assets are stealing yield from your users
   

Building a vault

1. First depositor

"I already know it", "will skip this part" is what you are thinking. Then skip the whole article dumbass, because I am not only gonna talk about the basic bug, but will also include it's other variants. Now with that attitude out of the way lets continue.

The most common attack for vaults, done when there are no virtual shares or offset mechanism. The main problem is how shares are calculated:

Solidity rounds down and if totalShares is really small (like 1 wei) and totalAssets bigger than assets, then shares will round down to 0.

The common patterns is:

1. Attacker deposits 1 wei asset for 1 share

2. Attacker sends 1000e18 assets to the vault

3. Vault share ratio is 1 share = 1000e18 + 1 assets

4. Victim deposits 1000e18 assets, gets minted 0 shares

5. Attacker's share is worth 2000e18 assets

Stopping points:

0 shares cannot be minted

Donate 51% of the victim assets in order for him to mint 1 share and you will steal 25% of his assets (2 total shares - 1500e18 total assets, 1 share is worth 750e18).

Vault does not track assets by balance - look around any find if there is a way to increase that variable without increasing the shares. Some interesting variations I've noticed trough the years are:

• deposit and round with down withdraw to receive less assets and increase totalAssets (repeat that a few dozen times)

• Liquidate your position so that you have less shares and the vault has extra assets (the vault had some extra functionality)

Offset of 1 with shares = assets * (totalShares + 1) / (totalAssets + 1) - The attack is no longer profitable, however the shares value can still be increased in order to grief the vault.

Bigger offset - Neither profitable, nor it changes the ratio that much, is not considered an attack.

Fix:
OZ have made a really simple and easy to implement fix which uses _decimalsOffset to make virtual shares. But basically you can redo _convertToShares and _convertToAssets to be:

2. Being first pays too well

The problem here is that most vault that distribute rewards do it time based (epochs or dripping), but they don't account for the fact that sometimes there may be no one to claim them (no depositors).

The common patter for this is:

1. Vault is creased and immediately starts distributing rewards

2. The first depositor/staker comes after X hours/days

3. No matter how much he stakes, since he controls 100% of the shares he gets all of the rewards for that X hours/days where there were no stakers

   
   

Stopping points:

They may handle this, but what if everyone leaves the vault for some time and one user deposits, will rewards be paused or will he receive all of them for that missed time.

Distributing rewards based on depositor enter time - what about the rewards that were generated when no one was in the vault, do they get stuck?

Fix:

There is no code specific fix as the issue is more of a design/business logic related. However structurally it should distribute rewards only when shares > 0 and track the start reward time the moment the first user joins.

3. Front running bad debt

If the vault has any external factors that will result in a profit or loss, but can't be put on chain with real time access, or can be observed before they happen, then share price can get MEVed.

This description complicates the issue a lot, but it comes to:

1. User1 will get liquidate and will result in bad debt for the vault

2. User2 front-runs the liquidation TX and withdraws

3. User1 is liquidated, lowering the share price from 1 to 0.9

4. User2 deposits again

User2 avoided the bad debt socialization and essentially MEV the vault in order to keep his assets safe from bad debt.

Stopping points:

Bad debt is not socialized - that's another issue. What happens to the losses if they are not accounted then they will lead to insolvency.

Fix:

If such events can be observed before they happen, then consider making users request to withdraw, followed by some time delay (1h, 24h, etc...), when after this time they will be able to withdraw.

4. Gaming the lock-up with 1 wei

Deposit -> your assets are locked up -> after T time you can hold or instantly withdraw. The most common issue I've noticed with vesting is that the vest is usually set once on the first deposit/withdraw (D/W for short) and every D/W after just adds more amount. This can be exploited by D/W 1 wei and when the vest expires to do the rest.

Example:

1. User1 deposits 1 token

2. His token is locked for 1 week

3. He can now withdraw, but he deposits the rest 99 tokens

4. He has a deposit of 100 tokens and can withdraw any time

Same for when deposits are instant, but you need to vest in order to withdraw

Stopping points:

Every action resets your vest - can we D/W for someone else and reset their vest?

Each D/W is it's own position with it's own vest time and amount - Accounting can get really messy as for each user we need to track multiple positions and their total combined value. Adds a lot of extra logic.

Fix:

Best recommendation is to reset the D/W vest on every new instance and prevent other users from making deposits.

However if you want users to D/W any time without punishing them with the lock, then consider making each D/W into it's own position, and track user total into a mapping. This will add a lot of complexity, but when done right it's the best solution.

5. How dust becomes insolvency

By far the most common of them all. But what is it?

As we already know solidity math is not precise, all divisions round down and if you are rounding down on how much shares to burn then you are essentially "rewarding" the user (even though the amounts are dust).

Simplest example is right here, where the share price changes and we may burn 1 less shares, essentially giving the user 1 more asset.

But how can 1 wei be dangerous? Usually it can't and these issues are Low or Info, however in rare circumstances it can cause insolvency. That's usually when the assets are fixed and accounted separate from vault balances (i.e. a variable instead of usdc.balanceOf(vault)).

Stopping points:

But it also rounds in deposits, so it negates itself! - yeah as if there are gonna be the exact amount of deposits to withdraws. Users can deposit once and withdraw 1000 times.

Fix:

Simplest solution would be to use OZ Math and and simply round in favor of the system.

In favor of the system means that you always give less assets to the user and burn more users shares.

Integrating with Vaults

1. Your withdraw order is killing your yield

Another simple, yet often missed vault bug. When using vaults as yield, or any other group of yield earning entities for that matter it's important on how and when you deposit to each and how and when you withdraw from each, aka your sorting of priority.

Simplest example is when projects have a basic FIFO (first in first out) order, where usually this order is like:

1. Vault1 - 15% APY

2. Vault2 - 10% APY

3. Vault3 - 5% APY

From first impression this looks fine. We deposit and fill up the first vault as it has the highest yield, then the second and the third.

But if you are a smart cookie you will notice that for withdraws it's the same. We always withdraw from the highest APY vault, meaning it's never fully filled. This will in turn decrease yield significantly.

Example:

• All vaults have caps of 100k

• Vault1 and Vault2 has reached it's cap

• Vault3 is filled with 50k

1. We earn 15% * 100k + 10% * 100k + 5% * 50k = 27.5k

2. User withdraws 50k

3. Vault1 totalAssets are decreased to 50k

4. Now we earn 15% * 50k + 10% * 100k + 5% * 50k = 20k

Where as if we have withdrawn from Vault3 we would have made

15% * 100k + 10% * 100k + 5% * 0 = 25k

Fix:

Instead of using FIFO use FILO (first in last out) and sort the array based on the APY we earn in order to optimize for highest yield.

2. convertToAssets + convertToShares == wrecked

Imagine that you would need to figure out how many assets your shares represent. What function would your contracts? Most obviously convertToAssets, the name suggests that it will convert our shares to assets right?

That's the wrong answer.

The problem with it is they don't account for any withdraw fees or swap slippage, meaning that it will return an overinflated amount of assets.

MUST NOT be inclusive of any fees that are charged against assets in the Vault.

Fix:

The correct function to convert shares to assets is previewWithdraw. It will return an exact version of what you would withdraw if you called withdraw, but without accounting any vault or user limits (aka. returns how many assets you have).

Same is true for the reverse functions - convertToShares and previewDeposit.

3. Rewards

It's really common for vaults to not only distribute yield in the form of share price increases, but to also reward some sort of incentive tokens to given strategies. Simplest example and one that we cough recently on an audit is a vault that farms yield on Morpho, but does not handle Morpho rewards.

Are reward tokens even handled?

The most basic mistake — the vault integrates a protocol that emits reward tokens, and simply never claims or distributes them. They accumulate, sit there and get stuck forever.

What tokens, and can they change?

Protocols can add or rotate incentive tokens at any time. Does your vault hardcode them to one token - not good. Would recommend a map for reward tokens.

Who can trigger the claim?

Some protocols let anyone call the claim function, which means reward tokens can be sent directly to your contract address without warning. If your vault isn't built to handle an unexpected token transfer, those rewards are stuck.

4. Caps and static tokens

Another easy to find (if you know it) bug is that some vaults have max caps. Be it for one reason or another they do not let more than X amount of assets be deposited.

Simple, so what's the problem here?

The issue is in the way most developers integrate with such vaults, as they don't know or consider that there is a possibility of the vault filling up and deposits to it to revert.

Sometime it's not checked and deposits are just reverting, even if there is some space still left in the vault.

Example:

1. Index vault deposits to other vaults

2. There is space for 5000 assets to be deposited

3. User calls deposit for 8000 assets, but the TX reverts

4. User leaves

Some developers fix it by implementing maxDeposit Now we make sure to fill the vault up and all assets are utilized!

But is that a fix? Do you see the issue here?

This bug wasn't about deposit reverting when the vault fills up, but for when it doesn't. The issue here is that after the final deposit where the internal vault is filled up we are still allowing more deposits. These extra assets are not gonna be used in a yield generating way, but will take part of that yield. This is best shown with math

1. Index vault1 has 100k assets

2. 50k are deposited to 15% APY vault

3. 50k are deposited to 5% APY vault

4. Users earn 10% APY

vs.

1. Index vault2 has 120k assets

2. 50k are deposited to 15% APY vault

3. 50k are deposited to 5% APY vault

4. 20k are idle as both vaults are filled up

5. Users earn 8.3% APY

Fix:

Fill up all vaults to 100% and then prevent more users from depositing.

Only for builders

Building a vault or anything that deals with shares?

If you have a mainnet launch, upgrade, or token event in the next 60 days and your contracts haven’t been re‑audited, you’re running on luck.

Book a security audit review call with us here:

https://phagesecurity.com/request-audit

or hit me up in my TG at @Pyro3b.

I'm not going to claim this replaces an audit, but every bug here is something we at Phage Security have caught in real engagements, and the patterns were consistent enough that I thought they deserved a write up.

Re-entrancy attacks

In half of the PMs and PM add-ons I've audited there was a re-entrancy bug somewhere. That is pretty common in these products as CTFs are ERC1155 tokens, which have a receive hook when transferred (If you didn't know this it's better to quit, web3 ain't for you D:).

The best way to avoid is to have nonReentrant on every function that sends these tokens to the user.

But what if I have multiple contracts? nonReentrant won't protect me against multi contract re-entracy.

For that my dear friend we need to figure out how to stop re-entrancy without relying on nonReentrant modifiers.

The simplest way to do it is to just transfer the tokens at the end of the whole call. Save them in memory and just transfer them after everything else is done. There won't be a point in re-entering if there is no difference between it and just another call. It's that simple...

YES + NO = 1 USDC

Fundamental in prediction markets. It may seem simple, but it's sometimes not accounted for when you try fancy math with positions, forget that order books have spread or when distributing yield based on YES/NO probabilities and a negative yield surfaces by.

These vulnerabilities are best described with examples, so here we go:

Order books

Order books can be used to match users who sell YES and users who buy YES, directly 1 to 1. But they can also match buys of YES and buys of NO, by collecting the USDC and then splitting it to create YES + NO tokens. Same can be done for selling when one users sells NO is matched with another user selling YES, where both tokens are used to merge into USDC and give it back proportionately to the users based on their order prices.

Fundamental feature of orderbooks are their spread. The current probabilities may be 50% / 50%, but some users will place limit orders at 10%, 20% or 30% as stop losses or entries.

Your engine may not be able to match positions that fill up to exactly 100%. Simple examples are to match 2 orders for YES at 0.6 and NO at 0.45 for a total of 1.05, or we collect YES at 0.55 and NO at 0.40 for a total of 0.95.

So what are you gonna do if positions are matched to above or bellow 100%, who is gonna take the profit and who is gonna eat the loss?

To fix the first you should forbid orders from matching above $1.00 (100%). Because the system cannot deliver on them. If we collect 100 YES for 0.6 and 100 NO at 0.45, and merge them then the total is 100 USDC, but we must deliver 60 to the YES holder and 45 to the NO, which will cause insolvency.

For the second case it comes more to a taste. Either one of both orders are matched at a discount, where they will be different from the actual price. When we collect 100 YES at 0.55, 100 NO at 0.40 and merge them we get 100 USDC, deliver 55 USDC to the YES holder and 40 to the NO, the extra 5 USDC can be fees (really big fees). Or if you want to spare your users the huge fees you can overdeliver on one or both sides (i.e. send the extra 5 USDC to them). Essentially deliver positive slippage as one or both parties are gonna receive more USDC than they placed a sell order for.

Yield

You may be doing fancy math on yield and splitting it based on YES/NO probabilities.

Smart cookie!

However when farming yield there is always a possibility of negative yield. The black swan event where out of nowhere 70% of one of your Vaults TVL is wiped out. They didn't hack you, but you will still take the L and if you haven't planned for it in advance...

Well it's gonna be problem. But how do you handle it?

Well if you farm 100 USDC in yield you can split it 80/20 (or whatever the probabilities are at the time) and deliver 80 USDC to YES holders and 20 to NO.

However if you lose 100 USDC burning 80 YES and 20 NO won't result in the 100 USDC being accounted for. Matter in fact you made it worse. You've essentially accounted only for 20 USDC as the 20 NO + 20 YES = 20 USDC and burned extra 60 YES for nothing.

You must reduce both YES and NO by 100, i.e. not to split the loss, but to account it at 100% for both YES and NO.

Fees

When charging fees how exactly would you "charge" them. If a user deposits 1000 YES tokens you can only take a fee on YES, so you take it and keep it, but the market resolves in NO. What now? The user was charged a fee, his assets decreased, but you didn't take a profit too, since all of the YES resulted in being 0$.

Your fees become a bet, and that is no fun. Not only that but your revenue comes at the resolution date of the bet, not whenever users interact with your product. You are building a project that should produce somewhat consistent revenue, not one that bets with the users.

To avoid this you can merge YES+NO in order to have pure USDC.

But merging from time to time will result in the same betting as the market may resolve before you merge. The best solution is right after taking the fee for the system to keep track of it's YES/NO tokens and to try to merge them instantly. This way you will always keep X amount of either YES or NO, but will minimize "betting" and maximize guarantied profit.

Early resolution for borrowing

Using your position as collateral and borrowing against it may seem fine at a first glance. It's collateral that sits and does nothing, why not utilize it?

However if you dig deeper you will see that prediction have extreme volatility. Volatility doesn't go well with borrowing and lending, that is if you don't wanna get liquidated all the time.

You see some predictions may have an end date in 1 year making them somewhat stable, however they can:

• prematurely end (due to an early resolution)

• get canceled

• flip overnight

• get manipulated

Example:

1. 100k YES on if BTC will hit 100k by the end of 2026 - 60% valuation = 60k coll

2. Loan for 30k, overcollateralization ratio of 200% - pretty solid for normal markets

3. Black swan event occurs and drops BTC price by 10% in a day, market looks bad

4. Suddenly YES is valued at 25%

5. Loan is for 30k, but your coll is worth 25k

You will get liquidated at a win, but the lenders will take that loss.

The oracle problem

First thing that comes to mind when you think about borrowing or lending is leverage oracles, yes oracles...

The main problem is that there are no oracles for PM positions. Yes there are deciding oracles like UMA, but no oracles from where you can get the YES/NO price.

This will prevent you from building a reliable product that is dependent on the price of a position.

What if you make your own oracle?

Great question! But oracles are not just prices on chain, they have many hidden components, like:

• Few sources to avoid manipulation

• Deep asset liquidity (again to avoid manipulation)

• Instant prices (who cares what the YES price was 1h ago?)

  
  

Locked out

Another issue, not a security one, but user facing is how quick a user can remove and sell their position. If they are farming yield, but decide that YES no longer works for them and want to sell how much would they have to wait to get their tokens?

Some vaults tend to have withdraw periods or lock ups. Which is fine if the user want to hold their token till resolution, but for users that wanna sell when the price increases (or drops too much) that waiting is essentially forcing them to keep their bet when they don't believe in it.

Having such mechanisms will drastically lower their participation in your product.

Only for builders

Building a prediction market or anything that uses it's tokens?

I’m offering a limited number of free 3 day security reviews specifically for PM products.

DM me on X about this offer to grab a slot before going mainnet.

The protocol TVL has dropped by 40% in two blocks. You are getting constant pings in your Discord and Telegram community chat, asking you what happened?

You check Etherscan. You check it again. The "To" address is a contract you don't recognize. The "From" address is your main liquidity pool.

The marketing intern just drafted a tweet that says, "We are aware of an issue, funds are safe." They have no idea if funds are safe. You have no idea if funds are safe.

This is the moment. The "Oh sh*t" moment.

Most teams freeze. They stare at the screen, not knowing what the immediate step should be.

This document is for that moment. It is not a theoretical framework for "security resilience." We have seen the best teams crumble and the worst situations salvaged. This is how you survive.

This Is Not Bug Fixing

The most common mistake in the first hour is teams going into debug mode. That’s the wrong first instinct.

If an exploit is continually causing harm to your system in real time, your priorities should change. Your first job is not to figure it out. It’s to be safe.

Containment. Assessment. Mitigation. Remediation. In that order.

First 15-30 Minutes (Containment)

Your only objective right now is containment. You do not need to understand how it happened yet. You just need to stop it from happening further.

1. Incident Mode

Once you are in Incident Mode, normal rules don't apply anymore. You don't ask for permission to pause contracts. You don't wait for a code review to revoke a compromised key. You act to save the protocol.

Do not tweet or post anything detailed on Discord just yet.

2. Kill Switch

If you have pausable contracts, pause them. Now. It is easier to explain downtime to users than to explain why their funds are gone.

It is very common for attacks to originate from a team member who got compromised. Assume the worst and revoke key permissions as well.

Now, you can tweet. Along the lines of “We are aware of the issue. We are investigating” should be just fine for now, as you are not aware of the scale of it, just yet.

3. Verify Reality 

Now that you have shut down everything you could, it’s time to check whether it’s actually an attacker or a bug causing this. Check the transactions, check the logs, verify the exploit, and try to understand the scale of it.

First Few Hours (Assessment)

The initial panic is over. The protocol is either paused, or the attacker has finished. Now you need to figure out the blast radius and prevent secondary damage.

1. Extra Checks

Check your website. Is the attacker serving a malicious UI? (See the Ledger Connect Kit or BadgerDAO incidents). Check your DNS records and recent deployments.

Rotate your AWS/GCP API keys and database credentials. If the attacker got in via a compromised developer laptop, they might have access to your backend infrastructure, not just the smart contracts.

2. The Forensic Ledger 

Start a "Loss Accounting" spreadsheet. You need to categorize assets into three buckets:

• Confirmed Lost: Assets already moved to the attacker’s wallet.

• At Risk: Assets in contracts and vaults that you are not sure if it’s compromised.

• Secure: Assets in cold storage or successfully paused contracts.

Why this matters: You need to know if you are solvent before you write the breakdown tweet.

3. Incident Timeline 

Assign your best engineer (or external security partner) to trace the attack.

• T-Minus: When was the contract deployed? When was the last upgrade?

• T-Zero: The first malicious transaction.

• Pattern: Is it a single atomic TX (Flash Loan) or a drip-feed drain over multiple TXs?

4. External Coordination

• Security Partners: Contact your auditors and security firms. They can further help confirm the vector. Escalate to SEAL 911 from Security Alliance. It is basically an emergency hotline run by security researchers (often reached via their official Telegram bot). They can help coordinate triage, support fund tracing and recovery flows, and advise on how to engage exchanges and law enforcement.

• Exchanges & Stablecoins: If the attacker stole stablecoins or assets, try contacting the issuers to see if they can help freeze the assets. This rarely works in time, but it is a required step for liability. Contact major exchanges with the attacker's address to flag deposits.

• Update: Provide a further update to the community and on X with your findings. The goal is to share the factual details you know so far, so independent investigators like ZachXBT can also take a look and potentially help.

  
  

First 24 Hours (Remediation Strategy)

The world knows you are hacked. Your goal is to control the narrative and plan the recovery.

1. The Situation Report (SitRep)

Communication is a minefield.

The Don’t: Don’t jump into saying “all funds are safe” unless they’re 100% safe or already recovered. I remember the Celsius team saying “all funds are safe and we have robust risk management,” only to file for bankruptcy later.

The Do’s: “We are aware of an exploit. The protocol is paused. We are investigating the scope. Please do not interact with anything on our site or the smart contracts until the next update.” If you have a general idea of what happened, write a blog or article summarizing the incident, the impact, the suspected cause, the actions taken, and the next steps. If done right, you’ll earn trust from the community instead of being questioned and mocked.

2. Remediation Decision: Patch vs. Migrate

• Patch: Can you upgrade the implementation contract to fix the logic?

• Migrate: Do you need to deploy V2 and move all liquidity?

• Redeploy: In cases of severe key compromise where you cannot trust any previous state, a full redeploy of the architecture might be necessary.
  

3. Preservation of Evidence

This is critical for any future law enforcement action or further investigation.

• Save Logs: Snapshot your CloudTrail logs, RPC logs, Transactions logs, Discord audit logs, Twitter logs, etc. depending on the type of attack.

• Download Git History: Ensure no one force-pushes changes to the repo to hide a "bad commit."

• Document Decisions: Keep a log of who decided to pause, who decided to tweet, and exactly when.

4. The "Whitehat" Negotiation

You might receive a message on-chain (Input Data Message) or seeing movement to Tornado Cash.

• The Bounty Offer: It is standard industry practice to offer a 10-20% bounty for the return of funds, treating the incident as a "whitehat rescue."

• The Channel: Open a communication channel (email or on-chain messaging). Do not negotiate on public Twitter.

First Few Days (The Fix)

The adrenaline has now faded. Now you have to do the hard work of rebuilding.

1. Root Cause Analysis (RCA)

You must produce a technical RCA that is verifiable.

The Invariant: What was the root cause, and exactly what, logically or technically, caused things to break. Some edge cases may not have been handled properly. This will likely become more common with AI-written code.

The Miss: Why wasn’t this caught in internal testing? Did you do a proper audit before deploying the contract? Or maybe the audit was done on the original contract, and the team didn’t run a full audit when deploying v2.

The Proof: Provide PoC (Proof of Concept) steps that reproduce the hack on a fork.

2. Patch and Verify

• Private Audit: Do not deploy the fix immediately. Your "fixed" code often introduces new bugs because it was written in a panic. Send the patch to a trusted security partner for a review.

• Adversarial Testing: Try to hack your own patch. Use the tools and methodologies the attacker used and learn from all the previous hacks on different protocols.

3. The Restitution Plan

Users want to know if they are getting their money back.

1. Treasury Assessment: Can the Company cover the loss?

2. Collateral: Will users have to take a % loss?

Advice: Be honest. If you cannot pay them back immediately, say so. "We are exploring options" is better than a lie. You should be openly communicating to big institutional partners asking for help, as they are more open to help as to not give crypto the bad rep of always being hacked.

4. Phased Rollout

Do not flip the switch back to "ON" for everyone.

• Phase 1: Withdrawals Only. Let people leave. (Most won't, if you communicate well).

• Phase 2: Capped Deposits. Limit exposure.

• Phase 3: Full Operations.

  
  

First Few Weeks (Narrative Shift)

If you survive the first week, you have a chance to become resilient. Many of the strongest protocols today (MakerDAO, AAVE, Euler Finance, etc.) have survived major incidents.

1. Operational Hardening

The hack was likely operational, not just code.

• Multisig Hygiene: Implement multisig, if you haven’t yet and expand the signer set if you already have it. Require hardware wallets for all signers. Implement geographic distribution of signers.

• Timelocks: Add timelock to all governance actions. This gives the community time to react to a malicious proposal or compromised admin key.

2. Monitoring and Response

• Real-time Alerts: Implement monitoring that alerts you to "invariant violations" (e.g., solvency check fails) rather than just "large transactions."

• Automated Pause: Consider building a bot that can automatically pause the contract if it detects a critical invariant failure.

3. The Audit Cycle

• Retainer: Move from "one-off audits" to a continuous retainer with a security firm.

• Bounty Program: Launch a high-value bug bounty. A $50k bounty is cheaper than a $10M hack.

4. Rebuilding Trust

Trust isn’t rebuilt by marketing alone. It’s rebuilt by shipping secure code, communicating clearly, and surviving the next few weeks without surprises.

• Publish the Post-Mortem: A clear admission like “we overlooked this specific logical bug” earns more trust than vague deflection like “it was a sophisticated hack none of us expected” when it wasn’t. What matters is clarity on what happened, what broke, what you did, and what changes going forward.

• Consistent Updates: Share specific, technical updates on what you’ve changed to prevent recurrence, along with timelines and what users should do (or avoid doing) in the meantime.

  
  

How to Handle CT

Crypto Twitter is a coliseum. If you show weakness, they eat you. If you lie, they destroy you.

The 3 Posts Teams Regret

1. "Funds are safe." (When they aren't).

• Why: You look incompetent or malicious. (See Celsius, 2022).

2. "We were hacked by a sophisticated state actor." (When it was something completely different).

• Why: Independent security researchers will find the truth ultimately. You will be mocked and not be trusted.

3. "We take security seriously."

• Why: It's a cliché. Obviously you didn't, or you wouldn't be here. Show, don't tell.

Safer Alternatives (Templates)

• The Initial Ack: "Eg: We are investigating an irregularity in the Vault contract. Operations are paused. 🧵"

• The Hard Truth: "Eg: We have confirmed an exploit. ~400 ETH has been drained. The vector was a logic error in the claimRewards() function. Remaining funds (~2k ETH) are secured."

• The Path: "Eg: A fix is in development. It is being reviewed by our security audit partners. We will pause the operations until it is deemed safe."

Handling Rumors

• Quote-Tweet Hysteria: Ignore the ragebaiters. Do not reply to "Rug?" tweets. You shouldn’t take them seriously. 

• Fake “Official” Links: Scammers will post lookalike claim sites, Google forms, and “recovery” wallets in replies. Warn users clearly: “We will never DM first, and we will never ask you to send funds.” Pin that message and repeat it in every update.

• “Funds Are Safe” Pressure: People will demand reassurance. Don’t overpromise. Say what you can verify: paused status, known impact, what’s being done, and when the next update drops.

Closing Thoughts

Getting hacked is not a filter for competence, it is a filter for resilience. The market doesn’t only judge what went wrong, it judges how you respond when everything is burning down.

A protocol dies when the team panics, goes quiet, overpromises, or ships “fixes” without a second thought. A protocol survives when the team contains fast, communicates facts, and rebuilds with discipline.

Vibe coding is fine for prototypes. Vibe incident response is how you lose real money, real users, and the narrative.

Have a plan before you need one. Because when the exploit hits, you don’t rise to your intentions. You fall to your preparation.

Don’t Wait For Your “Oh Sh*t” Moment

If this felt uncomfortably real, that’s your warning shot.

We at Phage Security perform smart contract audits for Web3 protocols so this story stays an article, not your post‑mortem.

If you have a mainnet launch, upgrade, or token event in the next 60 days and your contracts haven’t been re‑audited, you’re running on luck.

→ Book a security audit review call with us here:

https://phagesecurity.com/request-audit

or hit me up in my TG at @Pyro3b.

In this article I’ll show you the exact 6 step checklist I use to help teams go from “we think we’re ready” to actually audit ready for an audit.

Summary

1. Have complete code (skip if you are interested only in the security part)

• No placeholder functions or TODOs

• All integrations implemented

2. Writing tests

• How much coverage is enough?

• Should we mock or simulate real conditions?

• Unit tests vs integration tests

3. Internal reviews

• Code reviews before audit

• How and what to do

4. Clear documentation

• What should/shouldn't it have?

• Architecture diagrams

• Comments

5. Scope definition

• Be specific about what needs auditing

• Exclude out-of-scope contracts/functions/interfaces

6. Choose the right audit firm

• Get multiple quotes

• Research the auditors

--------

1. Have complete code

Before you consider any sort of security, you must first have a MVP/POC. That means an actual piece of code that should be working on its own. All user paths from first interaction (deposit, stake, lock, etc.) to last (withdraw, redeem...) should be working with the intended variable inputs without reverting or leading to any errors.

If you have any integrations, make sure you followed their best practices (thoroughly read their docs, or at least make Claude read them and correct any code that goes against them). If you are unsure about some functions, most (if not all) projects have supportive developers that you can reach out to and who would be happy to look at your code and help with anything you are missing.

If you are doing heavy integrations, I would even suggest reaching out to them, as they know their code best, have seen many projects integrate beforehand and know what works and what doesn't.

2. Writing tests

The most dreaded part.

Most people would look at what coverage you have to determine your test suite. However, coverage is an inaccurate stat. It simply determines if your tests go through a given path, skipping the fact that you might have tested it wrongly, or with the best possible conditions.

The amount of tests you want to write depends on how fast you want to launch (you can write tests during an audit, although I suggest to have everything beforehand).

If you are in a rush, you would need the most basic tests:

• Simple function tests without malicious intent (i.e., just regular user interactions) -> deposit, claim, withdraw

• Simple user paths without malicious intent -> deposit -> withdraw and stake -> claim -> withdraw

• Access control -> if users can call onlyOwner functions or if users can withdraw from other user accounts

• Simple protocol integrations -> mock calls for the protocol you are integrating, distribute yield and then try claiming it

However, if you have a spare day or two, you should consider testing more thoroughly (all of the above and):

• Users with malicious intent calling functions/flows -> try simulating first depositor bug if you are using 4626 or deposit/withdraw 1 wei

• Advanced function flows -> user1 deposit -> user2 withdraw -> user1 claim

• Reverse scenarios -> black swan events, negative yield, bad debt liquidations

• Integration tests to see if your integrations actually work

Honestly, these tests shouldn't take that much time. You should be spending 80%-90% of your effort on the actual project.

Notice that I said "making" as for tests you don't need to write them on your own. You can (and I suggest you) use AI. I prefer Cursor with Clude, but Claude code works too (if not better). The way to make it write the correct tests, the right way is simple:

1. Make it create a testing diagram for every function and user flow (make sure it's correct)

2. Prompt it to make a complete setup (initialize and configure every contract) with a few user accounts

3. Start writing tests one by one

4. Correct it where necessary

You won't write them yourself, but you'll be supervising their creation. This would speed it up by a lot.

3. Internal reviews

You've written a lot of tests, but often they miss unique paths and "strange" conditions. This is why you should audit your own contracts. Paying your developers (or doing it yourself) would cost you 2-3 days of "no progress" on your code/app. However, that can save you an extra audit. What would you rather do - pay your devs to work a few more days (300$ - 500$) or get an extra audit (10k - 20k+)?

This often will make the difference between needing 1 or 2 audits

Now, before you start, I would recommend setting a time window that would force you to do about 300-400 nSLOC per day (i.e., 1000 nSLOC -> 2-3 days). Since this is your own code and you know it well, you won't need extra time to understand it.

During that time, your only goal is to break everything you can. Don't write new code, don't re-edit old code (note it somewhere for later), but just go around and try to exploit your own project.

Don't start fixing bugs the moment you find them! Make GitHub issues with the vulnerabilities (or note them somewhere) and continue breaking your code. After the time is up, start fixing them as best as you can.

After you are done with the fixes, make sure all of the tests run and new ones if you introduced new logic.

4. Clear documentation

This should not be complex. Don't overengineer it. No one needs GitBooks for every smart contract with every function and every variable and what they do. If they want that, they can open your GitHub and read the contracts (or interfaces) and get the info they need.

Your docs should be simple to understand, concise, and to the point. Again, use Claude to write them. It takes only a few minutes (with a good prompt), maybe 30min of you want them polished. Also, if you happen to have diagrams and schemes, feel free to show them in the docs. They provide a good visual reference.

Make sure you have some minimal nat-spec. You don't need to explain every single line, but have 1 or 2 sentences above function or complex logic that gives a brief explanation what it does and why. Again Cursor can do that for you.

5. Scope definition

The simplest part. Get only logic contracts in scope. That means any contracts that are interfaces can be removed from the scope to reduce the nSLOC (and possibly the price). Finding bugs in interfaces is rare, and most are due to wrong interface implementation, which is implemented in the logic (i.e., already covered by the scope).

If that's your 2nd or 3rd audit, you can exclude simple helper functions (or implement OZ/Solady ones) from the scope. Auditors will still look at out-of-scope contracts that integrate with in-scope ones and try to find bugs there. However, note that if the helper functions are too complex, they may also need to be included in scope, just in case.

6. Choose the right audit firm

Choosing the right firm is not easy. You must consider:

• What your users think (most don't know which ones are good)

• What your VCs think or push you to choose (they still don't know which ones are good, but rely on their brand, which is very dangerous)

• What you and your developers think (these guys you can trust the most).

My first suggestion would be to not let yourself be pushed around by VCs telling you which firm you should pick. Resist them as much as you can and provide logical feedback on which ones you think are better and why. But how do you know which ones are better and why?

To know that you must first find a number of auditing firms and research them. Here is what you should be looking for:

• The firm doesn't do the audit, the auditors do

Brands are a big thing. But in cybersecurity, the brand is 80% client communication and the other 20% is delivering on results.

On top of that, most firms work with contractors, some have employees, but I've seen employees of big firms take things "on the side". So consider that most firms have access to the same pool of auditors, where the same team of 3 can be one price at firm X and 2x more expensive at firm Y, FOR THE EXACT SAME GUYS.

• Some auditors are better than others, and some are specialized

Most (if not all) auditors have a GitHub portfolio/CV with their past experience. You will need it to determine how good they are. Look for contest wins, which firms they have worked with or overall quantity of audits.

Some auditors are mediocre in general but are highly specialized in X niche (lending, bridges, prediction markets, or any interesting topic). It's generally good to have one of these as they would most certainly catch the rare bugs (missed by most).

• Some auditors are booked on 2 projects at the same time, reducing their quality of work

When making deals, make sure to ask if all of the guys would be doing only this audit during the whole time frame. Again, most big firms usually send a team of 2 juniors or intermediates for the whole audit and 1 lead auditor just to check at the end if they have missed anything.

Steps to take before you choose an auditing firm:

• Get a quote from a few firms

• Ask each about the team they plan on putting and their CVs

• Ask for people familiar with the project type you are building

• Look at each team and consider the price

Short summary of next steps

1. Make sure your code is finished

2. Spend a few days with Claude writing tests

3. Do an internal review on your contracts and fix/improve anything you've noted

4. Write short and clear docs

5. Scope your project

6. Research a few auditing firms --- Want help doing all of this before you pay for an audit?

---

If you’ve got your MVP live on testnet and you’re aiming to launch in the next 4–8 weeks, we offer a free 3‑day security overhaul for a small number of teams each month.

Over 3 days, we will:

• Try to break your core flows like an attacker

• Flag Critical / High / Medium issues with clear fixes

• Tell you if you’re actually audit‑ready and what your scope should be

If you want me to do this on your contracts, apply here:

https://phagesecurity.com/request-audit

or hit me up in my TG at @Pyro3b.

You are not alone, my friend. I sometimes feel this too. The sad truth is that not everyone is meant to make it, there is not enough room for everyone to be successful.

"All those who work hard don't succeed, but all those who have succeeded have worked hard." - Kamogawa Genji, Hajime no Ippo

I consider the above just an excuse not to give your best, to not make the greatest sacrifice. These beliefs are like ghosts, the more you believe in them, the more real they will seem. They are excuses to quit early, but remember, every failure bring you closer to the win. You have no choice but to do your best, failing time, after time, after time, without seeing an end.

Everyone falls the first time they try to walk…

The above was the first thing you needed to learn, and below is the rest, enjoy.

Progress is exponential

Progress, whether in sports or a career, is never a straight line. It's exponential. The more you practice, the better and faster your improvements will be.

Indeed, this scientific graph (which I definitely didn't draw myself) shows a good representation of how progress is measured.

It's the same with success, money and even women (or so I've heard D: ). The more you achieve (have), the faster you can acquire more. This is why they say:

When it rains it pours

This is great and all, however it's upside is also it's a downside. You see, this doesn't apply only to you, it applies to everyone. Everyone is on this curve and if someone is ahead a month or two he can be much better and much more successful than you. Even worse, the more in front they are the faster they will expand the gap between you and them.

But worry not kind reader, there are things you can do (or not do) that will help you scale better in any aspect you want. If you've read my previous article (selfish promotion )

https://mirror.xyz/0x3b338e782859aE11c0B15694bc482a9aFa4A5809/-NXPrhqz8kzbDEZzEbIq5B-EExV2l7tTvTzidOWoc5k

you will know that in order to master a certain skill you will need to practice this specific skill and not skills that mimic it. If you are confused, here is an example from the above article:

Driving your car every day to work won't make you a F1 racer.

For you to master something as fast as possible, you will need to cut off all distractions

And the most dangerous of all distractions are the ones that make you thing you are going the right way, that you are working and grinding, task that take your energy, time and attention, but yield no return.

These my fellow reader, are the ones that you pay the highest price (time, energy and suffering) and get the lowest returns - nothing…

Do you remember it?

While we are on the topic of acquiring as much knowledge as possible, I need to ask you

Do you remember it all?

You may remember the stuff you've read for a few days, even a a week or two, however if this knowledge is not used it's ultimately forgotten.

Does that mean you should stop listening to advice or new ways of thinking? No it's just the opposite. You should aspire to find the best way to be proficient at what you do, and that is by learning and implementing new methods and mindsets.

So what should you remove?

Well, why are you reading an article about how Compound works, when you don't plan to audit Compound based projects? Why are you reading the famous 1 DAI article when 50% of the stuff in it you already know and the other 50% you won't need? I've personally read it and if you ask me I've forgotten everything in there, as I didn't really need it.

Note: No hate, it's a really good article for general knowledge, however I don't recommend wasting 1 hour of your life if you have basic knowledge of EVM.

Have you read Mastering Ethereum ? Why ? It’s extremely dense nature makes it packed with info that you won’t remember, or won’t need. That book i as old as time (probably dinosaurs wrote it), most of the stuff inside is outdated. It’s a giant waste of time.

Note: Again, nothing personal, this book might have been a great read a couple of years ago. However if you want to be a developer/auditor this book is too outdated.

I am telling you this from experience, when I started I spend 1-2 hours a day reading random articles on different DEFI projects. How Compound works, deep dive into OpenSea, Curve, Maker, Lido... Yet, this information is now completely forgotten.

Reading things like this might seem productive, and it's better than playing video games, however at the end you only end up with the feeling of productiveness. Better spend the Saturday night with family or friends, or writing articles if you are like me (empty inside :D).

Do you need it?

As per Bytes (a random guy I saw on twitter :D ) one of the biggest mistakes new auditors make is:

Studying stuff that you don't need right now

This leads me to the most important question that you must ask yourself before starting any new endeavor:

Do I really need it?

Does It Make The Boat Go Faster? is a quote from a world class rower. There are so many exercises that you can train to improve team coordination rowing technique and a thousand other little things. But does it make the boat faster? The fastest boat wins the race, not the one that trains the little things.

So I am asking you, are you training to make the boat faster or are you training the small little things? Some thing might feel like work and look like work, however they are the furthest things away from work. They are not making you progress faster, they are just occupying your mind, making you think you are productive, while letting your competition surpass you.

Very few of the articles I’ve read were useful. Again that doesn’t mean to skip everything, but it means that some articles, some videos, even some tweets are useless.

You see, everything you need is already on the internet, you don't need to remember all of the stuff as long as you know it exist and how to find it. Simply if you are working on a project that integrates with Lido, go and look up how lido works. This way your learning will help you build better code and the information that you are gonna acquire is gonna be remembered for longer as you will use it in your code.

Trust your gut (or boredom)

Most people will tell you that you need to rely and discipline and do the tasks even if you don’t want to do them. I have nothing against it, however in most cases your gut instinct tells you pretty well if you actually need to know something or you are just procrastinating, and if the latter it would make you not want to learn it. Here discipline will actually be bad for you, as you would force yourself to learn something you don’t need or want.

Perfect example is reading the docs while on an audit. Everyone has had that experience needing to understand the code better and heading to the docs, in order to spend the next 1 or 2 hours mindlessly reading stuff. If you actually gain insight, then that’s amazing! However I can tell from experience that most of the time you would read it with the hope of getting more context, but end up in the same place 2 hours later, with 2 hours less and a ton on energy wasted on useless tasks.

Same can be said for tutorial hell. Most people after watching enough videos and reading enough boring articles will start to notice that every new piece of content is 95% already known and 5% new stuff. These 5% of “new stuff“ might be useful, but most likely not.

When you reach that point you would need to shift your priorities. There is nothing bad in learning more, or reinforcing what you already know, however do that in your spare time, don’t count it as “work done” because it’s not. It’s entertainment, especially if it doesn’t change your behavior.

With time and experience you will get a feeling of what is actually useful and what isn’t.

If you do it, do it good

Finally you’ve got my point (if not, hit me up on twitter, I would appreciate some feedback) and you have eliminated all of the crap and started reviewing the real stuff. Now it comes the time to ask you how well you are doing it ?

Generally I would suggest when you read an article or watch a video to do only that. Don’t check your phone, or send a few messages on telegram, or read all new emails. Just watch the video and fully concentrate on it. When you finish, do a short 30 second summary in your head.

If you have chosen to watch it, it means it’s important (even if at the end it proves not to be). Most interviews or podcasts have a tone of hidden implies that are only a sentence or two long and may sound like small talk, but in fact they actually give extreme detail on the methods or way that this guy operates. Multitasking in these cases would mean that you have wasted 1 or 2 hours watching the podcast, but have gotten 20% of it’s insights and thus made near 0 improvements.

With that I would put an end to my rant. I hope you’ve got the point I was trying to make. If while reading it, or just in general you have some ideas or topics that I have missed, hit me up on twitter and I would add them here.

And of course if you really liked it, want to share the knowledge or just want to get more followers on X, then feel free to tweet about it!

Everything in life is a skill, yes…, even breathing, eating, making your parents think you are a disappointment, and learning.

However learning is not just a skill, it's a meta-skill. Now, you might be wondering, what on earth is a meta-skill? Well, it's a skill that helps you acquire more skills faster. Learning how to learn is the ultimate meta-skill, allowing you to grasp anything faster and better. That sounds good, doesn't it?

Today I am gonna teach you 1 concept (useful stuff) and 3 tips (gibberish), enjoy :)

Deliberate practice

Deliberate practice can significantly enhance the performance of a specific skill. It's important to emphasize that deliberate practice is the key, and it exclusively contributes to the improvement of the targeted skill. Now, I'll provide you with 2 examples:

1. Driving your car every day to work won't make you a F1 racist (I mean racer).

2. There are people who train in the gym for 10+ years, but they still lift the weights wrong.

The first example illustrates that even though you are engaging in the "same" skill (driving), it won't make you that much better in it. This is because they are not the same skills, it's a different level of driving. You driving to work at a normal speed, won't improve your ability to take 90-degree corners at maxed-out 2nd gear. It will only make you better at the normal circumstances. You become a better normal driver (and that's not always the case).

Now, I'm not suggesting you should speed, but… we all have that one friend who drives like an F1 racer. In most cases, they excel at taking corners, speeding, and avoiding obstacles (hopefully). They engage in learning the skill of racing by driving at high speeds, while you focus on driving normally. These are two different skills, even if they appear similar.

The same principle applies to coding, auditing, business, or any other field, different levels of a particular skill must be treated as different skills.

The second example suggests that there is a difference between practice and deliberate practice. Even though there are individuals who train for years, it doesn't necessarily mean they are training correctly.

If you are into the gym, you will probably know the basics (hopefully) and notice that some people, despite being jacked, still make fundamental mistakes, especially in compound movements.

These individuals are merely practicing, they don't know how to lift, so they lift the weight and hope for gains. This is not the recommended approach in any pursuit. You may achieve some results, however there are better ways.

First, understand your goal and how to achieve it (check this article if you are curious).

https://mirror.xyz/0x3b338e782859aE11c0B15694bc482a9aFa4A5809/4mvQk7T7KQA-pE1YY3_OEpbdFAYOxbKLmIYFYXCJ_P8

Only then should you strive to achieve it, and that is through deliberate practice - with the intent of improvement and conscientiousness in the task.

Drill everything

Now that we've covered how to practice, we will also need to cover the fact that you need to practice. Regardless of how well you perform your job or how deliberately you practice, if it's done only once a month you will see zero progress.

The most effective way to acquire a new skill is to turn it into a habit. Habits are made by consistently performing the task as frequently as possible, ideally on a daily basis. A downside is that you'll only realize a habit has formed once it's firmly in place. Pinpointing the exact time it takes varies, it could be as short as a few weeks or as long as a few months, depending on the complexity of the habit.

"But what if the skill I need to acquire is suuuuuuuuper boring?"

Well, to that, I would say that with time, it'll become more interesting and easy. Surprisingly, the more you do a specific task, the more enjoyable it becomes. If you're someone who hits the gym regularly, you get what I mean. Initially, you might not always feel like going, but after some time (a few months or a year), it starts becoming the best part of your day.

To summarize it, when aiming to pick up a new skill, choose a consistent time each day when you're typically free, be it morning before work, or late evening after the kids are asleep. Eliminate all distractions during this time and focus on what you need to do.

Retrieval

Knowing how memory retrieval works is absolutely essential for learning faster. Retrieval, for those unfamiliar with the term, is a method used to improve storing a given memory into your long-term memory. It increases the chance that your brain will actually remember what you are learning.

Certainly, the best way to remember what you are learning is for the subject to be interesting to you. However, in life, the things you must learn are often boring. Even with a few techniques, we can make your brain remember even the most boring subjects.

Retrieval or recall is simply done by closing the source of information and trying to explain what you just read. It's that simple. However, you will notice that you can't retrieve everything. Don't worry, open the source again and read what you missed. If you want to recall again, you can, and it will increase the benefits even more, but generally, once or twice is enough to remember most of the stuff.

Now, I know that after reading this article, your behavior when learning won't change, so I challenge you to try it now. Minimize the tab, close your eyes, and take 1-2 minutes to summarize the parts that you've read. Use your own words. Even if you can't summarize everything, continue thinking, and the explanations will pop into your mind. Trust me.

Did you do it? If not, here is a second chance...

As you can see this will increase your time spent when learning. However, it will also increase the number of things you learn, help you connect the dots between different parts, and store this memory for longer. If that's not a good deal, I don't know what is!

Like every other tip on the list, the more you do it, the better it becomes. If you do it with everything important that you must know, over time you will get really proficient at it. It will also force your brain to remember the stuff when reading them, in order to retrieve them later.

Don't take notes on the same day

This might sound strange, but hear me out. Your brain is like a computer (very powerful, yet stupid) and like a computer, it has RAM and storage memory. When you read stuff, your RAM fills up, and when you sleep, your brain processes this RAM and decides what is "important" (memes, cat videos, embarrassing moments) and stores it. During this time, your brain also "deletes" what it deems "unimportant" (i.e., what you studied today). Learn more here.

Writing is a form of relief. It's a great way to express what's on your mind, break it down, and judge it from a logical standpoint.

It gets stuff off your mind.

Now your two brain cells are making the connection. When you write, you "offload" your RAM onto a piece of paper. It's no longer in your head, and thus your brain doesn't need to process it.

All of this processing happens during the fancy sleep you have all heard about - REM sleep. That is why if your girlfriend breaks up with you and you go to bed instead of crying, it's going to be more beneficial. You will still be single and stressed, but a tiny bit less stressed than the night before.

Your brain determines which things are important, and it typically does so in the following order (just remember, this field is complex and I am here teaching BRO science, so take it with a grain of salt ):

1. Fix emotions. If you are learning something and your girlfriend breaks up with you, the next day you will remember almost nothing, as your brain is prioritizing fixing your well-being first. Because if you hug a tree at 160km/h it won't matter that you scored a C on the final exam.

2. Remember important (aka repeated) stuff. You hopefully know how to learn correctly by now wink.

3. Remember emotions and motor skills. I don't know which of these is first, so I put them together ( ¯\(ツ)/¯ ).

"So, what should I do, never write notes?"

No kind reader... , I would suggest writing them in the morning. This way, you have remembered most of the things, you will have your note, and you have done a retrieval on the information. Everything in one!

This "exercise" is great and all, however, it may not work for everyone or with every subject. I have noticed that for me, math doesn't work this way. I need to write the formulas, break them down, and understand them in order to remember anything.

This should be all for today. If you have enjoyed reading this article, you will probably enjoy reading the rest.

Algorithms

Finding the most efficient method can be a challenge, it may even require restructuring some functions or even some contracts. But fear not...

“Everything that can be invented has been invented.” - Charles H. Du

Not vary accurate, but great rule of thumb. Most functions that you are going to use have already been optimized for minimal computational requirements. You just need to find the answers (or the solutions *wink*).

The function below is used in a DAO-type system to return the vote count of a user at a given time. By understanding the context of other write functions and how block.timestamp works, we can deduce that the Checkpoint array is sorted. This is based on the fact that block.timestamp only moves in one direction (towards the inevitable end of time).

With this knowledge, we can implement a binary search algorithm to find our checkpoint more efficiently. You can copy the code from someone else (like I did), or microdose some "substances" and write it yourself.

When we compare those two functions, we can find that the gas cost for the normal search is linear (more checkpoints -> more gas), whereas the binary search has an exponential decrease in gas cost (more checkpoints -> a bigger percentage of gas saved).

Transfers

Transfers and how the system implements them can lead to excessive gas costs. This happens when you perform too many or unnecessary transfers.

Unnecessary transfers include internal system-to-system transfers, where you move tokens from the user to the periphery contract and then transfer them again to the main vault.

Implementing such mechanics isn't necessarily incorrect, but it's not optimal from an economic perspective.

With the above function we can save ourselves some gas if we simply sent the funds to the vault, instead of doing 2 transfers. Same can be said if the vault mints any tokens to the periphery contract and then the periphery distributes them.

Math

When it comes to math in older Solidity versions, we were accustomed to seeing only OZ math being used. However, with the newer versions, we started implementing simple math operations (a * b / c) and creating our own functions.

This is beneficial, as it gives us the ability to perform simple subtraction without the fear of underflow. However, it has led developers to completely abandon the safe and economical math functions and dive straight into simple math.

While on this topic, I must mention that doing complex math using basic methods like direct multiplication and division can be dangerous, as it's error-prone.

Apart from the potential bugs that may arise, we are also wasting gas on calculations that could benefit from optimization or, even better, refactoring.

For example, consider these two functions, they achieve the same result, but the second one is approximately 18% cheaper than the first.

Off-chain

This topic might be somewhat controversial, but I believe that anything not essential in Solidity should be handled by some back-end process. While some protocols can shift a considerable amount of functionality to a back-end or integrate it within the UI, others might require everything to be on-chain.

Generally speaking, the more complex your protocol is, the more components can be moved off-chain. This approach is beneficial, as it saves the gas required to deploy and operate substantial portions of code.

Examples of functionalities that can be efficiently removed include complex find algorithms, array sorters, user imputed data (you will see what I mean in Storage hashes) and any other elements that can be securely removed from your contract.

Merkle trees

If you are a developer, you will know what Merkle trees are (hopefully). However, the issue is, do you know when to use them? Well, this developer didn't know, which caused him to pay about 6.2K for a transaction that was worth 50 dollars.

Firstly, let me provide you with a quick (bad) description that will help us identify their use cases.

Merkle trees are compact (user) storage data, great at storing pieces of the same kind of information. Used when we need to insert external information into the EVM.

This could include, as in the aforementioned case, whitelisted tokens, or other data such as users and their reward amounts. It can even be something more complex, like users and the roles they have (if you have many different roles such as admins, guardians, owners, operators, and so on...).

It doesn't matter what you store there, as long as it's a repeatable patters you can get it off your head and into the code.

Storage Hashes

While discussing Merkle trees, I cannot go away without mentioning storage hashes.

They are incredibly useful when used correctly. However, improper use can lead to complications and can be quite dangerous. Proper use includes, but is not limited to:

• Verifying the important variables on creation.

• Including every variable in the hash.

• Ensuring that once a hash is used, it is promptly deleted.

With these security considerations addressed, let me introduce you to an impressive piece of code:

The snippet above demonstrates how to hash an order and store it in a 32-byte space. Compared to using a giant struct, this hash implementation can save a significant amount of gas.

Furthermore, this approach eliminates the need to store and later retrieve these structs when processing orders. It also removes the need for checks during order processing, as any incorrect user input will result in keccak256 computing an unknown value that won't be stored.

This also involves off-chain elements in a sense, as users are not expected to remember and retain all of this information. Here, technically, the developers have "moved" their storage off-chain (not entirely, but to a significant extent).

Simplicity

I'm saving the best for last. If you're reading this, your attention span is longer than I expected, congrats!

Simplicity is crucial when coding in any language, especially when deploying on the EVM where hacks are everywhere, and the gas cost is higher than Snoop Dogg.

That's why it's crucial to keep everything simple. To achieve this, consider refactoring your functions, making them smaller, and even splitting them if necessary. Your sole goal should be to make everything simpler and clearer to understand, commonly known as “writing clean code”.

It usually takes a few tries, as no developer can code the perfect function on the first attempt. This is me giving you permission to play with your functions. Don't be scared, it's part of the process of real optimization. Slowly but surely, bit by bit, you'll develop better functions and consequently, better contracts.

In the meantime, ensure you're making the function cheaper, not the opposite (and more secure, but that’s for another article *wink*). You can achieve this with foundry gas reports.

An added benefit tis that the code-base will have fewer bugs, and its audit tends to be on the cheaper side.

That's all from me. If you've enjoyed this article, feel free to share it with the people who will need it.

Focus ain't the secret

Another day, another segment of mastering your mind. As always, today you're going to realize that it wasn't your fault, not in your relationships (there you totally deserved everything), but in your career/business. I am going to show you how to unlock your secret potential and achieve what you truly desire.

What you missed

Up until now, you've been aware of only 25% of the equation. Everyone has explained why focus is essential and how to achieve it, but no one has unveiled the other 75%.

Above, you see the "holy trinity" (yes, there are 4 things, but I'm bad at math D:). Here, you're shown:

1. Clarity - to know what you want and how to get it.

2. Energy - your daily energy.

3. Willpower - the ability to execute boring tasks.

4. Focus - the multiplier that focuses (pun not intended) the other 3.

Your mentors either didn't know or didn't care to show you the other parts of the system. They have glamorized focus and its powers (which it has), but focus is only a multiplier. If everything else is at 0, well... you do the math.

I will give you some examples with points so your video game-addicted minds can understand them better.

Most likely, these are your current stats. You are good at focusing and isolating your work. However, the prerequisites that focus multiplies are really low, which will cause your total output to be low as well.

Compare the above to the below, and you will see the difference (it's 5x).

If you little degenerates think that 5x is not that much, please close this article. I you won’t need the skills anyway.

Now comes the important question - “What should we eat for dinner?” No... the other important question - “Well, how do I level up my stats?”. That's what we are going to learn in the next sections.

Energy

Energy is by far the hardest to optimize because it depends on a lot of thing, things that you might like, but are bad for you. However, to achieve your dream goals, you need to make some sacrifices.

If you don't sacrifice for your goal, your goal becomes the sacrifice.

Energy is also the hardest to define. The best definition I have is “zero brain fog”. It's the time when you wake up fully rested, fasted, and your brain feels like it's not yours...

Sleep

We start with sleep, and like our relationships, everyone talks about polymorphism (many), but anyone that tries it always regrets. If you sleep monomorphically (one sleep), it will be easy to find out how much sleep you need.

You might be blessed with a 6-hour sleep or cursed with 10. For the biggest optimization, you will need to know how much you need.

Afterward, you will have to find your chronotype. Chronotype is the word that signifies when you wake up and when you go to bed. If you've heard that some entrepreneurs wake up at 4 AM in the morning, remember that they are either lying or early in the morning is their best performing time. Find yours, and you will be amazed at how easy work becomes!

There are other basic factors that you need to know.

• You sleep best at around 16-19 degrees Celsius.

• Don't eat at least 3 hours before going to bed.

There are probably more that I can think of, but this is going to turn into a sleep article, so I am going to cut it short.

Diet

Similar to sleep, there are many different types of diets. The "best diet" varies from person to person, and some might feel better on keto, carnivore, or other strange eating habits. However, it's best for you to identify which foods make you less productive and eliminate them.

Certain foods, generally fast carbs, can make your brain function like a monkey. They will cause an insulin spike that will make a hungry lion to fall asleep and cuddle with a sheep. As you can guess, this is not good for you. After consuming certain foods (like bananas with honey, I really like those...), your body will expend most of its energy towards digesting the food, rather than engaging in thoughtful activities, ultimately making you "dumber."

Find what foods your body functions best on and stick with those. Additionally, ensure you are getting enough protein, fats, vitamins, and all the other important bits.

Substances ?

That depends on you, just try not to overdose... with coffee (I know what you thought). Different stimulating substances like caffeine and black/green tea are quite useful, as long as you don't become dependent on them.

Being dependent means using them not because they make you better, but because without them you are worse. You know that you have reached that point, the turning point where you no longer use caffeine, but caffeine uses you. When you reach this point of “I can't work without coffee”, that is when you should stop drinking it (at least for a while) - video on the subject.

On the other side, coffee and other 'substances' can be quite useful if you know how to use them right (another video). They are not for pleasure but for work, and if you use them, it should be for this purpose and this only. Currently, I am on the side of “abusing” coffee for only important work. This means once a day for 6 days a week (at most), and sometimes I will take breaks of 2-3 days.

With coffee, you build tolerance. If you want to be more efficient (and less addicted), you need to know:

1. How fast you are building tolerance.

2. How much caffeine you need to have high energy (and enter flow easily).

The first point you just need to figure out by yourself, give it a try and see when the effect of coffee starts fading out. Then you will know when to take a day off from caffeine.

The amount you need will determine the task you are doing. If it's manual, you may need higher amounts, and if it's mental, I suggest microdosing it. When doing mental tasks, you need a calm and effective mind, not one that is high on coffeeine and ADHD.

Clarity

I know you degenerates think "I want money" is enough for your clarity, however, if it were enough, you would have skipped this section of the article, wouldn't you?

"I want money", "I want fame", or "I will show them all" are good starting points, however, we need to improve on them as they are really vague. We need to pick a clearer goal for you, one that will satisfy this need and is also autistically easy to follow.

Most likely, if you are reading this, you are some kind of programmer, so this example will suit you.

"I want to learn solidity"

• Complete 1 part a day of the 30-part solidity course.

• Read 1 article a day on how different crypto protocols work.

• Post what you learned on Twitter every day.

Depending on how much free time you have, you can add more tasks, remove some, or make some more extensive.

The above example is a good level of clarity (you can always make it better and easier to follow) that will give you 3 tasks that you need to finish before turning the PC off. This will prevent you from distractions, as you know you need to finish these 3 before wasting your time on YouTube cat videos.

And what next? What happens when I learn solidity? Well, your next step to your final goal "make money", is to get hired as a solidity developer. Here are a few goals you will need:

• Start working on a project (for production).

• Post actively on Twitter and other social media.

• Complete puzzles and participate in hackathons/CTFs.

If your semi-goal changes in the meantime from "I want to work as a developer" to "I want to have my own project", you can always switch or replace some of your daily tasks.

It's that simple. Clarity is to have a direction and a plan. The clearer the direction and the better the plan, the faster you will move forward in its execution.

Willpower

The easiest to understand, and the hardest to implement.

Willpower is the ability to brute force through things that you don't like.

You are bored and don't want to write code, "Forget it, I am writing code now," and you open the editor and start writing.

This is not discipline, this is willpower, and your willpower is like a battery. The more you use it, the less you have left in the tank. To recharge it, you will need better sleep and some passive and active rest. You can check those in another article of mine (after you finish this one wink).

https://mirror.xyz/0x3b338e782859aE11c0B15694bc482a9aFa4A5809/r8pU23Aucpp7jnOaP_4lIE99KsFJGBCSm0yY_ynNv38

But don't worry, there is good news too! The "battery" that contains your willpower can actually get bigger. Yes, like every other skill in your life, you can also improve in willpower. And how is that done, you may ask... Well, if you go to the gym, you "break" your muscles, and they become bigger. The same applies here.

The more you use your willpower, the bigger the battery will become.

But keep in mind that it can't be infinite, you can run out of willpower, no matter how big your battery is. This is a reminder not to always rely on it, as it will fail you when you most need it.

If you want an even better explanation, go and check out one of the videos where I learned these subjects - here.

That should be all for today, thank you again for giving me your time and attention. If you enjoyed this article, feel free to tweet about it!

1. Report everything.

2. Write good issues.

3. Spend as much time as you can.

4. Close the cycle

5. Think outside of the box.

Report everything

One extremely common mistake that most auditors make is catching a bug and not reporting it. That may seem stupid. Yes... yes, it is.

However, most beginners are not sure what a bug is and what is not. Some people think only major issues are bugs, like stealing some funds or breaking the whole contract, and so on. However, really simple bugs are also bugs, and they usually are the bugs that pay the most. These bugs can be a simple discrepancy between the docs and code, small errors, things that are "strange" but don't cause any issues. An example is a recent audit of mine, where a MED is a slight discrepancy between the docs and the code. The bug was worth some money, not because no one knew it or that it was an "advanced" exploit, but because they didn't report it as they thought it was informational at best.

That moves us to the second point. Most people are afraid of submitting stuff. I am questioning Sherlock, as they are the guys that punish people for submitting false bugs. However, some people are transferring that feeling of being wrong when they submit an invalid bug to other platforms, like c4. On platforms that don't punish bad reports, I would suggest reporting everything that you find as "strange". Put the big stuff as MEDs and the small stuff as LOWs (however, make the report good so you can argue for escalation if that LOW is a MED at post-judging QA). There is no penalty for submitting invalid stuff (unless you submit 15-20 awfully invalid findings, but you are not that stupid... right?). Of course, try not to spam the judge with crappy reports and half-baked findings.

"You miss 100% of the bug you don't report."

Look at another perspective, the perspective of the developer. He is paying for the audit, and as such, you should provide him with as many bugs or inconsistencies as possible. Reporting something "strange," which may be a bug or may not be, is you trying your best to make the code as secure as possible. Because if something "strange" is left out, on future updates, it can be the reason a bug pops up.

Write good issues

Now, while we are on the topic of issues and reports, it is really important that you write as good reports as you can. That skill purely affects your payout, as you can be a really good auditor, but bad reports will consistently get your findings invalidated or marked as 50% (half the payout). And if you are really good at writing those reports, you can get "selected for report," a nice title with a 30% reward increase for this issue.

Here, I am going to give you the short version of "How to get selected for report every time” and if you want more details, check my other article about writing the best report there is.

https://mirror.xyz/0x3b338e782859aE11c0B15694bc482a9aFa4A5809/PaGjtbM61hxA1kAqJYXPfrzNaW7Sh_gCX3M5XGsV0SU

1. Make it simple - Be sure that, even if the judge hasn't looked at the codebase yet, he will know what you are talking about.

2. Use ChatGPT - Make the report yourself and use GPT just to structure it better and fix the grammar mistakes.

3. Do a POC if you have time. This is avoiding the 50% mark and making you really close to being the selected report. However, just a POC won't make you selected, as you need a really good-looking report. And for God's sake, make those POCs in a Gist, don't just put 500 lines of code into that report.

4. Use fancy math - Use markdown mathematical formulas ($$ \frac{1^{(n-1)}}{n} $$) if there is math involved.

5. More links, the better - Every time you reference a function, make it a link. Firstly, they add some color to your report, making it less blunt, and secondly, they make it really easy to follow with the main code.

6. Make good resolutions - After doing the report, think of what's the best solution. If it's some code that needs to be redone, do a diff, that makes the solution seem extremely simple.

7. Use tables for examples with a lot of prerequisites - save space and looks really good.

8. Use the solidity tag instead of jsx - that may be obvious, but some of you mules are still marking your Solidity code with jsx.

Spend as much time as you can

When you are done auditing and you think you are finished, I want you to know that actually, you are 50% done, if even that much. There are always more bugs to be found, more ways to break the system, and more tricks you can pull to score those fine As on QA reports.

Why is that, you may ask? As described by the best auditors on Twitter, they only catch about 50% of highs and 35-50% of mediums. So why do you "finish" the audit with 6-7 bugs? What makes you think that you have found every bug you can find?

We often wrap up audits and call them finished because we looked at everything, our minds are exhausted, and we can't think of any new ideas. We already know the code by heart and every aspect of it. The audit gets hard as we are forced just to think and think of what could go wrong in a system that by now seems empty of bugs. However, no matter how many bugs you have found, there are always more. You need to stop listening to your mind telling you to jump ship to the next audit, focus on the thinking, and be there looking at the code.

Most times, you are able to find one or two more bugs. Even if you found one, these bugs are often the most valuable. This is because there is another really important concept:

"If it's hard for you, it's hard for everybody."

This means that when you reach the point that you want to quit, other auditors have reached it too, and they have chosen to quit.

One really good piece of advice I've heard from Owen is after you have finished the audit, submit everything, read the code one last time. Read it line by line, the same way that you did when you were starting the audit. Most likely, you will catch a few more leads.

Close the cycle

We need to close the learning cycle as quickly as possible. Imagine it as a large circle, the faster you close it, the smaller it becomes. We need to make it as small as possible in order to do the most laps, where with every lap you get better and better. This is advice for anyone who wants to progress quickly, because the more you repeat the same mistakes, the more they will slow you down.

Everyone advises to "review your past audits," but no one teaches you how to accomplish it. That's why today I am going to give you the most straightforward advice that anyone could follow, maximizing your learning from every past issue.

Get yourself a note-taking app, I use Obsidian, and we will start making notes.

1. Make sure you do it as soon as possible.

2. Write the audit name + summary. Write the date and name of the project ('2077-12-coconuts') and a short description below (like a summary).

3. Write every issue with your own words and link it to the original report.t. Avoid laziness and write each issue in your own words, that's the primary learning mechanism.

4. Write three or more questions on how this issue can be found again.

5. Close the tab and try to name every issue and how it's done. This is the secondary learning mechanism. Your brain makes memories not just from reading but from pulling information out of itself.

6. Read all the issues you weren't able to explain.

If you wish, you can repeat steps 5-6 until you know every issue by heart (it will take 2-3 turns). However, we have already achieved maximal learning with minimal effort. This kind of summary will likely take 30 minutes to an hour, and you will have reviewed every issue, whether you found it or missed it. The important thing is to know how these issues are found and what their structure relies on.

Think outside the box

Finally, but most importantly, you will need creativity for this job. That is the hardest part, yet the most proficient one. Because it doesn't matter that you spend all day in order to find that finding, it won't matter that this is your only issue, and it won't matter if your report is mediocre if you are the only one reporting this issue. At the end, if you want to call yourself one of the best, what will matter are your skills at finding the hard-to-find bugs.

This here is what defines good from great. Your ability to be creative and think outside the box, for your brain to work in ways that no one else can. This is why this is the hardest thing you can do, and of course, the one that pays the most. This is all great, but "How is that done?" is the question you are asking yourself.

To think outside the box, firstly, you will need a box. These are the fundamentals, like solidity, how transactions work, how big protocols work (UNI, COMP), and so on. You will learn them with time, as some audits will require you to know how certain protocols work. Focus on learning things that are important and useful for what you need at the moment.

You will need to view the system as a whole, not function to function interaction, not contract to contract or protocol to protocol, but the whole web3 as one giant sphere of possibilities. How the contract you are currently auditing will interact with other contracts and the network, this is where the floodgates of creativity will open.

Here is where I will end, as I have not yet reached this part. I can write more stuff about it, I can say more things that you can do, that you will need, but those will be just guesses.

I hope you enjoyed the reading. Give this article a tweet and tag me at 0x3b so we can share this knowledge faster. See you next time.

It's really important to write good reports. That skill purely effects your payout, as you can be a really good auditor, but bad reports will consistently get your findings invalidated or marked as 50% (half the payout). Also if you are the only one reporting this issue, a good report can be the difference between invalid and solo. Finally if you are really good at writing reports you can get "selected for report", a nice title with 30% reward increase for this issue.

Make it simple

Be sure, even if the judge hasn't looked at the code-base yet, when he reads your report he will know what you are talking about. Simple, clear, straight to the point.

Use ChatGPT

Compose the report yourself and use GPT to enhance its structure and remove any grammar mistakes. If you are like me, you'll find it quite useful.

Here's my approach:

paste the report

If you're good with how you've set things up and the words you've chosen, go ahead and "check for grammar." If you want to make your description sound better, you can "improve on the report." And if the words seem a bit too complicated, just "use simpler words." But sometimes, these choices can be a bit much – either too complicated or too simpler. If that's the case, you can "use simpler words, preferably grade (pick one from 8-12) reading"

Do a POC if you have time

This helps avoid the 50% mark and brings you closer to being the selected report. However, just having a POC won't make you selected. You also need a well-presented report. And for god' sake, put those POCs in a Gist, don't simply insert 500 lines of code into the report.

Use fancy math

Always use markdown mathematical formulas (using $$), if there is math involved.

You can:

toleratedGaugeWeight = 80000e18 * 1.2e18 / 1e18 = ...

However it looks 5x better if you do it the correct way. You insert the formula into GPT and let it write it for you.

I use:

"represent this formula in .md mathematical format using $$"

paste math here

More links, the better

Every time you reference a function, make it a link, firstly they add some color to your report, making is less blunt, and secondly they make it really easy to follow with the main code.

" Due to the nature of how ArcadeAirdrop is made and the expectation that there might be a change in the Merkle tree in the near future, users will expect to be able to claim the extra rewards (if they are increased on Merkle root). However, because there is a problematic if statement (that is inherited in ArcadeAirdrop by ArcadeMerkleRewards) users that have already claimed their rewards will have no share of the future ones. "

Tell me, doesn't the above look better that this bellow? If you think it's the same, you have a bad taste.

" Due to the nature of how ArcadeAirdrop is made and the expectation that there might be a change in the Merkle tree in the near future, users will expect to be able to claim the extra rewards (if they are increased on Merkle root). However, because there is a problematic if statement (that is inherited in ArcadeAirdrop by ArcadeMerkleRewards users that have already claimed their rewards will have no share of the future ones. "

Make good resolutions

After completing the report, consider the best solution you can implement. If it involves code that needs to be redone, use diff, this makes the solution appear extremely simple.

See how clear the one below is. It clearly highlights the issue we have.

If you encounter an issue for which you don't have a clear solution, it's better to admit uncertainty than to suggest something useless.

"Because I am unsure of how the developers want this protocol to function, I am unable to propose an effective solution to resolve this issue. Significant parts of the system need to be redone."

"Because this issue relates to the overall structure of the protocol, and not some specific one liner issue, I am unable to give an exact solution."

Use tables for examples with a lot of prerequisites

This is an area where providing examples in bullet points can make your report long and boring.

• the size of the pool is 10,000 tokens

• the max LTV is 50%

• and so on...

Can you imagine yourself writing all these as bullet points? Why not use the table below, it's a great summary and it looks amazing!

Use the solidity tag instead of jsx

That may be obvious, but some of you mules are still marking your Solidity code with jsx (I also was one of these mules D: ). This is really annoying because some things have color while others don't. It gives this feeling that it's your first report ever.

Finally, after completing most or all of the tasks, there's no guarantee your report will be chosen. If you believe your explanation is the best, wait for the escalation period and then explain why your report is actually the best. Sometimes, the judge has too many things on their mind and may not thoroughly compare all the reports. This is why you should comment and escalate with a clear description stating why your report is better.

For example: The currently selected report looks good, however, I believe this one highlights the issue more clearly (selfishly pointing to my report). The report is simpler and easier to understand, with a more in-depth explanation, a great solution, and even includes a runnable POC!

If you enjoyed this article, feel free to tweet it out. This way, we can help share knowledge faster. See you next time.

Firstly, I may be a woman (I almost believed myself on this), and secondly, that is possible with mindless tasks, ones that don't require much focus or willpower. However, if you are reading this article, most likely, your primary work/business requires some hard focus, the kind that you need to pull from the back of your dead soul.

For this to happen easily and at will, you will need some good rest. I am not saying you can't work 16 hours a day, 7 days a week. I am saying that you don't have the balls to do it. If you want to consistently put in 12-hour workdays, 6 days a week (maybe 7 if you are a maniac), you will need some good rest.

Now, I am going to shut up with my rant and just tell you what's the best rest and why.

What?

Boredom. It's that simple. You can either:

1. Meditate.

2. Stare at the wall/ceiling.

Here, the important part is to stare at something bland that is not moving and not changing (like a wall...). I prefer to lay on my bed (I set up an alarm if I fall asleep) and watch the ceiling. Meditation also works, but if you are like me, it will need some effort and willpower to meditate, and that is not what we want. We want full rest mode.

I've been doing this for a few months, and I can say that it is by far the best rest thing you can do. Depending on your work, you can stay focused for an hour and a half, maybe 2 hours (maybe 3 if it's really pleasing), and afterwards you can take a 10-15 min break, just lying on your bed letting your mind think (or try to fall asleep and take a 10 min nap).

To this, I can also add my Sunday "break." It is simply the above but exaggerated. Where you can lay on your bed and stare at the ceiling for 2 hours (maybe 3 if you want to have a bigger effect). It is really important not to fall asleep, that's why you need set up an alarm every 20-30 min. Here we want to make your brain think of all the things it wants to think about. Just let yourself think (you have the time, wink). This exercise is extremely boring, as after about thirty minutes to an hour, it will hit you. You won't want to lay there doing nothing and will want to go do some productive things, but bear with me, last the 2 hours. This will have a profound effect on your mind.

Now when you have finished this, you can feel 2 things. Either that you are sleepy or energized. If energized, just go do your work. However, if you are sleepy, we need to start moving your body, do any task that you have planned for the day, or take a short walk (15-20 min) without listening to music.

Why?

Now it's the interesting part. Work is the same thing as exercise, however, its effects are larger on the brain than the body (yes, you can feel sore after some mental work). And just like when exercising, you pause between sets, here, we will also need that "pause".

However, we need to make the rest relaxing rather than stimulating. This is the most important part, as some things that people consider "rest" are not actually rest (like TV, video games, checking Twitter, or Instagram). Stimulation on rest time is like bench pressing on your 3m squad rest break. You think it won't affect you because these are 2 different things. However, if your brain can think, you should have been driving a Lambo by now, instead of reading this article.

This is the magical part here, as the brain likes to stimulate itself, and like the 30-year-old single women, the bigger the better. If we make your "rest" more stimulating than your work, your brain will choose... well, to "rest." That is why we make it so boring that your brain is thrilled to work again.

The extra bonus part is that you don't have infinite thoughts. You think you do because your brain is always full of them. However, that's because you have no waking moment when you and your brain are together. Every waking second you spend either consuming content or multitasking, like watching a YouTube video while preparing dinner, listening to music while walking the dog, and so on.

However, if you are left with enough time with your brain, you will just run out of things to think about. All the cringe childhood memories, the awkward moment when you tried to flirt with a girl in the gym, all of that, gone. And what happens afterward, you may ask. Well, here is a 3-minute video about the subject link (it's like your brain overdosed on brake cleaners).

Sweat out the stress?

Rest and boredom are good, but you will also need an active way of removing stress from your body. This can be going to the gym, running, some fighting sport, or anything that will get you focused and make you sweat.

These are needed because with time, you can build up frustration and anger. The rests above will do nothing about these emotions, and if you let them build up with time, they can be the main source of your burnouts. And what better way to remove anger than hitting 100kg on the bench (the weight of 885 cheeseburgers, for all my American readers).

What I've learned from successful people is to space your work between these active stress removers. Simply, wake up -> work -> gym -> work. This will help with the workload, as if your work is more dense and requires large quantities of focus, splitting it into 2 will give you two 4-5 hour work sessions with about 2 hours of "rest" in between.

That's all for today. Also, if you enjoyed it, feel free to share it on Twitter and tag me at 0x3b.