In web3, building fully onchain applications is the gold standard. Yet, many onchain projects rely on centralized components at one point or another. For permissioned applications, this often means access is managed through offchain systems. A common example is the use of Merkle trees, where the Merkle root is published onchain, while the rest of the tree and its leaves (proofs) resides offchain.

While Merkle trees offer a clever solution that maintains a degree of trustlessness, there are key limitations. One drawback is the reliance on offchain storage. For some, this defeats the purpose of building onchain, where transparency is critical.

Beyond the offchain issue, Merkle trees themselves are static structures. They excel when verifying data in a fixed list, but if your access control system needs to change dynamically—whether you’re adding new users or adjusting permissions—the inefficiencies of Merkle trees become evident. Each modification requires you to:

1. Recalculate the entire Merkle root (state): Anytime you update your list (e.g., adding or removing a wallet), you need to rebuild the entire tree from scratch and calculate a new state.

2. Store and distribute Merkle leaves (proofs): You must store the leaves somewhere offchain. Whether you opt to store the leaves on IPFS or a centralized server, this step introduces friction to the verification process and brings your data offchain.

3. Republish the updated Merkle root onchain: After recalculating the new Merkle root, you must post it onchain.

4. Configure the root onchain: Once the new root is published, you need to update any associated onchain configurations. This includes URI pointers, event start and end time, and other data. Many apps do this in a separate transaction, introducing additional costs and friction.

In addition to extra costs, this process introduces delays. For example, to add a new wallet to an access list, you must recalculate the new Merkle root, publish it onchain, and then configure additional parameters. The time and financial costs of these operations can add up quickly, especially for high-volume applications.

In some cases, this three-step process (recalculating, publishing the data offchain, and configuring the root onchain) costs up to $3.65 in network fees. Multiply that by hundreds or thousands of updates for apps with dynamic permissions, and you're looking at significant overhead. Not to mention, on busy days, Ethereum transactions can take up to 11 minutes—an eternity in today’s climate, where users expect instant access.

Quible offers a novel solution to these challenges through its key feature: Quirkle trees. Unlike static Merkle trees, Quirkle trees are designed for dynamic access control, allowing teams to go fully onchain without the compromises of traditional methods.

Here’s why Quirkle trees are superior for onchain projects:

• Root Persistence: With Quirkle trees, you only need to publish your root once on your chosen chain. From there, any subsequent changes to your access control lists can be made incrementally. No need to recalculate or republish your root every time you update your list. This saves both time and money.

• Incremental Updates: Need to add or remove a wallet from your access list? No problem. With Quible, you can make updates one at a time, without having to reconstruct or republish an entire tree. This makes Quirkle trees ideal for applications that require frequent, real-time changes to their access control systems.

• Cost Efficiency: By eliminating additional transactions to update access lists, Quible helps you cuts down on network fees. Instead of performing multiple transactions to update and configure a Merkle tree on your home chain, let the Quible Network do the heavy lifting by also replacing the costs involved in depending on offchain components.

• Reduced Onboarding Delays: Quible eliminates the need to continuously recalculate and republish Merkle roots, removing a common bottleneck for onboarding. Offering instant access to new users gives your application a significant edge over competitors.

As onchain applications evolve, so too must the infrastructure that supports them. Projects that rely on centralized offchain components are forced to compromise on the very principles of transparency and decentralization that are core to Web3. With Quible, you can take your project fully onchain—without the delays, costs, or inefficiencies of Merkle tree-based access control.

Ready to go fully onchain? Start building with Quible today!

Website: https://quible.network
Whitepaper: https://quible.network/whitepaper
Twitter: https://twitter.com/QuibleNetwork