How to raise a $10M seed round

Earlier this month, we won a $2.5M bug bounty—the largest bounty ever received by an AI agent. This was a bug in a major blockchain, and it put >$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, among countless 0days (including Linux LPEs, QEMU escape, Firefox UXSS, 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 ZachXBT, samczsun, Walden Yan, and more.

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

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 particularly interesting because such a capability would allow you to exploit software that’s previously considered secure. 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.

meme credit: LiveOverflow

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 in an arbitrarily large and complex codebase, reasons about how it actually works, and then uses that understanding 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 closest 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 will 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 at new, state-of-the-art models and claim that cyber is solved. It’s another thing for developers to meaningfully leverage models to secure their code. The average developer is still asking Claude or Codex to “review my PR for bugs” followed by “OK fix these”. 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 to unlock 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—or something—to come in and fix it for them. It should embed directly into their organization (i.e. in their Slack), understand their workflow (do you use Github? how do bugs get assigned? what do you use for issue tracking? what agents do you use?), and feel tailored to their context.

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, and finds novel bugs. Then package that capability into a useful product, and 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 bugs are found and patched. Gatekeeping access just slows down this process. For maintainers, adapting to a new threat landscape is uncomfortable but unavoidable, and we think the best approach is to just find all the bugs now. In practice, that means arming defenders with offensive capabilities so they can harden their own code.

To be clear, we want software to be safe and trusted. It’s irresponsible to unleash offensive capabilities that 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 concerns as a pretext for not actually giving anyone access—and in the process, not protecting people at scale. This year alone, V12 has protected users with over 6,000 security reviews. 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 monitor public commits and trivially recreate a weaponized exploit. 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. Particularly, that means defenders need extraordinary PoC and fix generation capabilities.

Bug bounties are dead

Bug bounties in their current form will be dead, beside vulnerability acquisition programs for exceptionally valuable bugs. All other bugs will be mined out by offensive cyber tools like V12 before the code is shipped i.e. before attackers get a chance to start looking.

Maintainers are buckling 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, both were untenable because while virtually all code is flawed, reasoning through all the possible bugs was time and cost prohibitive. 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. We are obsessed with finding all the bugs, and crypto is currently the place where this matters most. More than $500M has 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.

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 over dashboards—what V12 is optimized for. Meanwhile, outside crypto, security still revolves around a culture of compliance, not substance.

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. Now, if software isn’t secure, 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 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. 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. Basically, all code eventually becomes high assurance code.

Don’t forget about 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? The internet depends on software that nobody is looking at.

The way security is currently done will not work. It is an afterthought and performed on a best-efforts basis. Teams focus on developing features and make security someone else’s responsibility. 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+ security reviews 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. 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.

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

In 2026 seed founders are a commodity, and seed rounds are raised off credentials. HYPMS dropout, YC, previous founder, etc. This is 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.

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 generally isn’t 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 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 Series 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 TERMS 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.