Brought to you by @0xfan

TLDR:

• The current ecosystem for Application-specific rollups (RollApp) comprises four types: RollApp SDK, Rollup-as-a-service (RaaS), Rollup-SDK-as-a-service, and Unified Sequencing Network.

• RollApp SDK helps create personalized rollups for developers. Typically, RaaS providers leverage Rollup-SDK to develop their services, which eliminates the need for coding rollup deployment, delivering a smart-contract-like development experience.

• While RaaS is primarily intended for smart contract developers (2C), there is also a need for aggregating all these different SDKs for developers, leading to the emergence of a 2B service provider - Rollup-SDK-as-a-service.

• Unified Sequencing provider leads to specialization in some features for sequencers such as decentralization, scalability, and security.

• There are four major types of rollups: Settlement Rollup, Sovereign Rollup, Based Rollup, and Enshrined Rollup. Different RollApp SDKs and RaaS are focused on different types of rollups with their own trade-offs.

• The current RaaS projects offer a similar degree of customization. The primary concern is the extent to which these features have been implemented and the speed and stability at which they can be deployed.

• Unified interfaces lead to modularity. Modularity, in turn, brings composability, unlocking the potential for a multitude of app rollups. In the absence of unified interfaces, there is a risk of ending up with a collection of Legos that are incompatible with each other.

• The decentralization of sequencers could be compromised in the market. Rather, the ability to effectively execute the business model and the convenience of launching and customizing an app rollup are highly valued, even if the nodes are initially not decentralized.

Application-specific rollups (a.k.a RollApps) are shaping up to become an important narrative in the blockchain space. While this idea of “RollApp” is still very young today, we have seen several projects in this field arise over the past year.

In this overview, we want to highlight and compare some of the different solutions within this specific field, as they may prove to become an important factor in the blockchain space in the foreseeable future. Before we dive into these individual solutions, and it’s important to discuss how we got here.

Initially, developers only had the option to deploy on top of an existing Layer 1 (L1) chain (Ethereum, etc.). While deploying on top of an existing layer provides builders with sufficient security guarantees, they lack the scalability features required to scale to the masses. In order to combat this scaling issue, we started to see the development of more and more rollups, as opposed to more L1 chains. Rollups provide sufficient scalability, while still preserving the security of the underlying base chain. Although this managed to solve some of the scaling issues, developers now faced the issue of customizability.

Every dapp that deploys on top of an Ethereum Layer 2 (L2) shares computational resources with all the other dapps within that rollup, leading to an intensive gas war for battling the limited blockspace. Aside from this, dapps also lack customizability, as they have to essentially follow the same rules as the underlying chain they’re deployed on.

Limited blockspace and lack of customizability have contributed to the rise of application-specific blockchains. This type of framework was popularized by the Cosmos ecosystem, and has been followed by Polygon Superchains, Avalanche Subnets, and others. However, even app-chains have their own drawbacks, such as having to bootstrap their own validator network and security.

But what if developers could combine the best of both deploying on a rollup, which means security right off the bat, while also benefiting from the customizability behind having their own dedicated environment?

This is exactly what application-specific rollups, or “RollApps”, are trying to accomplish. The idea essentially involves combining the aspect of borrowed security from rollups, with the aspect of flexibility and having your own dedicated environment.

1. The RollApps Ecosystem

Currently, there are four major participants from the RollApps ecosystem.

• RollApps SDK

A framework and toolkit for developers to build customized rollups with ease. However, developers need to understand the basic blockchain logic to build their own application-specific rollups. Different SDKs focus on diverse rollup types with different options for validity and fraud proofs. Therefore, it is essential for developers to choose an SDK that best suits their application needs.

• Rollup-as-a-service (RaaS)

RaaS refers to the rollup service providers. RaaS providers usually build services on top of a Rollup-SDK (e.g., Caldera uses Op Stack). There is no code for rollup deployment. All the nodes/calls have been handled by RaaS operators. For a smart contract dev, there is no need to understand the block logic, and the dev experience is very similar to the process of developing a smart contract.

• Rollup-SDK-as-a-service

RaaS caters primarily to smart contract developers (2C), however, there is a requirement for consolidating various SDKs for developers, giving rise to a 2B service provider known as the Rollup-SDK-as-a-service. Currently, there are a limited number of projects focusing on this area. The modular Cloud team presented a depiction of this functionality in 2022, but their current focus is on constructing an explorer for diverse modular blockchains

• Unified Sequencing Network

Although every RaaS or App Rollup SDK may possess its own sequencers, there remains a requirement for a specialized sequencer provider that prioritizes consensus and security of decentralized sequencer networks. A shared and unified sequencer network can simplify the attainment of atomicity and interoperability across different RollApps.

2. What Are the Different Types of Rollups?

Rollups are designed to deliver scaling benefits to L1s. They are composed of different components, including a user client, VM, sequencer, proving system ( esp. for zk rollups), one or more mempools, and a bridge contract on the L1.

While there are debates regarding whether rollups should be defined by the bridge contract or not (link), we can distinguish between “sovereign” and “settlement” rollups based on which chain/layer serves as the source of truth, similar to how we distinguish bridge protocols.

• Settlement Rollups refer to the type that relies on the smart contract on the settlement layer to verify proofs and bridging assets. This smart contract acts as the source of truth for the rollup chain. To protect this bridge smart contract, many rollup teams like Arbitrum and Optimism hold tight on the upgrade key to fix any apparent bugs on the rollup at any time. However, this authority on the other hand also gives risks for changing the code arbitrarily without being noticed.

• Sovereign Rollups were introduced by Celestia, where the rollups themselves operate like a layer 1 blockchain. The Sovereign rollup itself is the source of truth, not the L1. The rollup nodes transfer fraud (validity) proofs through their own P2P network and verify them locally, while only using the base chain to store ordered transactions.

  In addition, the community of a sovereign rollup can upgrade the chain with a hard fork without the permission of the base layer. It is beneficial when some rugs happen and a sovereign rollup wants to revert it.

• Based Rollups refer to the type of rollup that uses the L1 node as the sequencer. The L1-sequenced design can help it inherit L1 liveness and decentralization, alleviating the toxic MEV from centralized or short-term sequencers (see more on Justin Drake’s recent post). Currently, there are no SDKs or RaaS protocols that use based rollup design.

• An Enshrined Rollup means building a rollup block inside the L1 itself. On Ethereum, the execution client builds blocks containing the block header and body. If we wrapped this block as a rollup block with proofs (validity/fraud), then there is no need for other validators to re-compute all the transactions, just to compute the state difference and verify the proof.

  This idea is very similar to the stateless idea in that only one builder contains the full state to generate the witness which can then be directly verified by others without downloading all the states. Currently, Dymension is an enshrined rollup structure, and a detailed discussion on this structure will be provided later in this article.

3. Dive Deep Into the RollApp SDK Solutions

3.1 Discussion of Rollkit and the OP stack

On February 21st of this year, the Celestia team introduced us all to Rollkit, a modular rollup framework that enables developers to pick and choose between different features in order to build their own custom rollup. One of the key differences between Rollkit and the OP Stack is that Rollkit supports sovereign rollups.

（1）The VM Provided by Rollkit Might Be More Flexible than the OP Stack

The main benefit of a sovereign rollup is NOT its ability to fork, but rather that it allows the developer not to have to write a solidity light client for the rollup.

This can encourage more flexible innovation with VMs, as they are not bound to the limitations of an L1 where the zk and fraud proofs have been processed and settled. In many cases, the based settlement layer (e.g., Ethereum) would not be able to process very efficiently.

The OP Stack aims to alleviate this problem by building its own settlement layer for all the Superchains. However, the settlement layer might still be bound to Ethereum's settlement capability, which might not be a perfect place for Superchains with other VMs to settle on.

Individual VM modules that want to integrate into the OP Stack must support the Engine API, which is a collection of methods that all execution clients implement in Ethereum. The Engine API is currently undergoing development, and not all virtual machines are natively supported by this interface. As a result, there is still considerable work to be done in order to ensure compatibility with a wider range of virtual machines.

（2） Difficulty in VM Wrapping and Language Incompatibility Would Be the Major Challenges in Bringing Other VMs into Rollkit

However, if Rollkit can enable a more flexible VM design, why aren't there many VMs (such as SolVM, MoveVM) included within Rollkit?

Rollkit provides an ABCI-like client implementation for rollups. This means that it handles requests and forwards them to its local app instance through the Application Blockchain Interface (ABCI), which was first introduced by the Cosmos SDK. In other words, ABCI allows a blockchain client and an application to communicate with each other, even if they are written in entirely different languages.

On the other hand, if the client on the blockchain wants to communicate with an application (e.g., VM), then the ONLY way to do this is to call the ABCI methods by sending requests to it.

Therefore, for any application or VM, it has to be wrapped into the ABCI interface in order to be integrated into Rollkit. This is a complicated process, thus, the only VM that has been ABCI wrapped so far is the EVM (Etheremint).

In addition, it would also bring some other problems when developing. ABCI is designed by Cosmos-SDK. Therefore most tooling for building applications on top of ABCI nowadays is specific to Golang, which brings difficulty for someone who wants to bring the Fuel or Aptos stack that is written in Rust and other languages to Rollkit.

The simplest way for Rollkit to communicate applications using other programming languages is to use socket connections. However, Rollkit does not have a native capability for communicating with an app using sockets currently, which would limit the rate of migration for other VM or applications.

On the other hand, the OP stack has its ABCI-alike interface requirement called Engine API, which is underdeveloped and still has to be engine API compatible for any VM integrated into OP Stack.

（3）Rollkit Can Be Integrated into a Non-EVM Chain Like Bitcoin to Inherit Its Security, While the OP Stack Can’t

For the OP Stack, it has to rely on the third-party chain to be the settlement layer for other OP stack chains, which would require the deployment of the light client or smart contract of the source chain on the settlement layer.

Using a non-EVM compatible chain as the settlement layer requires each chain to understand and verify the proof and state of other VM systems. This necessitates a difficult process of building light clients of each other. However, it is extremely challenging to build a light or full client of the OP Stack in chains like Bitcoin, making integration into Bitcoin almost impossible.

However, since sovereign rollups verify proof through their own light clients, it can be relatively easier to pull data into bitcoin to use it as the DA layer.

（4）Validity Can Not Be Inherited from Bitcoin for a Bitcoin Sovereign Rollup

The Bitcoin Sovereign Rollup uses Bitcoin as the DA layer and verifies the proofs off-chain, but to what extent can the security be inherited from Bitcoin?

Given that it is almost impossible to write a full or light client for the Sovereign rollup on Bitcoin. This means there is no trustless bridge to move assets between Bitcoin and its Sovereign rollup, and the interpretation of the proof and state from the Sovereign rollup would be impossible.

Sreeram Kannan provides an excellent framework for evaluating the security of a blockchain. Applying this framework to assess the security of the Bitcoin Sovereign Rollup, we see that re-org resistance, censorship resistance, and data availability can be inherited from Bitcoin, leaving only the validity property as a unique challenge.

Therefore, Bitcoin sovereign Rollups are not suitable for applications that require the native use of BTC, or the ability to compose other applications' logic on Bitcoin. However, it could be a great option for projects that prioritize censorship and re-org resistance, such as NFT projects.

However, can Bitcoin become a suitable data availability layer for its sovereign rollup? Taproot witnesses have given Bitcoin the ability to include up to 4MB of arbitrary data in each block. While the cost of storing a sovereign rollup's data still requires further discussion, it may be 7 times cheaper than Ethereum on a per-byte basis, according to Eric Wall, the founder of Taproot.

3.2 Discussion of ZK Sovereign (Sovereign SDK) and ZK Settlement Rollup

ZK rollups should have a quicker finality time than Optimistic rollups, however, a ZK rollup still suffers from a long finality time due to the high cost of verifying proofs.

The cost of validating a single proof in an Ethereum rollup can range from 300k to 5m gas, depending on the underlying proof system. However, proof sizes tend to grow slowly with the number of transactions. Therefore, rollups often choose to wait and accumulate batched transactions to amortize the cost of proof verification per transaction.

The main reason for zk's long finality time in the current zk settlement rollups is the delay in time taken to decrease the cost. However, by using and trusting a centralized sequencer, zk settlement rollups can achieve faster "soft finality".

From this perspective, the Sovereign SDK offers unique advantages by achieving fast and "real" finality by lowering verification costs. Nodes in a sovereign rollup can create proofs in real-time and use recursion to aggregate them into a batch proof later. Additionally, there are no extra on-chain verification costs for a sovereign rollup, which eliminates the need for extra waiting time to amortize transaction costs.

Once again, the finality is still contained by the DA and Consensus Layer, but can largely reduce the delay caused by the high cost of proof verification.

3.3 Discussion of Enshrined Rollup (Dymension)

As we discussed above, enshrined rollup means building a rollup block inside L1 itself. In Ethereum, the execution client builds blocks consisting of the block header and body. If we wrap this block as a rollup block with proofs (zk/fraud), other validators do not need to recompute all transactions. Instead, they can simply compute the state difference and verify the proof.

This can generate a few advantages:

• No re-execution, especially suitable for state witness solution. This can also accelerate the node syncing process due to the light history load.

• Almost all the values will be directly given to L1 - the Dymension Hub.

• There is no need for building the bridge contract on the settlement layer, achieving smaller latency and faster finality.

It is difficult to incorporate enshrined rollups into Ethereum, which is why projects like Dymension are building in the Cosmos ecosystem.

However, the biggest potential problem with the enshrined rollup's SDK is its lack of flexibility and sovereignty. The basic logic of block production, proof verification, and rollup types are "enshrined" in the settlement layer and cannot be freely modified or ‘LEGOed’ by developers.

Therefore, the enshrined Rollup SDK (e.g., Dymension) is tightly bonded to its settlement layer and is hard to freely modify each module of the Rollup like Rollkit or Sovereign SDK.

3.4 What Would Be the Key Feature for a Rollup SDK?

Modularity enables composability. For instance, a modular SDK can be customized and implemented for different usage purposes, from a dex to a high-TPS-required gamefi project, by combining various modules ranging from execution environments to proof schemes. The more specifically developed modules that can be smoothly integrated into the same SDK, the higher the composability, which in turn significantly reduces the threshold of use.

However, modularity also requires unified interfaces. Having standard interfaces would make it easy to swap out components. In contrast, divergent interfaces could fragment the application rollup ecosystem. In the absence of unified interfaces, there is a risk of ending up with a collection of Legos that are incompatible with each other**.** Unified interfaces lead to modularity. Modularity, in turn, brings composability, unlocking the potential for a multitude of app rollups.

4. Dive Deep into RaaS Solutions

While building an application-specific rollup from scratch using an SDK can be convenient, there is still a learning curve and a barrier for smart contract developers who want to customize their RollApp without coding or having to know the basic knowledge of the actual rollup chain. Therefore, the rollup-as-a-service, which makes the development process similar to the dapp experience, is becoming very popular nowadays.

Each RaaS (Rollup-as-a-Service) provider allows developers to easily build and launch their own custom, dedicated rollup with just a few clicks. Some RaaS providers may be more suitable for specific ecosystems than others (Caldera for EVM, Dymension for IBC, Eclipse for SVM, etc.). However, these modular solutions ultimately allow for different components to be added over time, whether that’s a new VM offering higher throughput or a new DA (Data Availability) solution with stronger security guarantees.

Caldera

Caldera (previously known as 0xConstellation) is a rollup as a service provider focused on the EVM ecosystem. Caldera chains are highly performant (produce one block for every transaction), customizable, and EVM-compatible, which means teams are able to leverage the existing EVM tools they’re familiar with, such as RPCs and wallets.

• Execution Layer

As of today, developers can deploy their own rollup using the Ethereum VM. However, the team has already made it clear that they will be adding multiple VMs over time. Some of the ones they have named in their docs include SVM and FuelVM.

On top of choosing their preferred VM, the developer can then add his/her own custom features, such as what token to use for gas, sequencer location, bridge fees, and several other customizations (depending on what modules each solution provides over time).

• Settlement Layer

Caldera chains can be referred to as settlement rollups. Caldera chains can settle on any EVM-compatible chain. While the most popular selections include Ethereum and Polygon, other options developers can choose from, include BSC, Avalanche, Evmos, Aurora, and more.

As a reminder, this settlement layer is where all proofs would be sent, meaning that ultimately, each Caldera chain will be relying on the security from its underlying EVM-compatible settlement chain.

• DA Layer

Like the other solutions, Caldera is very open regarding the DA layer choices. Teams can choose to have their transaction data sent either directly to the EVM settlement layer (Ethereum, Polygon, BSC, etc.), or to a dedicated solution, which currently includes Celestia or Eigen DA.

AltLayer

Like Caldera, AltLayer is a rollup as a service provider based on the settlement rollup, allowing teams to spin up their own dedicated execution environments.

• Execution Layer

As of today, AltLayer allows builders to launch their own rollup using the EVM. However, they’re expected to add other options over time, such as Wasm.

• Settlement Layer

AltLayer rollups today have three settlement options: Ethereum, Polygon, or BNB. However, the team has already confirmed that they’ll be adding other EVM and non-EVM settlement options in the future, such as Solana.

• DA Layer

Sticking to the modular philosophy, AltLayer in theory can connect to any of the popular DA solutions in existence today, but currently, there are not much datils about this.

AltLayer has two core products, Flash Layers (rollup with a set expiration date), and Pessimistic Chains (chains that don’t have an expiration date).

Although it may not seem obvious right away, there are several use cases for disposable chains, mainly in the gaming and NFT sector. Here are some examples:

• Mini-games: As we saw with Yuga Labs’ launch of the Dookey Dash game, some teams can benefit from launching their own short-lived, congestion-free rollup.

• Indie Games: Traditionally, these types of games are known for only lasting for a short period of time, before the popularity ultimately dies down and players move on to the next game. This makes indie games a good fit for short-lived chains as well.

• NFT mints: Popular NFT mints seem to always clog up the Ethereum chain, leading to increased gas and low latency. To avoid this scenario, teams could launch their mint on their own dedicated rollup.

Dymension

Dymension is building an enshrined rollup ecosystem. To be more specific, Dymension is a Tendermint Proof of Stake (PoS) chain built using the Cosmos stack. This proof of stake chain serves as the settlement hub for the entire Dymension ecosystem, providing all connected rollups with security, liquidity, and interconnectivity.

Enshrinement offers rollups the same trust and security assumptions as the base layer, yet with a simpler, safer, and more efficient design space.

Dymension also provides a simple-to-use framework that enables developers to build and deploy their own application-specific rollup. Unlike the previous solutions we have looked at so far, which focus more on the EVM world, Dymension is more focused on “vertically scaling Cosmos”, by providing the L2 “dimension” for the ecosystem.

• Execution Layer

As of today, Dymension offers two VM options for developers, CosmWasm, or the EVM. Dymension enables the use of the EVM (thanks to a partnership with Evmos) for their execution environment, meaning that Solidity developers can deploy their dapps using the Ethereum tools they’re most familiar with, while still being able to take advantage of IBC connectivity.

• Settlement Layer

As mentioned earlier, Dymension serves as the settlement hub for the entire ecosystem, as opposed to the previous solutions we have looked at, which offer settlement through an existing L1 base chain, such as Ethereum or Polygon.

• DA Layer

As of today, Dymension offers the ability to use Celestia as the DA solution. However, like the rest of the solutions we've looked at today, we should be expecting the addition of other DA solutions to the “RollApp” stack over time, such as Eigen DA, which was one of the DA solutions mentioned by the Dymension founder in a previous interview.

Although enshrined rollup may lack flexibility and sovereignty, there are still some advantages for the Dymension hub.

1. Shared Security. The Dymension hub provides a shared security mechanism, whereby the more RollApps that deploy on top of Dymension over time, the stronger the security gets.

   In order to deploy your own RollApp, you need to bond DYM tokens to the network validators. These DYM are staked on the Dymension hub. In order for a malicious actor to take control of the Dymension chain, they must hold ⅔ of the entire staked DYM. So, the more rollups that deploy on top of Dymension, the more staked DYM, and the more staked DYM there are, the more money you need to control the network, ultimately leading to increased security.

2. Inter-connectivity. One of the core components within the Dymension ecosystem is the Inter Rollup Communication protocol (IRC), which is the ecosystem’s own native version of IBC. Essentially, it’s IBC tweaked specifically for rollups. IRC uses the Dymension hub as the common ground for rollups, enabling seamless rollup<>rollup bridging and ultimately providing us with a similar user experience to that of Cosmos. And since the hub is IBC-enabled itself, the RollApps are able to communicate with the rest of the IBC world, opening up the door for interoperability with other IBC-enabled App-chains such as Osmosis, Juno, etc.

Eclipse

Similar to the previous solution we looked at, Eclipse provides both a rollup framework, as well as a settlement layer. What separates Eclipse from everyone else, however, is its focus on Solana VM-powered rollups.

To be more specific, Eclipse is itself a sovereign rollup built on top of Celestia, and built using the Solana VM (Sealevel). One of the features from the SVM that Solana developers like the most, is the use of “parallelism”, which is essentially how Solana dapps reach such a high throughput.

• Execution Layer

Each rollup deployer can choose his/her preferred VM, which as of today, these options include SVM or EVM.

• Settlement Layer

Eclipse itself serves as the universal settlement layer for its ecosystem, meaning every rollup that deploys on top of Eclipse, settles on that chain. As of today, Eclipse offers optimistic settlements (fraud proofs), and they’re currently working on adding zk-settlement thanks to a current collaboration they have with RISC-Zero.

• DA layer

Regarding DA providers, Eclipse allows its rollup deployers to choose between Celestia, Eigen DA, or Polygon Avail. Plus, the team has already stated on their docs that they will add Ethereum DA in the future.

The Experience of Spinning off a New Rollup

A UX-friendly RaaS should have the following features:

• Some certain levels of chain customization (e.g., the whitelist of addresses to interact with the chain, its own gas token, etc. )

• UX-friendly facing features(e.g., bridge interface, block explorer, etc.)

• Well-integrated developer tools. (e.g., graph indexing tools, oracles, block-level API, etc)

By design, the current RaaS project can provide all three aspects. The real problem is to what extent these features have been achieved, and how stable and quickly these features would be deployed.

Both Altlayer and Caldera have opened up their test programs for developers to create rollups. A comparison between the two is provided below:

Currently, developers on Altlayer can customize the transaction sequencing mechanism; the name of the Flash Layer; native currency name, symbol & decimal; and Genesis account and balance. However, Caldera only allows the developer to customize their gas token on the mainnet.

Currently, there is not a huge difference between the developer tools provided by Altlayer and Caldera. However, Altlayer is currently not allowed to switch to another settlement layer, while Caldera provides three options: Ethereum, Polygon, and its own testnet. Although there is only one sequencing model for Caldera, Altlayer provides an FCFS model to decrease the impact of gas wars.

A flash layer may be a great place for scams since they can disappear after a limited time. To better protect users and help build confidence, AltLayer may need to implement monitoring or risk management functions during the bootstrapping process.

It is interesting to consider that RaaS projects can choose to work with a web2 hosting platform (such as Netlify), which would enable web2 users to create their app on their rollups without changing the UX, and ultimately have a unified development experience. This could potentially enable a larger number of developers and innovations to enter the crypto world.

5. What about the Unified Sequencer Network?

Currently, most rollups on Ethereum rely on centralized sequencers to achieve high performance, low latency, and immediate finality for users who trust the service. However, there is a need to decentralize the sequencer network to lower the impact of MEV on users and to avoid a single point of failure for rollup liveness.

The Unified Sequencer Network involved many participants, each aiming to provide their own sequencer set with a new and efficient consensus mechanism (for example, Espresso and Astria). Flashbot’s SUAVE aims to provide a marketplace for MEV searchers, executors, and builders/sequencers on different chains. Meanwhile, Saga aims to leverage its validator set to provide sequencing services for rollups.

Here, we will not delve into the details of each project but rather have a discussion from the perspective of the App-chain history.

The App-rollup SDK is similar to the App-chain SDK, while a unified sequencer network is akin to a shared validator set.

It is interesting to note that some of the projects in the App-chain world that provide shared decentralized validator sets, such as Blockless and Hamster, are experiencing more difficulties than those which initially focused on the SDK.

The main reason for this difference may be that the market does not prioritize the security or decentralization of the blockchain. Instead, it values the ability to fulfill the business model and the convenience of launching a chain, even if the nodes are not initially decentralized. An example of this is Optimism, which has not yet implemented fraud-proof measures and whose sequencer is still controlled by itself.

Will history repeat itself with the Unified Sequencer Network, especially for projects that focus specifically on the consensus of the sequencer network, like Espresso and Astria? Let’s wait and see.

Conclusion

The RollApp ecosystem is expected to experience significant growth in the coming years. Despite this fact, there are many potential problems to be solved still, such as centralization, security, bridging, and liquidity fragmentation. Rollups and modular construction are crucial for blockchain scalability. As technology advances, rollups will simplify the lives of Web3 builders and users by providing a customized UI, reducing operational expenses, and expanding the design space for native token economies.