Veridise

• Name: Veridise
• URL: https://veridise.com/
• Category: formal-methods security company / zero-knowledge audit operator / blockchain-security tooling company
• Summary: Veridise belongs in companies/, not only projects/, because the useful question is not just which tool exists? but which named operator turns ZK-circuit review, formal-methods-heavy audits, static-analysis and fuzzing tooling, and AuditHub workflow packaging into part of the practical release boundary for downstream teams? The practical leverage sits less in one audit artifact than in who decides the reusable tooling surface, the client workflow, and the formal-methods posture customers inherit.
• What it does:
  • Performs smart-contract, blockchain, and zero-knowledge audits for protocols, infrastructure teams, and cryptography-heavy projects
  • Develops in-house tools spanning static analysis, fuzzing, and ZK-circuit determinism checks
  • Positions itself as a specialist in zero-knowledge security across zkVMs, ZK DSLs, and privacy-heavy systems
  • Publishes AuditHub client tooling that exposes a programmatic API/CLI workflow for version upload, analysis runs, monitoring, and finding retrieval
  • Maintains a public GitHub organization with security research, ZK tooling, and AuditHub-related repositories
• Key claims:
  • Veridise is large enough to take seriously: its public materials claim 150+ audits, a 35+ person team, and formal-methods roots rather than generic audit-shop positioning.
  • The firm’s real niche is ZK-heavy work. Public references across Circom, Halo2, Nova, Plonky2, gnark, zkVMs, and privacy systems make that clearer than generic homepage copy does.
  • The useful artifact trail is not just reports. Veridise exposes a real tooling line — Vanguard, OrCa, ZK Vanguard, Picus, and AuditHub workflow plumbing — which is why the company note can answer questions the old project note could not.
  • AuditHub matters because it turns some of the security workflow into a repeatable client surface instead of keeping everything inside consultancy black boxes.
• Whitepaper: No single canonical company whitepaper is the point here. The clearest current source of truth is Veridise’s official site, ZK audit and tools pages, and the GitHub / AuditHub client materials collected in ../whitepapers/veridise-primary-sources-2026-04-27.md.
• Sources:
  • https://veridise.com/
  • https://veridise.com/audits/zk/
  • https://veridise.com/security/tools/
  • https://github.com/Veridise
  • https://raw.githubusercontent.com/Veridise/AuditHub-Client/main/README.md

Internal linkages

• Project-layer alias: veridise.
• Useful adjacent company reads: certora, runtime-verification, and zksecurity.
• Useful contrast where the emphasis shifts more toward Solana-security specialization than ZK/formal-methods tooling depth: sec3.

Protocol / company boundary

• There is no especially useful standalone Veridise protocol boundary doing the analytical work here.
• The meaningful surface is a company-run review-and-tooling workflow: ZK audits, formal-methods-heavy security work, static-analysis and fuzzing tooling, AuditHub automation, and the release-gating posture customers may start treating as part of real deployment process.
• That is why this note belongs in companies/: the sharper question is who authors the workflow and tooling defaults around this assurance stack, not whether Veridise is a neutral protocol primitive.

Control surface

• Practical leverage sits in which circuit and zkVM families Veridise prioritizes, how its tooling frames correctness checks, what AuditHub exposes as the standard workflow, and how formal-methods-heavy review gets packaged into launch and remediation decisions.

• The sticky dependency is workflow authority: once teams rely on Veridise tooling or managed review posture as part of deploy-or-don’t-deploy judgment, the company becomes part of the effective assurance boundary even without holding onchain keys.

• Read Veridise as a formal-methods and ZK-security company first, not as a standalone protocol surface.

• Last reviewed: 2026-08-11 UTC