The GuardianUI Origin Story
GuardianUI actually started as something much different than its current form. Much different.
I remember seeing this tweet back in April from the OlympusDAO giga-chad, Indigo, and it immediately struck a chord. Come to find out it was actually another chad, Appleseed, who came up with the idea — but regardless, I thought it was a clever concept.
I’m not a developer, but it seemed obvious that smart contract security has a long way to go. Why are DAOs / companies / organizations paying hundreds of thousands of dollars for audits that are largely sh*t? Just run through the Rekt leaderboard and see how many of these hacks were audited by multiple firms.
There’s also tons of hacks on that leaderboard that were unaudited, but what if you could provide peer-to-peer code reviews among a friendly set of DAOs? Could friendlies help identify and address attack vectors before code is pushed to production?
I decided to hit up my buddy Lienid (full-stack dev from Olympus). I knew he was also looking for a side project, and he’d be fun to work with. We agreed a peer-to-peer review system where DAOs reviewed each others’ code seemed like it could work well — especially because quality and accountability could theoretically be socially enforced by affecting a DAO’s or dev’s reputation.
Enter: Elsyn DAO (GuardianUI’s predecessor)
We had the crux of the concept from Indigo’s tweet, but how do you turn that into a business? After tons of research and conversations, we felt like there were four primary problems with the current smart contract security system:
- Audits are used as a single point of failure — We don’t have robust multi-layered security programs.
- Scheduling audits is inconvenient — Projects chase down numerous audit firms and potentially have to wait months for availability.
- Development best practices are underutilized — Rigorously building specifications, performing vulnerability analysis, and building robust test suites is the exception not the rule.
- Code is not continuously reviewed — Bug bounties are common but often do not provide reviewers full information due to the risk of black-hat exploitation.
We felt like in a perfect world…
- Organizations would have easy access to a multi-layered code review and best practices.
- An organization would only need to go to one party to schedule its code review needs.
- Code review availability would be guaranteed and predictable.
- Security reviews would be continuous and not dependent on one-time audits.
- Top-tier individual reviewers can make above market rates for their services.
The ELSYN Framework
Elsyn planned to provide a network of developers and organizations with a robust end-to-end security program for the benefit of member organizations. Core tenets included:
- Guidance on best-processes for development including documentation, risk assessment, coding, and testing.
- A Phase One review through a peer review by other organizations in the network. This review would be structured with a list of vulnerabilities to check and confirmation of appropriate test structure and adherence to best-processes.
- A Phase Two review by a distributed group of independent developers in the network via contests / rewards.
- An ongoing Phase Three review using bug bounties.
To summarize, ELSYN planned to develop and coordinate a multi-dimensional and continuous review system for member organizations. We’d monetize through a membership fee and by taking a fee on bounties.
It’s actually really cool to still see other people exploring similar ideas.
Seeds of Doubt
Lienid and I mapped out the business model, developed our operational plan, and started knocking on doors looking for market feedback.
I think most everyone thought the original idea from Indigo was cool - and the concept should potentially be explored - but we started hearing questions/comments such as:
I’m a dev but not an auditor and don’t feel comfortable reviewing other DAOs’ code because of potential personal liability.
How will you match review supply/demand among members so everyone feels like they’re getting as much as they’re giving?
How do you assure the quality of your reviewers? It’s a specialized skillset that not all devs do well.
How is your Phase Two review any different than Code4rena?
How is your development best practices guidelines any different than others already in market?
Why should I pay ELSYN to coordinate when we can establish an informal review collective of other DAOs and outsource the other ELSYN elements to Immunefi, Code4rena, etc.?
FANTASTIC questions! We have answers for many of them…but…then we spoke with Ivelin.
The ‘ah ha’ with Ivelin
Ivelin is one of my co-founders in Sporos DAO. We met last year and immediately hit it off. He’s a serial entrepreneur, dedicated open source contributor, and highly-disciplined developer. He has a great combination of pragmatism and vision — and I highly value his opinion. He’s also a huge proponent of end-to-end testing and building applications sustainably.
When I pitched him ELSYN, he got it immediately and didn’t hate it, but I could tell he wasn’t jumping out of his seat. And because I was second-guessing the plausibility of ELSYN at that point anyway, I wanted to get Ivelin’s fresh perspective on the potential opportunities in the security space even if that meant a hard pivot from ELSYN.
Over many weeks, Ivelin, Lienid, and I talked about several ideas across the web3 tech stack (frontend -> wallet -> smart contract), but some form of testing was at the core of most it. And all of them were products, not consulting services (a la ELSYN)
The net net is we’ve chosen to focus on frontend defense in the “Full Stack Web3 Defense” landscape. Our rationale is pretty simple:
With 100% E2E test coverage, it is very likely the tests will break if the web app code was hacked and changes UI behavior or the contracts were hacked / upgraded and misbehave. Mainly, it can incrementally strengthen defenses to prevent old boring attacks sneaking in. Almost all known attacks are due to some boring human mistake that took a shortcut in dev, security, or ops best practices. They’re rarely innovative super geek hacks.
This a16z pod does a good job discussing the importance, impact, and neglect of testing in web3.
See Curve and other stories about front end hacks. It doesn’t matter whether the contracts are secure if the web app is compromised.
Going Forward
I plan to share more in public as we build GuardianUI, a platform that helps web3 developers keep their users safe through E2E automated testing by validating and monitoring an app’s live UI to ensure it creates the expected smart contract interactions.
We think there’s a massive need for our solution, especially as the web3 industry continues to grow. You can check out this post for an intro to GuardianUI.
If you want to join our private beta, please complete this short waitlist form.
Follow us on twitter and hit us up there.
About GuardianUI
GuardianUI is the testing and monitoring platform for web3 frontends. Our SaaS platform integrates and automates end-to-end testing, application performance monitoring for web3 critical paths, and real-time alerting and observability to ensure deployed applications create the expected smart contract interactions for users.
