Why ZeroDev Gave Us More With Less
The financial industry is undergoing a profound transformation as technology, regulation, and investor expectations continue to evolve. At Liquida, we closely follow these developments while building solutions designed to address some of the most persistent inefficiencies in modern financial markets.
Our team is focused on understanding where the industry is heading and how emerging platforms, technologies, and investment models will shape the next decade of financial infrastructure. You can learn more about our mission and the team behind the project on our About Us page.
Choosing the Best of the Best of the Best
When choosing technology providers at the start of a project it is tricky for sure, everyone will tell you the big industry names that carry big industry standards with them, and 9 times out of 10 this will normally work. But when you are trying to do something no one has done before this becomes hard, because all of a sudden those standards may not work for the path your product is trying to walk.
This happened to us. When we first started our product build we looked at the gold standard for EVERYTHING! Chainlink for an oracle, Gnosis Safe for the multisig, and many other well known providers. All of these guys are great at what they do and lead the way in it for sure. But at our stage, paying for enterprise abstraction before we understood exactly what we needed would have been a poor architectural decision. Sometimes you can't afford to have your hand held and be shown the way, sometimes you have to be given the tools and build your way to Jerusalem - so to speak.
I also recommend not to build your product around one thing and then change it mid way through the build, your engineers will not thank you for it. I say this because we did exactly that. We built our eco system around several providers and they worked great for our POC but cost and testability of some of them is what bugged me, in particular the wallet layer.
The Two-Wallet Problem
If you have been around for a minute in Web3 you will know that wallets are not for beginners, they are the proverbial keys to the kingdom, and unless you have gone through the wringer of setting up a browser wallet like MetaMask, you probably won’t know what to do with a private key if it were delivered in the post. Our two-wallet problem looked like this, how do we govern the infrastructure of our protocol, and how do we make a product experience for a client so that they don't even realise they're using a wallet?
To solve our problem we must first look within, and that started with the statement, one person cannot control the infrastructure. Our contracts and vaults contain privileged roles capable of changing parameters, managing permissions and performing administrative actions. Our protocol could not ultimately come down to a co-founder's MetaMask. One compromised laptop/private key should not equal compromised Liquida infrastructure. We needed governance, distributed control and reduced single-key risk.
Multiple authorised people → approval threshold → execution
Fortunately, this is a well-trodden path in Web3. Multisig governance is hardly a new problem, and we had some of the best infrastructure in the industry to choose from. But what about the other half of our two-wallet problem? During our scoping meetings we lived and died by the following statement: Our clients should never need to understand wallets. The best wallet experience for an institution might be one where they never realise they're using a wallet. We didn't want our clients to learn Web3. We wanted Web3 to learn how our clients already work.
Our clients aren't crypto natives. They are institutions coming to Liquida because they hold financial assets and want liquidity. There is absolutely no reason they should need to understand seed phrases, private keys, gas, RPCs or browser extensions to use the product. There needed to be a better way.
For our clients, we wanted fewer signatures. For ourselves, we wanted more. On one side we needed an account that could feel like any modern financial application. On the other, we needed an account capable of enforcing how our protocol infrastructure could be controlled. The obvious answer was to treat them as two different problems, and that's exactly what we did:
- Governance problem? Multisig → Safe.
- Client problem? Managed/embedded wallet provider (WasS).
- Authentication? Another system.
- Gas? Another consideration.
- Permissions? More infrastructure.
I want to make one thing clear: none of these decisions were bad ones and would have done the job. The problem was what happened when we put all of those perfectly reasonable decisions together.
More With Less
As Liquida became more sophisticated, we realised our infrastructure actually needed to become simpler. More providers meant more SDKs, more documentation, more integrations, more security assumptions and more things that could break. After winning first prize at the Arbitrum London Founders House in July, we were fortunate to have the support of the Arbitrum team, who introduced us to ZeroDev.
For those of you who don't know, ZeroDev offers a programmable smart-account layer. Instead of treating wallets, permissions, authentication, transaction execution and multisig governance as completely separate infrastructure problems, we could start treating them as different configurations of the same underlying account infrastructure.
What stood out wasn't any single feature. It was how composable the infrastructure was. We weren't being told what a Liquida wallet should look like. We were being given primitives, through ZeroDev's Kernel smart-account architecture, that allowed us to decide that for ourselves, and this fundamentally changed our two-wallet problem:
Client account
- familiar authentication
- wallet abstracted away
- permissions constrained to what the client is allowed to do
- transaction execution hidden behind normal product actions
- gas abstracted from the user
Governance account
- multiple signers
- threshold approval
- tightly scoped permissions
- privileged protocol actions
- auditable execution
All of this from the same underlying infrastructure, but providing a completely different security model and user experience. One thing I want to point out is that ZeroDev did not magically remove the complexity, we still had to think about permissions, recovery, authentication and exactly who could do what. What they did remove was the stitching of those decisions across several separate providers. Ultimately, what started as us hunting for a wallet provider, turned into an opportunity to remove several infrastructure boundaries altogether.
Less Doesn't Mean Free
Composability comes with responsibility, ZeroDev gave us the primitives to build the architecture that is right for us, but it also creates more ways to get it wrong. The ability to configure almost anything is useful right up until you configure the wrong thing. It solved a problem, but it also opened a much deeper set of internal discussions around game theory and what if analysis, below is a flavour of that:
- What requires multiple signatures?
- Which client actions can execute without additional approval?
- What happens if a signer is lost or compromised?
- Which permissions expire?
- How narrow should transaction policies be?
- Who can change those policies?
- What does recovery look like?
- How do you preserve an audit trail?
The proof is in the pudding, we have since answered the questions and implemented the resulting controls but not without a few sleepless nights, rabbit holes and discovery sessions that saw no end. We weren't looking for infrastructure that made the decisions for us; we wanted infrastructure that gave us enough control to make the right decisions ourselves. Using fewer providers can be great, but it also means owning more of the architecture yourself. In our case, at least we now owned more of it in one place, with fewer boundaries and fewer assumptions between them.
The Final Lesson
Building a POC teaches you whether something can work, but building the company around it teaches you whether the architecture should work that way in the first place.
We started our journey looking for the best of the best of the best, it was never at the forefront of my mind that less truly can be more, that has probably been the biggest lesson from this part of the Liquida build. Reducing your provider footprint isn't about chasing the smallest possible technology stack, and it certainly isn't about replacing good infrastructure for the sake of it. It is about understanding where boundaries genuinely need to exist and where you've created them simply because that is how the industry has traditionally divided the problem.
I still don't recommend swapping infrastructure providers halfway through a build, your engineers really won't thank you. Unfortunately, when you're the engineer who made the decision, there's nobody else to blame, but in this case, it was worth it.
We started looking for the industry standard for each individual problem. What we should have been asking was whether they were really individual problems at all. ZeroDev didn't just give us another provider. It gave us an opportunity to remove several infrastructure boundaries and rethink how accounts should work across Liquida. Sometimes making a system more capable doesn't mean adding more infrastructure. Sometimes it means having fewer pieces that can do more.
If you are interested in learning more about our vision, exploring potential collaboration, or discussing investment opportunities, we invite you to connect with our team.
You can learn more about our company on our About Us page, meet the people building the project, or reach out directly through our Contact Us page to start a conversation.
Disclaimer: The content published on this website is provided for informational purposes only and should not be interpreted as financial, investment, or regulatory advice.