Integer division truncates. In a DEX, every truncation is a decision about who eats the lost fraction. Uniswap V3 answers it the same way in every branch of every function. Input rounds up. Output rounds down. Fee rounds up. Every wei of rounding error lands on the pool's side of the ledger.

The highest-return security spend for most new protocols isn't the audit. It's the threat model written before it and the monitoring running after, because those two cover the window an audit structurally can't. I sell audits. Judge the argument on the numbers rather than on who's making it — they're in the lesson.

When I audit staking systems, I treat emergency mode as a separate product state. I ask what a user can still do after deposits stop: claim, unstake, or exit. A pause is not safe if the protocol survives by trapping the people it is meant to protect.

If you hold a Uniswap V3 position and call collect, you may withdraw less than you have earned. collect does not settle fees. It reads tokensOwed as it finds it, and tokensOwed only changes when something calls position.update. The fix is burn(0) first. It is a documented idiom, not a trick.

Weekly membership value should be visible in the work, not hidden in landing-page promises. This week inside Zealynx Insiders: WHAT MEMBERS WORKED ON One member completed a Teller audit and turned two collateral-flow findings into a broader review method.

A bridge lost $624M and nobody noticed for six days. Not a clever exploit — no alert existed for a large withdrawal, so nothing fired. A user found it when their own transaction failed. Monitoring costs $2-20K a month. It's the line most budgets don't have at all, and it's the difference between four hours and six days.

When I audit ERC-4626 vaults, I do not stop at the normal deposit path. I test the empty-vault state, direct donations, and rounding together. Dead shares help, but the real question is whether any realistic sequence can make a user deposit mint zero shares.

Without prior experience auditing manually, I don’t think AI auditing can be done properly. In my final Quantus sweep, five of six parallel agents returned reasoned negatives. The sixth produced passing PoCs, but they only rediscovered an existing finding. None of those outputs could be accepted at face value. I strongly question every finding the agents return. But I also question them when they return nothing. A reasoned negative can help me decide where not to spend more resources. It does not mean an area has been completely checked, and it definitely does not mean the audit is done. This is what makes leading AI audit agents difficult. You need to stop them from inventing vulnerabilities to satisfy the prompt, while also stopping them from declaring completion because they exhausted one path. I don’t see this as replacing one auditor with six agents. It is about navigating and leading the resources LLMs give you: challenging findings, questioning negative results, noticing missing coverage and deciding where each agent should search next. The agents can explore and test much more than I can alone. But my previous manual auditing experience is what lets me judge whether their work actually means anything.

burn is the one place in Uniswap V3 where you can see both halves of the rounding policy side by side. Mint rounded up against you. Burn rounds down against you. Every rounding boundary in the protocol leans the same direction. The dust stays in the pool.

What a security budget actually contains, at $50M TVL: Audit, $40-100K. Monitoring, $2-20K/mo. Bounty max, 10% of what you hold. Incident retainer, ~$15K. Verification in CI, mostly engineering time. Most founders write one line for the first item and nothing for the rest. That's the real mistake, not the size of the number.

My view: if one role can move every holder’s assets, it is a custody system—not a normal admin permission. I would require multiple signers, an execution delay, and a legal authorization trail before treating forced transfer as production-ready.

Call burn on your entire Uniswap V3 position and your wallet receives exactly nothing. Not a revert. It works perfectly, and no tokens move. Your position became a debt the pool owes you. Getting it out is a second function, and that split buys three things.

The best thing I did with Hermes was stop treating it like one assistant. It works much better for me as a group of small agents with one responsibility each. Cron starts the work. Files preserve the state. Agents run independent parts in parallel. Telegram becomes the approval gate before anything public or difficult to reverse. This is how I have one agent maintaining three websites every day, while other workflows handle research, content, audits and operations without all of them sharing the same context. It works, but most of the orchestration is hidden across prompts, cron jobs, files and handoffs. When something fails halfway through, understanding what completed and what needs to run again is still more manual than I would like. Hermes now has workflow graphs with parallel nodes, approval gates, budgets, explicit failure states and resume. If one node changes or crashes, it can continue without repeating everything that already worked. I want to move one real workflow into it and compare both approaches. What I want to understand is not whether the graph looks better. It is whether the workflow becomes easier to inspect, recover and improve without adding another layer I need to maintain.

A threat model isn't a document your engineers write. It's four questions a founder answers: who would come for this, what do they get, what will they spend, and which of our functions is worth that spend. The output fits on one page and it reorders your entire security budget. Lesson 1 shows the page.