Last week, the Phylax team packed our bags and headed to the snowcapped mountains of Colorado for ETHDenver. Between the buidlathons, endless side-events, panels, and an axe throwing session, we spent our time chatting with developers about what we're building. Our conversations ranged from technical deep dives to philosophical debates about the future of security in Web3.

Watch Odysseas's talk here and Jacob's here.

What We Heard

While everyone else seemed caught up in the AI frenzy (how many "AI + blockchain" pitches can one conference handle?), we noticed something interesting in our conversations with actual builders. When we explained our approach to security, eyes lit up.

"You mean I can just write assertions in Solidity? Like I can just copy my Forge tests?" A few devs actually smiled and got excited. 

That was a common theme. The moment we mentioned that developers could write security rules in the same language they write their contracts, using patterns similar to their existing test suites, we could see the mental lightbulbs going on.

Interoperability Changes Everything

One insight that kept coming up in our discussions: as chains become more interoperable and liquidity flows more freely between networks, security becomes an even stronger differentiator for L2s.

When we talked to L2 teams, they immediately understood the implications. If users can move assets seamlessly between chains, they'll choose the ones with the strongest security guarantees. Nobody wants to be the chain known for "that one massive hack."

The Deterministic Difference

The most meaningful conversations happened when we explained our deterministic approach to security. In a world obsessed with probabilistic AI, we're taking a different path.

"So you're saying it either matches the rule or it doesn't? No AI guessing games?" asked a protocol lead.

Exactly. When millions are at stake, there's no room for "probably secure." Not to mention our conversations with some of the legal minds in the space. Let’s just say they are NOT sold on letting AI models decide transaction inclusion. 

This point resonated deeply, especially in light of the Bybit hack that happened just before the conference. On that note, here’s how we could have prevented it for all of those who have been asking.

‍

As most know, Bybit suffered from a security breach in Safe's hosting infrastructure, losing $1.4B.

The attackers, the Lazarus group, gained access to the server and were able to modify the served Safe Wallet frontend. More on the attack can be found here.

The malicious code specifically targeted Bybit's next transaction. As of today, it is commonly agreed that the signers of the transaction were shown a fake UI, which seemed to be the intended transaction to sign, but in fact, it was a malicious transaction.

Unfortunately, it is often very hard to verify the correctness of the message that is signed in software or hardware wallets.

Attack steps:

• Attackers gained access to the hosting server by compromising a developer's machine.
• A malicious frontend was uploaded to the server, which targeted Bybit's next transaction.
• The frontend would show the intended transaction, but in fact, the message to be signed was malicious.
• The malicious message was a delegate call which would change the implementation of the Safe's proxycontract.

How assertions could have prevented this:

In Safe's proxy implementation, the first storage slot is the implementation address.

The malicious transaction was executing a delegate call to a malicious contract, effectively changing the implementation address of Bybit's proxy contract. A change of the implementation address allows an attacker to almost completely exchange the logic of the contract. Therefore, it was possible to be able to drain all the assets of the Safe without the need of any additional approvals by the original owners.

It should be highlighted that even if there is no logic to change the implementation address in the implementation by Safe, delegate calls can modify storage slots of the calling contract. This allows for full flexibility but opens up the possibility for attacks.

Preventing attacks through assertions

It might be fair to assume that most users of Safes would never actually want to change the implementation address of their Safe, but they have no way to express their preferences.

Assertions give users the ability to express additional invariants on the state of the contract. A change of the implementation address could be prevented by analyzing the state changes within a transaction.

PhEvm precompiles used:

• forkPreState allowing to fork the state of the contract before a transaction
• load reading specific storage slots
• getStateChangesAddress getting all state changes within a transaction for a given slot

To even enhance security properties, a complementary assertion could enforce transfers to a whitelist of addresses. In the below example, the assertion checks if the balance of the safe decreased while the balance of the whitelisted addresses increased with the respective amount.

To put it simply, deterministic security enforced at the sequencer level is powerful enough to stop most hacks if the proper invariants are written.

And this isn’t just us shilling our product. 

Technical teams immediately understood the significance of building at the sequencer level. And this isn't just about detecting problems – it's about preventing them entirely. No more teams getting a notification that they have been hacked for $5mm, but that thankfully an additional $20mm wasn’t taken. 

"Wait, so you're saying transactions that would cause exploits never even execute?" A security researcher we met was particularly excited about this angle. "That's completely different from what everyone else is doing."

The non-invasive nature of our solution also struck a chord. No code changes, no redeployment, no downtime – just write assertions and deploy them. For teams that have gone through the pain of emergency patches and protocol pauses, this was music to their ears.

What's Next

We came back from Denver energized by the response and more convinced than ever that we're building something Ethereum desperately needs. We're excited to announce that we'll be launching our own testing environment soon, where developers can experiment with assertions and see how they prevent various attack vectors.

Even more exciting, we've secured a testnet integration with a major OP Stack L2 (more details coming soon). This will bring deterministic security to a production-grade environment and showcase how security can become a key differentiator for networks.

The road to better Web3 security isn't paved with buzzwords or black-box AI – it's built on deterministic rules, developer-friendly tools, and prevention rather than detection. We can't wait to show you more in the coming weeks.