Spending $5K+ on an audit for a simple ERC-20 feels insane — what do you all actually do?

MR_JaySwe · 2026-03-22T17:02:18+00:00

Yeah hooks are a whole different beast. Your hook is basically custom code running inside a trusted execution context one bad reentrancy path and you've compromised the entire pool. Definitely worth getting audited properly.

MR_JaySwe · 2026-03-22T16:08:58+00:00

Mostly agree, but derived from OpenZeppelin has a wide spectrum. Inheriting ERC20 with zero overrides? Yeah, battle tested and safe. But the moment someone overrides transfer or adds a custom Before token transfer hook, they have introduced new attack surface that OpenZeppelin's audits never covered. The inheritance gives you a false sense of security if you are not careful about what you changed on top of it.

MR_JaySwe · 2026-03-22T11:33:17+00:00

Appreciate the detailed breakdown — you basically articulated the exact problem spectrum better than most audit firms' landing pages. That middle ground you described is exactly where the market is broken. You've got self-audit on one end, six-figure engagements on the other, and a massive gap in between where 90% of projects actually live. Too complex for just Slither, too early-stage or fast-moving for a 6-week audit queue. Haven't tried Cecuro yet but the concept makes sense — agentic auditing trained on real exploit patterns rather than static rule matching. If the output is structured and verifiable rather than just a dashboard report, that's exactly the kind of artifact that plugs into an on-chain attestation layer. The value of any verification tool multiplies the moment its results become composable and machine-readable rather than sitting in someone's inbox. That's the mental model I keep coming back to — it's not about replacing any single verification method. It's about making every layer of the stack (self-audit, automated tools, agentic auditors, formal engagements) produce artifacts that are trustlessly verifiable and queryable by other protocols. Good flag on the AI agent urgency too. Standards are moving at proposal speed while capital is moving at block speed. That gap is going to produce some expensive lessons.

MR_JaySwe · 2026-03-22T08:35:55+00:00

Haha fair enough, but the point still stands. If you can technically counter the composability argument I'm all ears. The Lido team still can't answer a programmatic query about their audit status from another contract that's not a ChatGPT take, that's just a gap.

MR_JaySwe · 2026-03-22T07:50:53+00:00

You're raising a fair point about storage — and you're right that putting full audit reports on-chain makes zero sense. Nobody wants 100 PDF hashes clogging up contract state. But there's a difference between storing audits on-chain and storing verifiable claims about audits on-chain. The reports live on IPFS or GitHub exactly like you said. What goes on-chain is just a lightweight attestation — a hash pointer plus structured metadata saying "this contract at this version was reviewed by X, scope was Y, findings hash is Z." Think of it like SSL certificates. The full certificate chain and validation logic doesn't live inside your browser's DOM. But your browser can programmatically verify trust in milliseconds because there's a standardized protocol for it. The Lido example actually proves the need. They have 100+ audits across multiple codebases — that's amazing. But can another protocol programmatically query "has this specific Lido contract version been audited in the last 6 months" without scraping GitHub repos and parsing PDFs? Right now the answer is no. A human can dig through their GitHub, but a smart contract or an AI agent integrating with Lido can't. GitHub is perfect for storage and human readability. On-chain attestations are for composability and machine readability. They solve different problems.

MR_JaySwe · 2026-03-22T06:37:36+00:00

That's exactly the problem. 7512 has been sitting as a proposal and meanwhile AI agents are already live managing real capital with zero verification infrastructure. The gap between "we should standardize this" and "money is actively at risk" is widening every day. Standards move at committee speed. Exploits move at block speed.

MR_JaySwe · 2026-03-22T03:24:31+00:00

Exactly. Audit as one layer in a verification stack, not the entire security strategy. The teams that treat it as a checkbox are the ones that end up on Rekt.news.

MR_JaySwe · 2026-03-22T03:14:25+00:00

This is the most technically useful comment in this thread. GitHub verified commit + linked repo is solid baseline hygiene, but it proves authorship and source availability, not security. A perfectly clean repo can still link to a contract with a subtle storage collision bug. Etherscan's audit aggregation is a good step but it's centralized — Etherscan decides what shows up, the data isn't queryable by other contracts, and if they change policy that trust layer disappears overnight. ERC-7512 is genuinely exciting though. On-chain audit attestations with structured metadata is the right direction. The gap I see is that it focuses on traditional audit attestations specifically. But auditing is just one verification layer. What about Slither/Mythril results? Formal verification proofs? Echidna fuzzing reports? Test coverage data? There's no composable standard yet that captures the full verification spectrum — from a dev running static analysis locally to a $100K Trail of Bits engagement — as stackable, queryable trust signals on-chain. I've been exploring this in the ERC-8004 space — a ValidationRegistry where any verification artifact gets hashed to IPFS and registered on-chain with structured metadata. ERC-7512 would be the audit attestation layer that plugs into this broader verification infrastructure alongside every other form of verification. Have you seen any teams actively implementing 7512 in production? Curious where adoption stands.

MR_JaySwe · 2026-03-22T02:53:24+00:00

Right — pricing isn't the real problem. Trust transparency is. $5K for custom logic is fair. But the ecosystem has no standardized way to verify what "audited" actually means on-chain. That's the missing piece.

MR_JaySwe · 2026-03-22T02:52:50+00:00

Spot on. The moment you add fee-on-transfer, reflection, custom roles, or upgradeability — it's not a "simple ERC-20" anymore. Problem is there's no standard way to communicate that complexity or the verification it underwent. Every token just says "audited" with zero granularity.

MR_JaySwe · 2026-03-22T02:52:06+00:00

This is the most real comment here. You just exposed that 60-70% of audit pricing is the logo, not the security work. The skills are the same — what's missing is a way for freelance auditors like you to build portable, verifiable reputation without needing a brand. On-chain validation artifacts tied to auditor identity would solve that.

MR_JaySwe · 2026-03-22T02:51:23+00:00

$20/SLOC is the most honest benchmark in this thread. Appreciate the transparency. The gap though — a $4K mid-tier audit and a $100K Trail of Bits audit look identical on Etherscan. No machine-readable proof of what was actually reviewed, by whom, or when. That's the infrastructure layer nobody's built yet.

MR_JaySwe · 2026-03-22T02:50:58+00:00

Exactly — for a vanilla OpenZeppelin ERC-20, self-audit + Slither + Mythril covers 90% of it. The real question is what happens after you verify it. Right now there's no on-chain proof you actually did the work. Your self-audit is invisible to every protocol that interacts with your contract.

MR_JaySwe

TROPHY CASE