Gonçalo Magalhães, Immunefi | Why Privacy Without Security is Theater | Common S3nse 2026

Hello, hello. Um, okay. By bringing this topic of security to your attention , I hope , I hope you don't think I'm just a bore. But, you know, attention to this issue is, as you understand, extremely important extremely important . So, let's begin.

On May 29th of this year, Taylor Hornby, a security researcher, disclosed a critical vulnerability to the Zcash Dev Lab while working with Opus 4.8—a Lab while working with Opus 4.8—a small detail they decided to add to the disclosure. This vulnerability allowed an attacker to create fake ZEC inside a shielded pool without any on-chain without any on-chain signature. And then, on June 2nd, as you may have heard, a coordinated fix for the entire ecosystem was completed.

The error has existed since Orchard was activated in May 2022. So, 4 years before she was found. So we wo n't delve into that vulnerability, because, frankly, I'm not the best person for it. But let's look at the context around this whole revelation. So, revelation.

So, first, as the Shielded Labs team pointed out, this bug has a particularly nasty detail: due to its nature, and I quote, “there is no way to cryptographically prove whether the vulnerability was exploited before it was fixed.” So thank you to the Shielded Labs team for their transparency Labs team for their transparency . Later they will do something that will probably prove in some way whether there was a break-in or not. The community break-in or not. The community , understandably, had mixed feelings about all of this.

Woody says that Zcash creates a unique class of bugs that, if used, no one would know about. This unique class still exists. The fact still exists. The fact that they fixed this specific bug is irrelevant. Mithos could find eight others, and then Mythos 2.

Grayscale's Craig Salm, on the other hand Grayscale's Craig Salm, on the other hand , believes it is unlikely that, and I quote, "this vulnerability was exploited before the patch." You would have to believe that someone studied the Zcash codebase more thoroughly than all the developers and security participants from ECC, Zcash Shielded Labs, Zcash Foundation, and others combined, and resisted the temptation to completely deplete the Orchard pool to sell all the fake ZEC. And on the other hand, you have Arthur Hayes, who is dumping ZEC and arguing that the privacy narrative from AI, government, and big tech requires perfection requires perfection , not improbability. Okay, let's walk through some of these claims, let's say from the perspective of the security community. I don't necessarily speak for the security community.

And with that in mind, allow me to introduce myself. I am Gonzalo. I lead security, bug bounty processing, and AI work at Immunefi. Immunefi is a security platform for the on-chain security platform for the on-chain economy. 93% of all disclosed critical vulnerabilities in cryptocurrencies pass through Immunefi.

We have helped prevent over $25 billion in breaches across more than 650 protocols. So, because my job requires it, I saw most of the critical vulnerabilities found in active protocols. Which were found in active blockchains. And to give you an idea of ​​the absolute numbers, because 93% absolute numbers, because 93% may not be telling the whole story. Just a week ago, we reported that security researchers had discovered 44 confirmed critical vulnerabilities through Immunefi in the past 30 days.

And to be clear, this is not some random protocol with $100 TVL. Such protocols usually do not have bug bounties. These are critical bugs in some of your favorite protocols and blockchains. This isn't necessarily a bad thing, you understand. But let's get back to the Zcash disclosure and discuss the aforementioned claims.

So, Craig Wright said it was unlikely to be used. I won't discuss whether it happened or not. I think, as I told you, Zcash has done an Ironwood update. So, over time, it turns out that the exploit didn't actually happen. But regardless , the claim that no one was likely paying more attention is definitely not true for two reasons true for two reasons .

First, a security researcher found the bug by examining the code bug by examining the code . So the question is whether anyone wanted to, or whether anyone paid enough attention, perhaps from a different perspective, let's say . And the incentive to find such a mistake is, of course, huge. Secondly, this statement almost implies that Zcash developers are the most prepared to find bugs in their own code. But is that true?

The tweet mentions security experts here, but what incentives are there for the security community to even care or pay enough attention? Nothing against the developers, but if they are the best at finding bugs, why did n't they find this one? Or why don't they find those 44 critical vulnerabilities critical vulnerabilities that were disclosed through Immunefi? Udi seemed completely stunned by the thought that there was a critical error in the protocol. And while it's true that other bugs may exist , it's obviously good that one bug was reported responsibly and potential breaches didn't occur.

And it's also evidence that, you know, it was a complicated mistake, if you can put it that way. And since it touches on the topic of AI, and the disclosure also mentioned the use of Opus 4.8, I want to debunk a little the myth of AI as a magical tool for finding vulnerabilities. So, at least that 's my opinion. You know, there are many agents who find bugs in Immunefi.

I would say it's not Mythos that finds fault. It is the phenomenally skilled bug hunter who uses these models who finds them on a large scale. And this nuance is very important because, you know, the Zcash developers also had access to Opus 4.8. And finally, Arthur Hayes said, " Arthur Hayes said, " Privacy from government and big tech companies requires perfection, not improbability."

So, maybe he made a mistake by selling ZEC. At least, that's what current price movements suggest. But he was right about that, and it can be translated as privacy requires security. So requires security. So , for something to be confidential, it must remain confidential.

This, this is a big challenge. This means that to some extent, a protocol or cryptographic primitive must be robust enough or evolve robust enough to withstand the future. So, privacy is common sense, and it is not guaranteed without security. So, in a sense, security is common sense. So, let's move away from privacy protocols and the Zcash example and move on to the more general world of ZK.

In February of this year, ZK Security, I love these guys, wrote an article called " an article called " The first ZK exploits happened, and they were n't what we expected." In this article, they explained that two ZK-based protocols were exploited ZK-based protocols were exploited . One of them, well, I guess, was exploited in a good way, let's say. Exploited by " Exploited by " white hats", and another just lost 5 ETH. It's just, I mean, it's a relatively small amount of money.

And the root causes were related to Groth16 verifiers with incorrect settings. And this was not what they expected, rather they expected ZK- they expected ZK- hacks to arise from under- constrained schemes, which are actually usually the bugs reported on Immunefi. Anyway, I found one particular point they raised particularly interesting. They wrote: actually, I do n't have the full quote here. I'll read part one, and then here's this part, but they said, "We've always had the impression that the code associated with ZK is complex, and that's why we haven't seen any exploits from attackers."

"And then they continued with what is said here." We just want to believe that people working in the ZKP space are very focused on security, and researchers in this field prefer "white hats." Also hats." Also , perhaps the known group simply hasn't started studying ZKP yet. " started studying ZKP yet.

" Meaning, of course, the Lazarus Group." Now the interesting thing is that, um, there haven't been many ZK hacks, or at least large-scale ones at least large-scale ones . At least let's go back in time to September 2023. One of our elite white hats reported a critical vulnerability via Immunify that would allow an attacker to effectively withdraw funds from the entire Aztec Connect protocol. I loved Aztec Connect, I loved ZK money.

If I'm not mistaken, the project, I think, was here when it was announced. By the way, it says "October" at the top, but that's when it was, um, publicly disclosed, but, uh, a security researcher reported it in September. Um, and when it was revealed when it was revealed , I think the protocol was already, um, in the final stages, I think. So, there was only $5 million at stake, only $5 million in funds. And so the "white hat" was paid a reward of half a million dollars.

I think the error had something to do with, uh, and again, another restriction scheme. Something related to a witness. To be honest, I don't remember. But, going back to Craig Salmon: how likely is it that the bug isn't found by anyone who is, you know, an expert in this protocol, an expert in the code, in cryptography, and then a security researcher comes along and finds an active vulnerability. Are Zcash developers and researchers or Aztec developers and researchers simply incompetent?

Well, of course not. At least that's...I'm not 100% sure, but I would say no. So, this is why this happens. I've talked about this in the past.

I'll give a brief summary here. The mindset of a hacker, the mindset of a hacker—I'm specifically talking about people who usually hunt for live protocols—is a mysterious thing. I will say it. As you can see from some of these examples, which just illustrate the situation a little. Penning is an the situation a little.

Penning is an elite researcher who made $8 million from Immunefi. When asked about the methods, he replied a few years ago, perhaps he is already using AI now. I don't know. But he didn't use any tools or frameworks. And in other messages, he said it looked like a random side job.

He could sit over a bug for days , working on it without rushing. Infosec ranks 16th on the Immunefi leaderboard. He never wrote smart contracts in Solidity, but he found dozens of critical bugs in them. Another " bugs in them. Another " white hat" who earned over a million dollars on Immunefi.

He has some of the craziest ways to break protocol. His bug reports are always a nightmare to review. And, in fact, most of our eligibility rules came about precisely because of his reports. We had to invent rules because of him. When asked about the " trolley problem," this was his answer.

I would let the trolley run the first pair of wheels on the track to the two people, then move the lever to leave the second pair of wheels on the main track, derailing, etc. derailing, etc. However, this is not proof of security skills. This is also a scam because it is not a valid solution, but still, certain details are visible in these examples . This kind of unconventional thinking or a very atypical approach to things is part of the special features of the hacker brain.

So, in short, I don't know how much time I have left. Who are hackers? They... hackers? They...

Thank you. They think independently. They have no bias towards certain decisions or certain ways of looking at code. So you can immediately see a huge difference with protocol developers. They can see things from a completely new angle, which is why they notice things that developers don't .

They have what I call fearless creativity. They constantly ask: " constantly ask: " What, how?" As long as the developer—I have nothing against them, to be clear—but as long as the developer is focused, as the job requires, on making sure the application works as intended, the hacker doesn't care how it should work. They mostly focus on “what if?” scenarios.

And this is actually critically important for bug detection. And this is actually extremely important for finding errors in underconstrained schemes, because usually the problem is what's not there. What's there works correctly, but something is missing. Or perhaps the parameters— perhaps the parameters— if they are not set as expected. They pay attention to details.

They deeply understand the essence of processes and are able to break down complexity into much smaller, simpler parts. If we go back to the protocols we've seen, like Aztec or Zcash, they're complex. But I wouldn't say these are simple protocols. And therefore, their verification seems quite burdensome. However, if you look at the specific errors—I didn't show them, but they often come down to one line, and when they explain to you what's wrong, it seems pretty simple.

So the challenge is always to find those simple things , without letting this perceived complexity crush you. And they do it very well . And finally, they have what I call stubborn persistence. We often have to argue with security researchers and projects, mediate, and security researchers are very stubborn, but most of the time they are right. And, in fact, they leave no stone unturned.

If they sense —they develop this instinct—that something is strange or weak, they explore a multitude of avenues for exploitation until they find a successful solution. And that's another difference from developers, for example, because they don't seem to be time-bound, these hackers hunting in existing protocols. You'll see that some of these elite specialists find incredible errors, but then they can delve into one particular protocol for months. So, to summarize: if you care about privacy, or a protocol cares about privacy, about its users, their money, they should care about security. And the last line of defense is to engage the security community.

And they need this, because we have already established earlier: security is common sense. Thank you very much. Thank you very much. It was very, very informative. Uh-huh.