Post

@bytes032.xyz
@bytes032.xyz@bytes032·
When I first dove into solo audits, I was a hot mess. But then, I made a guide I swear by. Here's the 3-step plan that's nabbed a critical bug in my last 5 audits. 🧵👇
English
13
36
202
35K
@bytes032.xyz
@bytes032.xyz@bytes032·
Step 1: I only tackle X nSLOC a day. Some folks scan the whole system first, but I flip that script. I take it slow, focusing on a section daily, like a group of contracts or even a single contract if its big enough.
English
0
0
0
2.7K
@bytes032.xyz
@bytes032.xyz@bytes032·
By doing this, here's what's gonna happen: • You'll dive deep into that chunk of codebase • No more feeling swamped by endless contracts you just scanned • No more bouncing around without really getting the gist of things
English
0
0
0
2K
@bytes032.xyz
@bytes032.xyz@bytes032·
Step 2: I don't touch the docs until I've got the codebase down. After Step 1, the next hurdle's likely here. Rather than hitting the docs before the audit, I say do it after you've grasped the codebase. Why, you ask?
English
0
0
0
2K
@bytes032.xyz
@bytes032.xyz@bytes032·
Docs need the same "audit" level focus. Doing both at once? You're gonna half-ass both. Instead, review the code line by line, then show the same care to the docs. After, compare to spot any differences.
English
0
0
0
1.8K
@bytes032.xyz
@bytes032.xyz@bytes032·
Step 3: Spot variables that multiple places/contracts can change. Once you've got that, use Miro/Draw.io or whatever floats your boat to sketch a state machine. It helps you see how one contract can totally mess up another's state in sneaky ways.
English
0
0
0
1.9K
Paylaş