User experience, bridges and going around in circles.

For people being long enough in the space, it is not hard to realize that there are periods when people spend tremendous energy and time finding solutions to almost solved problems or decide to spend a couple of years finding new solutions by creating new problems along the way.

This type of thinking wastes tremendous energy, brain power, and a lot of money in a space that urgently needs solutions to user experience, adoption, and protocol interoperability.

Case in point, L2s and “decentralized sequencers.”

Having spent almost three years building scalability solutions for L1s, the community and crypto “experts” are now realizing, and some VCs with them, the design complexity of L2s and what it means for users and L1s.

Briefly, most Rollups, or L2s, achieve scalability by offloading settlement, consensus, and data availability to L1s while keeping transaction execution on L2. Rollups depend on a bridge contract that lives in the L1 and an off-chain aggregator, called a sequencer, which batches user transactions and then submits them as a new block to the Rollup chain (for deposits), or provides the evidence needed on behalf of the user, for the user to be able to withdraw their funds from the Rollup back to the L1.

However, this design approach has also created new problems. In our view, the two most critical issues are:

1. Suquencer in current scaling solutions is centralized and singular.

2. Whenever you have a bridge contract design for communication between chains, you need to mint another token representing the main (L1) token in the new chain.

With the first, censorship resistance is thrown out of the window for scalability. In contrast, with the second, you create friction, complicated user experiences, and after all, a significant barrier to adoption for new users.

So where do we go from here? I believe nowhere, and things will keep evolving as they have been the last couple of years.

But some solutions can work now, guarantee censorship resistance, and transfer developers' focus from technology masturbation to easy-to-use products. These solutions exist today in ecosystems like Polkadot and Cosmos.

Polkadot was designed to have many chains, each solving a specific problem, that can communicate without moving any assets. Each chain in this ecosystem enjoys the same security, derived from the sum of all chains, and is ensured by the main chain (Polkadot), which also remains decentralized by allowing an infinite number of validators. The communication protocol between the parachains is called XMC.

On the other hand, Cosmos-compatible chains have a built-in communication protocol called IBC. While the architecture of Cosmos is different from Polkadot, it achieves trustless cross-chain communication without limiting the scalability of the ecosystem. Unlike Polkadot, there is no shared security or main chain.

The main takeaway is that we can shift the design focus from the security/centralization/mint of new tokens space, which creates friction for the user, to the liquidity design space. What I mean by this is with solutions like Polkadot and Cosmos, there is embedded interoperability between chains. At the same time, a user can trade/exchange native BTC for native ETH in a decentralized way. What is needed in this case are solutions that will bring more liquidity to protocols, better use of on-chain liquidity with protocols like Mangrove, yield products based on native tokens, etc. This could also turn the focus to better user experiences, easier to understand for new users, and higher confidence for them to transact.