Barriers to Adoption
For two systems to effectively interoperate they must be able to communicate and exchange data in such a way that the data exchanged is understandable to each system. However, ensuring that the data exchanged is easily understood by the receiving system can be as complex, if not more so than the systems themselves.
Whether you believe in a future where there will be many different blockchains, where every DApp and DAO will operate its own chain and they will have their own native token, or a future with just a handful of layer 1 protocols – the user experience with even a single token is too complex for the majority of potential users, and developers.
The Enterprise perspective is also an important one to consider. The volatility of ledger costs and token prices makes it impossible to plan costs and budgets around high value use cases. Another major issue pointed out in our conversations with enterprises is that they do not want to be locked into one single protocol, especially this early in Web3’s lifecycle. However, currently the vast majority of all DApps are single network applications.
Companies select cloud platforms based on convenience, not pricing. But up to now, tooling for cross chain integrations has focused largely on technical scalability and interoperability, with little attention being paid to economic interoperability or the incentives required for internal experimentation with a Web3 technology stack.
Interoperability
Interoperability is a very nuanced subject and deserves a brief unpacking. As mentioned, the two principal layers of interoperability are 1) the actual exchange of data and 2) the understanding of that data.
The actual exchange of data is a technical undertaking and something that a lot of awesome teams are working on. Teams like Biconomy are working on a relayer as service infrastructure which would enable DApp developers to cover the meta transactions of their users, similar to how a merchant might cover your debit/credit card fees. Loom has built a multi-chain interoperability platform for DApp developers, and many more much needed solutions are in production. These are both great projects, and they address very critical issues concerning UX and data exchange across networks, but interoperability is multi-faceted.
Ensuring that the received data is actually understood is a very complex problem. Loom, Biconomy, and other great projects like Fission do a great job offering tooling for developers, but economic complexity and interoperability remains an unsolved issue – it is still very difficult to get tokens from one network into another.
Even for just a single network, the price of the token and its ledger fees/ gas costs/ transaction fees are both volatile. In our vision of Web3 where DApps leverage multiple protocols for a single use case, this volatility becomes magnified as a use case scales. Each protocol is working on their own mechanism to address these issues, but there is a lack of mechanism composition. The non-linear effects of mechanism composition can be huge.
Enterprises want convenience and pricing they can plan around. Developers need a unit of account tied to actual usage, and consumers just want the simplicity of a single (or no!) tokens.
Enter ZIP.
Z!P
ZIP is a POC we want to now open up as a collaborative community based project.
Our objective with ZIP is to develop a stable crypto commodity that abstracts the economic complexity for developers looking to build, deploy, and operate multi-network integrations. ZIP will provide a single unit of account across multiple ledger, stable usage prices, enable multi-network ‘cloud-credits’, and AWS-like pricing models that appeal to enterprises.
ZIP is a multi-network gas station backed by a collateral pool. The token itself is a burn-and-mint model with four key elements to its operation:
- Network tokens are locked up as collateral.
- ZIP is minted at the market rate according to an oracle and smart contract.
- Users purchase ZIP tokens (via a DEX with an optional fiat-on-ramp).
- When ZIP is spent, the tokens are burned, and the collateral is used to cover the cost of ledger use.
ZIP is pegged to a universal unit of compute, i.e. the price of ledger operations in USD. The abstraction is analogous to FLOPS, and the price to the user is stable, updating quarterly according to a forecasting model. The margin on actual ledger costs versus the sale price of ZIP serves as the project’s primary source of revenue once fully operational, very similar to how a futures market operates.
The collateral pool is a managed basket of tokens that can be used to build DApps across the networks corresponding to the tokens it contains.
Key Network Roles
Like many of the projects in Web3, ZIP will require a community of stakeholders to participate in network roles designed to operate the network. Current work is focused on designing the specific work flows and incentives for each key role, and details will be released in a following post. Broadly supply side roles can be broken up into two categories:
Liquidity providers are participants that lock tokens up as collateral to mint ZIP. They are incentivised via basket interest achieved through Alkemi, Balancer, or a similar approach. They may also wish to lock tokens up aiming to hedge against their own token volatility since ZIP is not pegged to USD, but instead to a global measure of compute.
Peg Management Keepers: These network roles will be key to ZIP operations entrusted with ensuring the ZIP peg is maintained, very similar to how Keepers on MakerDAO ensure Dai’s peg is maintained. However, in FUEL, Fetch Agents will be leveraged to execute operations also based on predictions as opposed to only observed volatility.
Value to Users
Demand side roles for ZIP are largely centered around the utility of ZIP. Users of ZIP can be end users, developers, or companies. Below we briefly outline some potential utilities for ZIP.
- ZIP can be used as multi-network cloud credits.
- ZIP enables enterprise friendly pricing – seeking to be stable and predictable – and can act as an entitlement tool for development contracts clearly showing the amount of resources being allocated and consumed by a given application.
- ZIP can be used as an incentive tool by enterprises to enable their developers to freely experiment with existing Web3 tools and infrastructure instead of building in-house tooling from scratch.
- ZIP allows its users to avoid platform lock by tapping into external developer networks and tooling.
- ZIP can be used by networks to lock tokens up guaranteed to be allocated for internal network functionality. This encourages internal velocity of the token inside the network, as opposed to externally on exchanges.
- ZIP can be a simple onramp for users looking to interact with Web3 protocols and DApps (made even simpler with a fiat-on-ramp)
What’s Next
Our plan with ZIP is to make it an open source tool for any group of networks, DApps, DAOs, Developers, or enterprises to abstract the economic complexity away from building on Web3. Our hope is that by empowering the ZIP community to abstract the economic complexity away from Web3, the adoption required to bootstrap a cambrian explosion of network roles (remote work!) can begin to take shape.
We are currently building out our POC, and in planning stages for our MVP at which point all code will be made open source with the objective of having it evolve into a plug-and-play piece of infrastructure for existing Web3 developer tooling.
The purpose for releasing this post is to start to grow the community around this project leading up to our official release. We are actively seeking Developers and Token Engineers to begin hacking on some of the fun challenges that lie ahead. Or, if you think your project can benefit from ZIP, please get in touch as well.
However you would like to get involved, please join our Discord channel for updates and to connect directly with Theo or myself. Look forward to everyone’s input!
In no particular order, thanks to Don Gossen, Dimitri De Jonghe, Eden Dhaliwal, Michael Reuter, the team at LimeChain, Alexander Ramsey, Jeff Emmett, Sebastian Wrobel, Trent McConaghy, Boris Mann, Jake Brukhman, Ryan Breen, Toby Simpson, Humayun Sheikh, Eddy Louchart, Marta Piekarska-Geater, Bob Crozier, John Calian, Christian Kourtis, Dominic Moore, Aron van Ammers, Joel John, Jamie Burke, and our colleagues at Outlier Ventures for your insights.
Disclaimer
This document (the “Document”) has been prepared by Outlier Ventures Operations Limited (“Outlier Ventures”). Outlier Ventures Operations Ltd is registered in England and Wales, company registration number 10722638. Outlier Ventures Operations Ltd is an appointed representative of Sapia Partners LLP (“Sapia”) which is authorised and regulated by the Financial Conduct Authority (Firm Reference Number 550103).
No undertaking, warranty or other assurance is given, and none should be implied, as to, and no reliance should be placed on, the accuracy, completeness or fairness of the information or opinions contained in this Document. The information contained in the Document is not subject to completion, alteration and verification nor should it be assumed that the information in the Document will be updated. The information contained in the Document has not been verified by Sapia, Outlier Ventures or any of its associates or affiliates.
The Document should not be considered a recommendation by Sapia, Outlier Ventures or any of its directors, officers, employees, agents or advisers in connection with any purchase of or subscription for securities. The value of any investment may go down as well as up. Recipients should not construe the contents of this Document as legal, tax, regulatory, financial or accounting advice and are urged to consult with their own advisers in relation to such matters. The information contained in the Document has been prepared purely for informational purposes. In all cases persons should conduct their own investigation and analysis of the data in the Document. The information contained in the Document has not been approved by the Financial Conduct Authority. This Document does not constitute, or form part of, any offer of, or invitation to apply for, securities nor shall it, or the fact of its distribution, form the basis of or be relied upon in connection with any contract or commitment to acquire any securities.
Any forecasts, opinions, estimates and projections contained in the Document constitute the judgement of Outlier Ventures and are provided for illustrative purposes only. Such forecasts, opinions, estimates and projections involve known and unknown risks, uncertainties and other factors which may cause the actual results, performance or achievements to be materially different from any future results, performance or achievements expressed or implied by such forecasts, opinions, estimates and projections. Accordingly no warrant (express or implied) is or will be made or given in relation to, and (except in the case of wilful fraud) no responsibility or liability is or will be accepted by Sapia, Outlier Ventures or any of its directors, officers, employees, agents or advisers in respect of, such forecasts, opinions, estimates and projections or their achievement or reasonableness. Recipients of the Document must determine for themselves the reliance (if any) that they should place on such forecasts, opinions, estimates and projections.
Information contained in the Document may not be distributed, published or reproduced in whole or in part or disclosed to any other person. The distribution of any document provided at or in connection with the Document in jurisdictions other than the United Kingdom may be restricted by law and therefore persons into whose possession any such documents may come should inform themselves about and observe any such restrictions.
