ZORA Modules and Protocol Architecture

Since rolling out ZORA V3 at the end of January, the response has been a resounding ‘Yes’. The question begs: How does ZORA’s composability, immutability, universal accessibility, and censorship resistance operate; and how do we ensure developers outside of ZORA can continue to use any version of our contract while minimizing migration costs for ZORA users? For those who wish to lift the proverbial hood of the car, some words from the engineering team on protocol architecture.

**

Smart contract development has introduced a new type of infrastructure for the internet. For the first time, we can create public goods that require no maintenance, are completely permissionless, and will survive for as long as the underlying blockchain on which it is built, exists. As such, developers are now able to utilize third-party services with a provable guarantee that the underlying behavior will never change unexpectedly.

We call this type of architecture a Hyperstructure. Since the launch of our first NFT protocol in January 2021, ZORA has exclusively built Hyperstructures. All of our contracts are completely permissionless, free, and neutral. Any developer can choose to build on a ZORA protocol at any time, and at no point will ZORA, or any party, be able to stop them.

Today, anyone can deploy a simple contract that takes an ERC-721 (like a Blitmap), converts the NFT into ownership shares with Fractional, and then uses those ownership shares as the governance tokens for a DAO. Since both Fractional and Blitmap were deployed with no admin functionality, you’re guaranteed from the moment of deployment that the underlying dependencies will not change from underneath the contract. If the DAO also had no admin functionality, an entirely separate developer could then build permissionlessly on top without worrying about any of those underlying services going down or changing suddenly.

From an engineering perspective, building a Hyperstructure is much more akin to building hardware than a traditional software product. As soon as we deploy, we are unable to upgrade, remove, or gatekeep our code. In the same way a new hardware product requires new supply chain management, assembly line upgrades, and product distribution—any new product iterations require a new deployment, address, migrating our users, and setting new ERC-20 and ERC-721 approvals.

This leads to a unique problem: how do we minimize the migration costs for ZORA users while ensuring that developers outside of ZORA can continue to use any version of our contract? Here are the following assurances:

1. Developers can trust the underlying implementation won’t change without notice.
2. ZORA users won’t have to re-approve their ERC-20s and ERC-721s.
3. ZORA can deploy upgrades and market types as fast as possible.
   

Option 1: Proxy Upgrades

The popular solution for shipping fast in Web3 has been to use a Proxy Upgrade Pattern. This pattern involves shipping a lightweight proxy contract and having it delegate business logic to a deployed implementation contract. At any time, the developer can upgrade their proxy contract’s underlying implementation. In addition, since the address of the proxy contract never changes, users never need to change their approvals to continue using the contract. This ease of use comes with a cost—no one else can ever build on that contract trustlessly, as the contract can change at any time.

Option 2: Independent Contract Deployments

Conversely, we could deploy each ZORA upgrade independently. This means that developers could build on top of each contract trustlessly, but users would have to re-approve every new contract iteration.

Neither of these potential solutions satisfy all three of our requirements, and we’re left with trade-offs.

Solution: ZORA Modules

ZORA V3 accomplishes this with modules: trustlessly deployed market contracts that utilize shared transfer helpers to mitigate user migration costs, while allowing developers to build on top of them without worrying about underlying changes. A brief overview of how modules work is outlined below.

With this architecture, users only need to approve their tokens once, and those approvals will continue to be valid for each module deployed in the future. Using an optimistic gas price of 100 gwei, we can visualize exactly how much gas is saved over time with ZORA modules.

We can’t wait to see the novel market modules proposed by members of the ZORA community.

Special thanks to Jorge Izquierdo and Dan Robinson for advising on the initial designs for our V3 protocol.