What started as a simple hackathon idea around EOA recovery quickly transformed into a deeper pursuit: building the next generation of onchain account infrastructure - modular, secure, and ready for real-world users.

The ZenGuard Journey

ZenGuard was born at a Safe hackathon, where we set out to build seamless recovery tools for Safe accounts. That early work gave us a strong foothold in the Safe ecosystem and led us deeper into Safe modules - how they could be built, distributed, and adopted more easily.

We realized a critical missing piece: a public marketplace for Safe modules, with standardized onchain audit attestations. We explored this idea in depth here.

With support from a Safe grant, we built tools, dashboards, and dev workflows to improve module creation, verification, and adoption.

Embracing Account Abstraction

As ERC-4337 and account abstraction gained traction, it became clear that Safe accounts needed new adapters and infra. Teams like Rhinestone led the charge in standardizing account interfaces and making Safe compatible with the 4337 spec.

We took that momentum and pivoted toward the missing infrastructure focusing on recovery, session keys, and delegated account access. Our goal became clear: make Safe accounts more secure, flexible, and ready for real-world use.

The Inception of Brewit

At Devcon, during a presentation at the Ethereum Foundation’s Account Abstraction Hub with Vitalik in the room - we introduced our concept of session keys + delegated automation.

That moment sparked the beginning of Brewit.

We realized: the primitives already exist - Safe accounts, session keys, bundlers, modules. But there was no cohesive framework tying them together into a secure, usable system. Brewit is our answer to that.

Brewit Today

Last month, we launched the first version of the Brewit App a consumer-friendly crypto app built around the concept of delegated accounts.

The response has been amazing, especially from newcomers to crypto who want simplicity without compromising on control or security.

But that’s just the start.

Why We’re Rebranding

With the rise of agentic workflows and AI integrations, we believe delegated account automation is the next frontier.

Most tools today don’t offer safe, self-custodial delegation - especially for agents handling complex tasks. That’s why we’re going all-in on the delegation and automation stack, and rebranding from ZenGuard to Brewit.

What’s Coming Next

We’re building a full-stack account delegation and automation framework for the new wave of smart accounts. Our roadmap includes:

• 🧠 A consumer crypto app built for secure, delegated experiences (Already live: Try now: https://brewit.money)

• 🤖 A verifiable agent delegation layer for controlled task execution for accounts

• 🔐 A verifiable automation layer enabling DeFi, security, and recovery flows for accounts

• 🛠️ Tooling for developers and users alike to build and adopt better crypto accounts

At Brewit, we’re not just building another app.We’re crafting the foundation for a new generation of secure, composable, agent-ready crypto accounts.

👉 Try the Brewit App👀 Stay tuned for our next big release - delegation and automation infra for onchain accounts coming soon.

http://brewit.money/

🔗 Follow us for updates and assistance:

🌐 Website🐦 X🛠️ GitHub💬 Telegram

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.

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.