Cover photo

Setting the stage for making Safe Modules safer

In the vibrant world of Web3, we're dreaming big – envisioning a future where everything, from our finances to our real-world assets, seamlessly resides on the blockchain. But here's the catch: while we're busy moving mountains, we've overlooked a crucial piece of the puzzle – security.

Sure, security audits are a non-negotiable part of the crypto world. They're what keep our users, communities, and investors feeling safe and sound. Countless tools, infrastructure, and auditing firms work tirelessly to beef up protocol security. But here's the snag: we're missing a standardized way to put all this vital audit info on-chain.

That's where the proposed onchain audit representation standard ERC-7512 steps in – it's the brainchild of some heavy hitters in the industry: Safe, OtterSec, ChainSecurity, Ackee, OpenZeppelin, Hats Finance, and Omniscia. Their mission? To ensure audit reports have a home on-chain and are easy to verify across different platforms and protocols.

ERC-7512 isn't just a game-changer; it's a community effort to bring trustless security to the forefront of Web3. By setting clear guidelines for representing audit reports on-chain, this proposal aims to streamline the verification process of audits, and auditors, thus fostering transparency within our ecosystem.

Onchain audits for Safe modules?

Here at ZenGuard, we're pretty pumped about this! Security is our bread and butter, after all. In our Safe Module marketplace (Currently in the Alpha version), we've got your back. Before you hit that enable module button on your Safe account, we will make sure every module's audit is verified on-chain and meets your security requirements. It's all about keeping things safe and sound for you because your security is our top priority!

At ZenGuard, we've designed a solid on-chain report collection system that sticks to this standard. Whenever a verified auditor conducts an audit and gives an on-chain attestation through our user-friendly dashboard, we will make sure to gather all the relevant details and make it accessible to be verified across platforms.

ℹ️ BACKGROUND: Safe Modules and ZenGuard: Safe Modules enable Safe Accounts to add additional custom features in the form of standardized Smart Contracts. These smart contract logic can be anything from Social Recovery, Passkey Auth, Session Key to DeFi Automation, and much more. We have created a non-exhaustive list here.

At ZenGuard, we have designed a marketplace for publishing, exploring, and enabling these modules. Understanding that the security of these modules is of utmost importance, we will be onboarding module auditors through our module dashboard.

The Safe Module ecosystem is buzzing with growth, thanks to all the exciting innovations in modular smart accounts. Developers are constantly adding new modules to the mix. But, ensuring the safety of these modules through security attestations is crucial for our Safe users. It's not just about promising wonders; it's about building a trustworthy ecosystem together.

Audit attestation and verification via EAS

In our initial implementation, we've made this process simple by using the Simplistic Attestation Service - Ethereum Attestation Service (EAS), which is open-source and comes with secure contracts and handy SDKs. ZenGuard will store these audit attestations securely on EAS with a predefined schema that matches the ERC-7512 audit properties.

Once the audit details are attested, they become accessible to any Safe account user through our marketplace Safe App (https://explore.zenguard.xyz). But here's where it gets exciting.

Our ZenGuard Module Marketplace will also rely on the proposed Safe {Core} Protocol registry to verify modules before they're enabled on a user’s Safe account. In our setup, the ZenGuard registry will check audit information against the ERC-7512 standard. Only when the security requirements are met can a module be activated on the Safe account; otherwise, the transaction gets rejected.

This showcases the power of on-chain audit verification, ensuring that Smart Accounts stay clear of extending them in accidental or intentionally malicious ways.

Audit attestation via ZenGuard Dashboard (Alpha version). The attestations are just mocks for demonstration and do not guarantee actual audits.
Audit attestation via ZenGuard Dashboard (Alpha version). The attestations are just mocks for demonstration and do not guarantee actual audits.

The initial responses and feedback

During our initial demos and onboarding on our alpha version to seek early reviews, we had some great chats with auditors and security advocates, including Shay Zluf from Hats Finance and Michael Lewellen from OpenZeppelin, who happen to be authors of ERC-7512. Their feedback has been highly encouraging and useful during the design of this initial implementation of this ERC in the Safe module ecosystem.

As we prepare to onboard the final versions of our modules onto our marketplace, we are actively engaging auditors who can conduct module audits and provide on-chain attestations. The responses we've gotten about the onboarding process have been really promising. We're hashing out the details as we chat with more auditors and brainstorm integration strategies.

Things to improve

So, this is just our first crack at on-chain audit representations. We're still ironing out all the kinks, especially when it comes to syncing up with the signature standard for verification and interoperability. Right now, we're relying on the EAS attestor information to verify attestors but we need to update our signature verification to standardize and guarantee interoperability as proposed by the standard.

But hey, since we're still getting the hang of it, there are a few things we need to sort out to make sure our on-chain audits are rock solid.

  1. Developing a standardized way to maintain and fetch the on-chain addresses associated with a verified auditor. It is also important to ensure there are good practices of key management and a way to revoke and add secondary addresses in case of auditor key compromises.

  2. Mapping the correct version of the module code base to the deployed module and providing the on-chain attestation will still require manual verification from the auditor's part.

  3. A better strategy is needed to provide updated audit attestations for newer versions of the module.

The end game

We see this as the start of something major, aiming to set the bar for security verification not just in Safe, but across the whole Web3 space. Our initial rollout and efforts are just the tip of the iceberg, meant to spark ongoing discussions and momentum until this becomes the norm.

Sure, there'll be plenty of stuff to rethink and tweak along the way, but hey, we've taken that first leap to get the ball rolling. We're totally open to feedback, collaborations, and yeah, even criticism. Feel free to shoot us a message or jump on a call for a demo and some good ol' discussion. Let's make this happen together!

⚠️ NOTE and DISCLAIMER Our current platform is in the alpha stage, and while the published modules have undergone thorough testing, they have not yet undergone full audits. The attestations added are just mocks and do not guarantee actual audits.