How to raise a $10M seed round

Earlier this week, we won a $2.5M bug bounty—the largest bounty received by an AI agent ever. This was a bug in a major blockchain, and it affected >$100M of funds at risk. We found the bug fully autonomously using V12, our AI security agent, and worked collaboratively with the team to remediate the issue.

V12 isn’t a generic agentic security tool. It regularly finds critical bugs like this, along with countless 0days (including Linux LPEs, QEMU escape, Postgres and Redis bidirectional RCE). That’s because, while we are building a product, our main mission is to research and build dangerously powerful offensive security tools. To make this possible, we’ve raised a $10 million seed round led by Electric Capital, with participation from angels including Walden Yan, Ari Herbert-Voss, ZachXBT, and samczsun.

We encourage you to try V12 yourself. It’s self-serve, and you’ll get $200 of free usage upon signup.

Part 1: What we’re doing

Our goal is to build a cyber nuke. That means building something that can find all of the bugs in a system. This is interesting because such a system would allow you to exploit software that’s previously considered secure. This capability would be so powerful that the world cannot ignore it. This hasn’t been possible until now, but frontier AI changes this.

We are not doing pentesting. Black-box pentesting that simulates an outside attacker isn’t interesting to us. It’s a saturated market, and we don’t want to make another product that throws XSS payloads. An agentic pentest is great for finding some bugs, but what we want is something that finds all of the bugs. That isn’t possible without reading and understanding code. We need to focus on white box code auditing, which looks more like vulnerability research.

More concretely, that looks like a system that can reason about code and all of the underlying abstractions, even creating new ones (e.g. weird machines). We want a system that doesn’t just find bugs, but can invent entirely new bug classes. That being said, this has also been the area of security that has most resisted automation. A lot of vulnerability research looks like carefully reasoning about code and proving to yourself “no, this can’t be buggy” or alternatively, wondering “wait, what if…?” All of this requires human-level intelligence, which hasn’t been possible to scale until now.

So in short, what we want is an AI system that takes arbitrarily large and complex codebases, breaks it down and understands it, synthesizes all of that together, and uses it to invent—not just discover—bugs and exploits.

Of course, a system that can truly find all bugs is not really possible; that’s the halting problem in disguise. It’s equivalent to proving that something has no bugs, where exploits are counterexamples. You can make programs that are arbitrarily hard to exploit, for example, a program that’s vulnerable if the Collatz conjecture is false. But we intend to push the limits and build the most powerful approximation that’s practically possible.

And none to guide us

Let’s say we actually build the cyber nuke. Now what?

Given an explosion of offensive capabilities, the world is going to drastically change. However, it’s unrealistic to expect developers—especially enterprises—to suddenly adapt on their own. Mature organizations lack the vision or expertise to properly make the shift. They also need solutions—functioning, well-designed products—not just “bags of tools”.

Regarding organizations’ ability to adapt, it’s easy to point to new, state-of-the-art models and claim that cyber is solved. It’s another thing to get developers to meaningfully leverage models to secure their code. The average developer is still asking Claude or Codex “review my PR for bugs” followed by “OK fix these then submit PR”. This is nowhere close to sufficient! Attackers already employ complex, aggressive bug-finding harnesses and pipelines. There’s asymmetry here. Defenders neither have the resources to create these pipelines, nor can they amortize the cost across many bug-hunting targets. They need someone to leverage, harness, and deploy these models for them to access their full capability.

Meanwhile, people are busy. They are overwhelmed trying to meet deadlines and ship features on the roadmap. They don’t have time to think about security; they want someone to come in and fix it for them. They need a forward deployed engineer (or something equivalent) that embeds directly into their organization (i.e., in their Slack) and understands their workflow (do you use Github? how do bugs get assigned? what do you use for issue tracking? what agents do you use?), to tailor the product for them.

For the same reason, defenders lose unless they have a product that’s useful out of the box. It needs to be either fully self-serve or come with white glove implementation. It should have the correct form factor (a CLI? an MCP? a Slack agent? a Github bot? all of the above?); it should feel good (not laggy, works on mobile, buttons are where you expect, …); it should make sense (inoffensive billing model, access control works appropriately, logical audit scope selection, …). There are a million things here to get right for such a product to actually be adoptable.

So in short: build something that takes in arbitrarily complex programs, fully reasons about them, up to inventing entirely novel bug classes, package that capability into a useful product, then handhold developers so they can actually use and benefit from it.

Part 2: Things we believe in

OK, so how do we actually make this happen? Any concrete game plan is useless (this is a seed stage company). It makes more sense to lay out our guiding principles and how we predict the world will evolve.

Against “safetyism”

First, we believe the most efficient way to secure the world’s software is to give everyone bug-finding capabilities. We don’t believe in “contact us” or “apply for access”. The logical end state is a world where all (autonomously findable) bugs are found and patched. Gatekeeping access just slows down this process. Capability improvements create an arbitrage for bugs that have newly become cheap, and this arb has to inevitably resolve. For maintainers, adapting to a new security landscape is uncomfortable but unavoidable, and we think the best way to secure the world is to just find all the bugs now. In practice, that means arming defenders with offensive capabilities so they can secure their own code.

To be clear, we want the world to be safe and secure. It’s irresponsible to unleash offensive capabilities the world is unprepared for. But a lot of the “controlled access” or “cyber verification” we see lately is posturing and marketing. People use safety as a pretext for not actually giving anyone access—and in the process, not protecting people at scale. In other words, we’re not against safety, we’re against safety LARP.

Open disclosure

We believe in open disclosure. Responsible disclosure will be seen as an outdated way of reporting and fixing bugs. Embargoes and coordinated disclosure don’t make sense in a world where anyone with the right tools can find and weaponize a vulnerability with minimal human intervention or expertise. We saw this when we found and reported Fragnesia, Pintheft, and DirtyDecrypt—Linux LPE 0days that ended up being leaked before patches landed in mainline kernels. Anyone can patch diff now. The only real solution is eliminating the patch gap entirely. In practice, this looks like more frequent (and automatic) updates and vendors shipping patches the same day (hour!) a bug is found. In practice, that means defenders need extraordinary PoC and fix generation capabilities.

Bug bounties are dead

Bug bounties in their current form will be dead, except for vulnerability acquisition programs for exceptionally valuable bugs. Almost all other bugs will be mined out by offensive cyber tools like V12 by maintainers before they are shipped—before attackers have a chance to audit them.

Maintainers are struggling under the weight of AI bug bounty submissions. Many have announced they are ending bug bounties entirely. Now that bugs have become cheaper than ever, the only solutions are to either (1) stop caring about most bugs or (2) stop shipping them. In the past, (2) was untenable because while virtually all code is flawed, reasoning through all the possible bugs was impossible due to time and cost constraints. But now, we believe it’s not only possible but inevitable.

Crypto security is interesting

Crypto projects are interesting targets and an important wedge for our company. The problem we’re obsessed about is finding all of the bugs, and crypto is the place that currently matters the most. Bugs here are more valuable than anywhere else, and likewise face more attacker scrutiny. Similarly, crypto companies take security more seriously than anyone else. This looks like immutable code, outsized security budgets, and catastrophic consequences for bugs exploited in the wild. More than $500M have been stolen in hacks just this year. If V12 can succeed in crypto—if we can win on “hard mode”—then we can win anywhere.

Vulnerabilities are more valuable in crypto/blockchain than anywhere else in the world. With limited exceptions (iOS full chain?), there are no bugs outside of crypto that claim seven or eight figure bounties. Outside of crypto, $50k is still considered a huge bounty. In crypto, a critical fund loss vulnerability is worth hundreds of millions of dollars if exploited. In general, no one wants to take security seriously, but crypto companies are forced to. That means when choosing security products, they select for bug-finding ability, not dashboards—what V12 is optimized for. Meanwhile, outside crypto, security still revolves around a culture of compliance, not substance.

That status quo is unsustainable for two reasons. First, AI makes exploitation cheap, and second the world is increasingly connected. All software is vulnerable, but the world operates as if this weren’t the case. This only worked so far because attackers were rare—technical skill was the bottleneck. AI removes that constraint, which means software has to actually be secure now, or else it will get exploited. The impact is magnified by the fact the world is increasingly online, and most of the world meaningfully exists “in a computer” now. Everything will have to become much more secure very quickly, and that looks like many more teams treating security as seriously as crypto companies do.

By the way, to dispel a common misconception: crypto isn’t all just smart contracts. Crypto codebases are non-trivial in size, complexity, and diversity. Firedancer is 722k LoC of highly optimized C, Geth + Prysm is 1.1M LoC of Go, Zcash is 304k LoC of C++ and Python (Orchard alone is 44k LoC of circuits and cryptography in Rust). These all contain virtual machines, low-level systems code, and distributed databases. For context, Postgres and CPython both hover around ~1M LoC.

Time for real security

The world’s software has always been vulnerable, but now it’s impossible to ignore. Critical vulnerabilities are dropped on a daily basis. This is unsustainable when everything depends on security. The modern web depends on secure cryptography and browsers, frontier models rely on TEEs to protect weights, and innovations in robotics and biology will only make security more important.

As the world moves increasingly online, all code eventually becomes high assurance code. This is compounded by the growing complexity of software supply chains. A lot of code we don’t think about will be (or already is) high assurance. OpenSSH certainly comes to mind, but what about all of the packages we forgot about? No one is seriously looking at anything and things are going to have to change in a big way.

The way security is currently done will not work. Security is an afterthought and performed on a best-efforts basis. Teams focus on developing features and make security someone else’s responsibility. Then, the goal is to nail down as many bugs as possible, not necessarily all of them. Most security products look like band-aids that manage the symptoms of bugs, not real solutions. But in a world with powerful AI, if there is even a single bug, someone is going to find and exploit it.

Instead, security needs to be continuous and comprehensive—every merged PR needs to be vulnerability-free. The road to get there will not be easy, and we don’t have everything figured out. No one does. But the fundamental problem this boils down to—finding bugs—is what we’ve been obsessed with for the last 10 years. Before V12, we founded Zellic, one of the world’s leading security firms, with 1500+ audits for 500+ highly attacked clients (e.g. crypto exchanges, bridges, L1s, wallets, open-source operating systems). And before that, we founded Perfect Blue, the world’s #1 CTF team for 3 years.

Every person on the V12 team hails from either CTFs or vulnerability research. Look at what we’ve reported so far: multiple Linux LPEs, a QEMU escape, wormable RCEs in Redis and Postgresql (bidirectional!), MariaDB, and Anydesk. These are all 0days. And what’s even more promising is that whatever new software we throw V12 at, bugs keep pouring out: Dolphin emulator, an employee’s NAS, Signal messenger. But these bugs aren’t the point. They’re just a way to prove our approach (and our obsession) works.

Closing thoughts

A good seed round gives you the best thing in the world: the chance to build something you love with your friends.

We’ve dreamed about this problem—automatically finding all bugs—since we were teenagers. Now AI is finally powerful enough for us to take a real stab at it. We’re excited. If we’re right, what we’re building will be dangerously capable, and the world will adapt around it.

We want to be the ones who make it happen. If V12 sounds like something you’d want to be part of: join us, we’re hiring!

Part 3: The actual tutorial

As promised, here’s a tutorial on how to raise a seed round. These days, seed founders are essentially a commodity, and seed rounds are raised off credentials: HYPMS dropout, YC, previous founder, etc. usually this is good enough. You also need an idea that’s plausible and isn’t totally stupid to VCs. Combine that with some early traction and a decent demo and you should be able to raise. You should aim for 2-4 weeks to close your round; longer than that, something is off and you need to rethink something.

Is my idea fundable? First, contrary to popular belief, you actually DO need an answer to the question “how do you plan to make money?” It can be some pie-in-the-sky hand-wavy shit about 5, 10 years in the future; it can be as stupid as “lol we will launch a token”, but your idea DOES NEED TO MAKE MONEY EVENTUALLY. So if you think otherwise, get that misconception out of your head. It was invented by losers who can’t fundraise.

Second, your idea needs to be able to become a unicorn. If your company doesn’t have a clear path to becoming valued $1B+, it is generally not fundable and you should think about different financing instruments because you are in the wrong asset class. This is what people mean when they say “you are not venture scale”. Third, your idea must be LEGIBLE TO VCs. Notice “TO VCs” is part of the all caps. That’s because even if your idea is totally correct, if you can’t make it understandable for investors, THEY WILL NOT INVEST. As the founder of the company it’s your responsibility to communicate why your company will succeed to outsiders who don’t understand anything.

Getting intros. Getting warm intros to investors is annoying but honestly not that hard. If you are a first-time founder and an outsider, my advice is to just move to SF and slum it as a little networking demon until you ingratiate yourself with enough founder friends that they can help you out with some intros. A founder who can’t get some intros themselves is probably ngmi, and that mechanism is largely why this social norm exists.

Fundraising mode. You are either building the company or you are fundraising. Never both. When you are fundraising, prepare to get zero actual work done on the company. I say that because to fundraise well, you should be back to back for 6+ hours per day with investor calls: angels, VCs, friends of VCs, people who can intro you to VCs, etc. This is why I say that fundraising is a distraction. But half-assing fundraising will just mean that your round drags on forever and either never closes or closes at terrible terms.

Pitch collateral. In the big 26 having a deck is mostly optional for Seed. We raised our seed without making a deck; we just wrote a Notion one-pager paired with a video of the product. Having a deck will make things easier because most investors invest based on vibes and decks are the industry standard form factor for packaging your company’s vibes. But making a deck is also honestly a waste of time and chances are investors will chuck it into an agent anyways. You will need a deck for A.

Pitching. My advice is to go in there and focus on answering your investors’ questions before rushing to get through your spiel. Of course you will still have to walk through the opportunity and why it will be a unicorn etc whatever but try to not say too much until you have an idea what they are looking for. Instead you should tailor the pitch for each investor. Most investors, especially for Seed, have what’s effectively a rubric/checklist, like the ones teachers used to grade your essays back in high school. Your goal is to basically figure out what’s on that rubric and check all the boxes as efficiently as possible. You want to avoid saying more than necessary because it just creates opportunities for random obstacles or blockers to spawn.

Getting negged. Fundraising feels like shit because it is literally the VCs’ job to neg you and make you feel like your idea sucks and you suck. This is because successful negging arms them with a rationale for a lower valuation, and the valuation is the price tag VCs pay for a chunk of your cap table. So don’t take any of the unsolicited feedback or annoying questions personally—it’s unfortunately just part of the game. The silver lining is that each time you get negged, you’ll be prepared if you’re ever asked the same again in the future.

Party round. Your first checks are the hardest. We follow the practice of raising a party round of angels and F&F. This gives you a decent BATNA when pitching: “look we are going to build the company with or without you so do you wanna invest or not”. It also gives you practice to refine your pitch at lower stakes before you move onto your most important conversations.

Multiple term sheets. Say it with me: AT LEAST TWO TERM SHEETS. Say this out loud and repeat it to yourself every day. AT LEAST TWO TERM SHEETS. If you do not have AT LEAST TWO TERM SHEETS you will get cucked. This is like having only one job offer. You will not be able to negotiate it and your round will clear below market value, whether that means a shitty valuation or giving up board seats or warrants or annoying side letters or whatever. So you need to have AT LEAST TWO TERM SHEETS in hand simultaneously to support a bidding process and walk them both up until you clear at fair terms. This sounds mean, but sadly it’s your responsibility as the founder to run a proper process even if that means shopping around a little. Once you have your first term sheet, the clock starts ticking and you need to get as many other term sheets as possible, as quickly as possible.

Postmoney YC SAFE. Everyone has a different style, but for Seed we like to insist on raising on postmoney YC SAFE only and no other weird terms except a minimal side letter. That means no board seats, no warrants, no weird shit. YC SAFE with valuation cap (post money) is the industry standard and it’s reasonable to insist on it. Raising on YC SAFE saves everyone time and precludes weird shit that can cuck you later. A lot of first time founders don’t realize this, but you can just ask to delete terms out of your side letter. You can just say “no I am not going to sign this. Please take it out” and get a lot of annoying terms to disappear. This only works if you have TWO TERM SHEETS though.

Furthermore, in our experience the best VCs are the ones most comfortable with just investing on a YC SAFE. This is because they have enough trust in their investing experience/process, and enough mutual trust with their founders, that they don’t need to mess around with weird terms to try to prevent founders from rugging them. In our opinion, Seed boils down to investing in people, and if a founder is going to rug it’s ngmi anyways.

Vibes. Taking any meaningful amount of money from an investor is like getting in bed with them. Actually it’s more like getting married. DO NOT ACCEPT SEED FUNDING FROM INVESTORS YOU GET A BAD VIBE FROM. IT WILL RUIN YOUR COMPANY. The best investors will help you when you need help, and otherwise leave you the fuck alone. Good investors trust you and are basically chill. While we are lucky to work with excellent investors, we’ve also seen many companies get torpedoed by shortsighted, shitty, immoral, or just annoying investors.

Reference checks. Your investors will ask for references from you. Similarly, you should ask your investors for 2-3 founder references. Do this for all your investors you get to the term sheet stage with. These references are great for making friends with other founders even if you do not end up taking the term sheet. You also might be able to convert them as customers. In terms of actually checking the references, obviously all the references you get are going to be positive reviews. So all the signal you get is from how cracked the reference founders are.

Dilution. Don’t think in terms of valuation, that’s for investors. Valuation is the price tag. Instead you should think in terms of “dilution and $ raised” because these are the two things that actually affect your company’s trajectory. For example, between “6 at 45” and “7 at 50” which one is better? It’s less obvious than $6M for 13% dilution vs $7M for 14%. In general aim for 10-20% dilution at seed and avoid exceeding 25% dilution.

Closing. Say it with me: DEAL ISN’T CLOSED UNTIL THE WIRE CLEARS. Closing is usually a miserable slog, but the upside is that while it’s a grind, it’s straightforward. Expect to spend 1-2 weeks in “due diligence”. Imo it’s lowkey made up for Seed, but we have to do the song and dance for the LPs. Retain well-known corporate counsel and loop your counsel in with the counterparty counsel in a big Reply All party. Watch that thread like a hawk to make sure shit isn’t going off the rails. It’s common for either side’s counsel to waste everyone’s time raising concerns that are not realistically going to materialize. When this happens, sort it out “at the business level” by calling your counterparty and telling them why the objection is not real and to tell off their lawyers so we can get the deal done and move on with our lives.

The hard part. Nothing feels better than seeing the wire in your Mercury account. Unfortunately, everything up till now was the easy part. The hard part is actually building the company. Good luck.