CTRL/SHIFT - 14 06 2026 PARTHENOPE STAGE - CESARE VALITUTTO

Thank you. Hello everyone. Yes, so today I want to explore why moving assets across chains is one of the weakest point of the Web 3 ecosystems. I'm going to analyze vulnerabilities that the actual vulnerabilities of the space of bridges and I'm going to try to define a path, a secure path to build secure interoperable protocols. Starting from a baseline, bridges were used since the ancient civilizations to connect people.

Uh particularly Roman Empire used uh bridges to not just move people and expand their um powers across multiple realms, but there is another important feature of bridges, moving assets. Moving assets across different geographical paths. An example, Web 3 moving assets across different chains, Layer 1s, Layer 2s, not specific networks. And a big example of this is the Pont du Gard, um which is a Roman bridge that is still um standing um finally preserved in the south of France, which has the important task not just to allow people to move from one side to another, but also to deliver water, so to carry water for 50 km from the source to the city. Was indeed an aqueduct, right?

An aqueduct bridge. This bridge is still standing, so also tell us a lot how Romans back in the time used to engineer and build bridges to, you know, sustain and keep it until today. Um but it's also open an important point, The moving assets and flowing economy still stands one important point that we're trying to achieve as a humankind. Particularly here when we say moving water, which is part of our living, from the source to the city and being part of the city waking up day having fresh water in your dwell is definitely something that we give it for given. And we would like to have the same in the web three, right?

Moving assets across chains without, you know, needed to think where our assets reside. And I want to open to the audience a question. If you had to cross one of these two bridges, where will you put your life on or your capital on threat on? The first one, option A, is a looks like a robust, sturdy, very solid bridge with concrete pillars. And the right side is more light weight, probably like more a design bridge that looks like more a castle of cards, right?

So, I'm sure that most of you in this room will choose option A. For the reason or several reasons, right? Like what I explained, what you can see as well. And the point that I'm making here is that we don't really see what is in the foundation of this concrete bridge. The pillar are strong until we see the foundation of where they are erected.

But I sold you this well, right? I I told you that it's a strong bridge. I compared option B that is more flimsy, light weight. And if you're curious, by the way, option B option B is based on Leonardo da Vinci self-supporting architectural design with a formula to understand exactly what is the hold that the bridge can support. Well, I'm saying this because well, we use exactly the same choices that we make when we are in the web tree ecosystem to choose a bridge because it's faster, because it's a good UI, and any other reason that I give before.

One of these being as well how that bridge is marketizing, right? Well, we should stop doing that. But let me get to the core of this presentation and telling you why what is a bridge, but also why we need a bridge at all. Well, for two main reasons. The first one is that with existence and proliferation of layer ones, layer twos, and app-specific chains, liquidity is fragmented across multiple chains, multiple layers.

So, we need a way to move them, to allow liquidity to move across these two paths or multiple paths, and by asset. But another important point that we tend to forget for the intrinsic nature of blockchains, they are isolated reality. They don't know anything else than their own world state and and the external world. So, the only things that they know about and how they can operate. Therefore, if you want to put in communication chain A with chain B, we need an external agent.

We need a middleman in the case that it will knows how chain A speaks to translate the language in something that chain B can understand to then put these things in communication. This is the bridge. In put it in simple words. Huh.

But, another important point is that I put in very simple words what a bridge is. But, the reality is that a way more complex architecture and solution than what we think. It consists of many components, some on chain, smart contract, and some off chains like the one they're representing here. They have the task, for example, of not just relaying a message, which is the basic part of a bridge, an important part, obviously, but also, and more importantly, to answer this question and resolve this big challenge defined as a the bridge problem. The bridge needs to convince the destination chain that something really happened and final on the source chain.

Again, because destination chain will not know at all how to understand whether whatever we are sending is valid or not. So, it needs to trust absolutely the bridge. And how do we design a solid solution? What are the parameters that we require to build a solid interoperability solution? Three main parameters, uh they're a part of the interoperability what is called interoperability trilemma.

One of these, the most important of the three, I would say, for the sake of this conversation, is trustlessness. Uh which can can be translated into security, right? How secure is the full solution of the bridge, right? The full perimeter of the bridge, not just the um smart contract assisting on chain A and chain B. And we need to maintain the security at least at least as secure as the um security that we have on both chains.

Then we have extensibility that defines the how the um solution can scale integrating new networks. And finally, generalizability that is defined the capability of that protocol to be general in handling data, right? Not just token transfer, but we're talking about passing data from um one side to another arbitrary data pass um messages. But let me give you an order of magnitude of the problem that we're talking about. Give you some number here.

Just think that 2.8 billions of the total amount of stolen funds to date in the web three ecosystem can be accounted to cross-chain bridges implementations. 2.8 billions. Which it goes up to a staggering amount of 45%.

I mean, we're getting some at 45%, which is half of the amount all the stolen funds funds and hacked on the web three ecosystem. This is huge. And what are the attack vectors? The exploits that attackers can leverage to steal funds. Well, the first one you're probably more familiar with um smart contract logic.

Um so, bugs, flows in the code. And more to say that these problems are coming less and less frequent because of the maturity of the environment, the ability of the community to build libraries and frameworks to create safety in the code of the programmers. And thanks as well to auditing firms that are auditing the code of the smart contract to then provide reports where there are critical bugs needs to be fixed before deploying that contract to production. But I want to focus this conversation mostly on the other two attack vectors. The second one being very interesting which invalidate completely the problem that I put before which is the bridge problem, right?

If you can actually lie to a bridge everything every kind of security that you put in any side of the the chain A and chain B full of heart. So that foundation that we were talking about can easily make your pillars to tremble. And the last one is probably the most invasive kind of attack which is in in consist in the attacker to hack directly the machine where the components of the bridge are to then manipulate and ingest like malicious code. So what I'm going with this? Well we definitely need to extend our perimeter of security not just focusing on the smart contract layer but going beyond.

Especially when we're looking at off-chain component, we need to make sure that there is a one layer end-to-end of security that covers the full solution. That means we need to absolutely expand the operational perimeter of our security and defense, as well following the threat perimeters that is extending as well. A terrible example of what we're talking about is the Wormhole hack, 18th of April, not long ago. Here we could simply say, well, the foundation of the protocols of that interoperability configuration was weak. Right?

Having a 101 DVN verifier on the layer zero um side bridge uh interoperability protocol that Wormhole was using to um perform cross-chain transfers is definitely something unacceptable for user. Nobody should ever accept to have a configuration with this level of weakness when the funds secure of this protocols are billions in funds of users. The hack The hackers walk walk away with a staggering amount of 300 millions, almost 300 millions uh dollars, equivalent to 300 millions of dollars. But, the most alarming part is that Wormhole is not an isolated case. Based on the data on DeFi Llama, 22 billions, 22 billions Oh.

Something happened here. Thank you. 22 billions of funds um are still uh of protocols are still put on the same risk, so they still contain the same configuration as for Wormhole, 22 billions. Obviously, protocols are trying after this hack to, you know, repair and changing a configuration. Many of them flee from layer zero to channeling CCIP.

But the reality is another, right? Why we can simplify and point the fingers to oh, bad configuration can be done simply by changing line of code having him like two or three or quorum. The reality is different. This operation was a complex sophisticated operation of hacking studied probably for months. But operated just in a mere amount of 46 minutes.

So short time to allow Cap Dao to freeze operation that only come after a few hours. How that hacker managed to stole this funds? Well, they manipulated, they hacked the infrastructure of two internal nodes of layer zero, the two or three that were part of this quorum. And they managed to ingest a malicious code that created false proof. So they basically covered the two main vectors of attack that we described before in the slide before.

And this is something extremely powerful and definitely we can talk about our defense. How we can try to avoid prevent this kind of hacks to happen. Well, we need to in create a layer of engineering definitely our perimeter of defense creating layers of defense. Not just my contract, not just redundancy, creating decentralization on the network, increasing quorum, improving the number of signature that are necessary to perform a cross chain um a cross chain transfer, especially of this amount of monitoring them. But the real core point here where you can move to clearly a better and solid solution is how we fix uh possibility that hackers through the much stronger social engineering um attempts that our environment is continuously um targeted to.

The solution, in my opinion, is to secure the level of computation that happens on the nodes themselves. That's what we're doing at Chainlink. November 2025, we announced confidential compute. Trusted execution environment. Meaning an hardware isolated piece of software, sorry, piece of hardware that [clears throat] runs on top of a CPU and is completely isolated from the machine itself.

Meaning no one, not even the host of that machine, can access this black box. What uh does it mean in a real case scenarios, especially comparing to the cap down attack? Well, if uh layer zero had a machine that was running on um having a chip of trusted execution environment and enclave, the low business logic executed by the verifier, it will not be spoofing because it will not be um hacked because you cannot ingest malicious code in a trusted execution environment and enclave. Besides that, um the enclave produce an attested execution proof and this attested execution proof can be validated by any chain. That's to say, we can definitely improve the way in which security is implemented now solutions and we must do that and is our duty as a architect and a software engineers in the web ecosystem to secure funds of people to allow people to get on board there on this ecosystem in crypto is to first guarantee safety and security to our users.

What I dream and what we should work towards is a bridgeless future where user will not need to put themself in the situation as I put you on slide two, choose A or B. Now they should be able to transact to perform any operation in a seamless way. This is user experience but mostly this is what's going to boost our ecosystem to the next level. Thank you so much for listening.