Zora is one of my favorite consumer apps in crypto; it has a straightforward economic structure and UX. As a researcher and a content creator, I’m obsessed with their platform. However, I believe that they are still missing a crucial element in the UX of web3: multi-chain fragmentation. I want to share my thoughts on solving this issue for both EOAs and Smart Accounts.

Zora is easy to use.

Zora is web3’s Instagram; creators simply share their art and earn money & visibility. It is as simple as web2 for creators. They have put a huge effort into making it easy for creators. Creators can be onboarded to Zora with only mail, and they can easily upload their images and let users mint & collect them. So, they have solved the issues for the creators. Gasless, seedless, semi-custodial onboarding for creators, which solves almost all issues for them.

But for users, the onboarding and having an asset on Zora is still a huge problem, and the main problem for users is bridging & cross-chain problems. Imagine that you’ve been onboarded to the Zora app and want to mint an NFT; how do you do it?

1) Using onramps or CEXs - which is not available for almost half of the world

2) Using Zora’s native bridge - took at least 10 minutes and costs 20$.

3) Using third-party, rollup to rollup bridges - UX is broken; I used Orbiter bridge to fund my Zora Chain wallet, and my funds got stuck for about 2 hours.

4) Instead, I created a collection and allowed my followers to mint. I funded my wallet this way because other methods were not broken.

Before that, what was my intent to fund my wallet?

Minting an NFT for an amount of ETH or any ERC-20.

There should be an easy way to understand users’ intent and execute it, and with the rise of new multi-chain bridges, it is possible to build a composable version of Zora.

The solution for EOAs: Finding a trust-minimized way for token bridging.

I’m sure that there are a lot of trust-minimized ways for doing it multi-chain, but the solutions that I’m aware of are liquidity bridges: Hop and Connext.

They allow you to call a function that doesn’t depend on where users are, but they are not that cost-effective for big amounts of money. these systems allow users to perform cross-rollup transactions without leaving the rollup.

Liquidity bridges allow trust-minimized and fast bridging, but their costs are not that cheap. Trusted bridges like Orbiter offer fast and cheap token bridging, but it comes with a huge trust assumption. But given that it is only for token bridging and is going to be used for only small token transfers, the trust assumption can be understandable for this use case.

Or we can also use Hyperlane and create a bridge with the trust mechanism that we prefer (Their verification layer is modular) - Interchain Accounts, MPC-based solutions, and many more.

So, if we can assume that we’ve found the best way for token bridging, the only thing we need is to create a good front end. The ideal user flow should be like this for a. new web3 user:

• The user is getting onboarded to the app,

• Selects the onramp provider or getting funded via CEX

• Starts to use the app.
  With the cross rollup compatibility, newbie users are getting a huge advantage: they can use all onramp options available for ALL Ethereum Rollups. Let’s give some examples:

  • If the user is from the US, they can be onboarded via Base - Coinbase, which is so easy to use and is doing a great job with Circle.

  • If the user is from Chinese, then it can be onboarded via OKX or Binance to Arbitrum or Optimism, and they can even not realize that they’re on a different rollup.

If the user is an existing Ethereum Rollup user:

• Users are getting onboarded to the app

• Start to use the app without thinking about which Ethereum Rollup they’re on.

This is easy for EOAs because you simply get the same account on different Ethereum Rollups, and key rotation is not supported in EOAs, which makes them easy to control across different rollups. Let’s talk about smart accounts and how to make them multi-chain with as less trust assumptions as we can get.

Smart Accounts & Multi Rollup Zora Experience:

Before diving into details, I want to highlight an important problems of multi-chain AA: cross-rollup synchronization. Since the Smart Accounts are working with Smart Contracts and Ethereum rollups can not communicate with each other in a fast, cost-effective, and trust-minimized way, we can not synchronize smart contracts.
Also, calculating the address with Create2 is working smoothly as soon as the Ethereum rollup is EVM equivalent. For example, if the chain that the smart account settled is on zkSync, then the zkSync address and other EVM addresses are going to be different. This problem can be solved via ENS.

I’ll explain my thoughts on smart accounts by dividing them into two parts:
1) Smart Accounts that use secp256k1 curve for main validation (EOA like smart wallet but with advanced AA features)

This is easy because most of them are working on only EVM equivalent networks and use the same address; the only thing that the bridge relayer needs to do extra is sponsor the first transaction for deployment (or it can be done by batch transactions).

So the user flow will be like:

• The user is getting onboarded to the app

• Starts to use.

But under the hood, the bridge relayer executes the token bridging and sponsors the useroperation.

2) If Smart Account uses a different elliptic curve: Passkey and Secure Enclave based signers.

This is a bit harder than other solutions because passkeys use secp256r1, and it needs an onchain verification, which consumes high gas if the chain that Smart Account lives doesn’t support RIP-7212 (A precompile contract for secp256r1 verification), which I’m also one of the co-authors of it. I’d be so happy to see Zora also integrating RIP-7212 to be compatible with other rollups.

But let’s talk about the worst cases: the case that a passkey-based wallet is living on a non-EVM equivalent chain or Zora has no RIP-7212 support.

In this case, the ideal solution is having a double signer enabled validator contract for the smart account; one signer should be the passkey itself, and the other signer should be a signer that works with a Turnkey, Portal Enclave key management system. If Turnkey or Portal tries to censor users, they should be able to escape from their censors, but without RIP-7212, I don’t think that passkey-based wallets can be first-class citizen smart wallets.

But calculating the account address becomes more and more problematic with this structure because the bridge relayer should know the public key of the passkey + turnkey’s public key, and as you can see, it is complex = extra code bug risk…

And this solution adds extra trust assumptions and a lot of engineering complexity to the app.

But with these supports, Zora will be able to reach more existing web3 users and more onramp solutions for the newbies. For example, we -Clave- are working on having a 1:1 ratio onramp for the Turkish Lira onramping, which will make Turkish users' onboarding much easier, and this is just one simple example of a specific region.

Final thoughts:

These thoughts are just some random thoughts that I had while using Zora. I know that engineering complexity kills innovation, and my writing should be just considered as a random - non-deven feeling of a web3 researcher.

I love Zora and will keep using it :)