# Thesis Old ### Thesis At its core, 99% of Web3 activity revolves around transferring value, whether between parties or across assets. There 300+ active chains, and the overall web3 ecosystem is fragmented and liquidity is stuck in silos. Even Web3 OGs have to figure out a lot of things using a dApp on a new chain. A typical user manages 100s of tokens across 10s of chains not to mention Gas tokens for each chain. Launching a dApp on a specific blockchain and attracting users from other chains is quite challenging for developers. Several protocols aim to address these issues, achieving limited success so far. The aim is to solve for the current 300 chains right now, but with the rapid expansion of Layer 2s, Layer 3s, app chains launching, everyone is playing catchup. We envision that in the future we'll have a million chains. As today we think of a chain as a really big, architectural, giant, monolithic thing. But in the future, chains may be similar to how we have billions of websites right now. On chains, we will have specific requirements based on specific infrastructures. We may use different index packs. All different requirements. So that's how we envision it. So someone has to solve the liquidity fragmentation issues. We may in the future have a standard protocol like we had in Layer 2 to replicate across websites. Or we'll have standards like TCPIP and DNS and all of that. But that is far off in Layer 3 right now. So we believe that this is the moment to actually build a liquidity layer which can enable liquidity movements seamlessly across millions of chains in Web 3 in the near future. So, the way we can do it... The first problem is, there are a lot of protocols or solutions trying to solve the GPT fragmentation issue. But let's say we bring an innovative solution. We don't get enough traction or discovery because the average user or app is not aware about the unique solution. When this unique solution comes in, there is another unique solution which is coming up for cross-chain liquidity or liquidity on the same day itself. And there are hundreds of new protocols and solutions coming up. This creates, again, more fragmentation in terms of just the solution itself. So, even if someone actually solves this issue, it would be very long before they become the standard across... and able to use them. Because there are so many different types of even solutions. So, the important part is for us to bring them together. For a developer or a user to be able to find these and interact with them and gain the benefit, it helps the performance, speed, or cost. So, that is the aggregating part. The other side of this point is, these protocols, because there are so many, for them to actually gain any traction, they need order flow. And that is very difficult to gain in the current landscape with so many solutions. So, our aim with the first part of building Compass is to capture the order flow directly from the tabs. And by aggregating all of the new, unique, old, all of the liquidity solutions, and giving the best output to the user. So, the user gets the best output, the latest innovations in liquidity, and is able to seamlessly transfer value or transfer assets across chains and use their protocols on any chain and token. The protocols, in turn, get order flow directly from the source, because all liquidity in that queue is technically to use a decentralized application. And this activity does not happen on the tab right now. So, we capture the order flow directly from the tab by integrating Compass directly with the tabs, and we enable discoverability for the protocol itself. So, in the end, it's a win-win for the users, the protocols, and for us, because we actually got the flow directly. So, then we become the single source of a good amount of order flow, and a massive amount of liquidity. Now after aggregating liquidity and maintaining the order flow, the problem is all of these different protocols are running, all of them are limited by their own innovation and stack, support of chain, and all of that. It's difficult for them to work together. So then comes a layer of execution, where Comcast Pathfinder handles the execution, works with all of these different protocols, merges them, finds the best routes, figures out efficient ways to execute the user's intent, in some sense, of giving one token and getting another token on a chain and actually execute an action, depending on the use case of, let's say, buying an NFT or putting money into a liquidity pool or anything else. So this is the execution part, where Comcast Pathfinder handles the execution, makes it streamlined, makes it efficient. Because even if you aggregate all of the solution, and if you give it to the user or the developer, they still have a lot to decide and execute and do. That also creates one more layer of complexity. So to reduce or remove, eliminate all of that, Comcast Pathfinder handles the execution. So your stack is aggregation, distribution, in some sense, for the protocols, for the end-to-end order flow, and then for the end-to-end stack, execution. So all of this is part of Compass. Now in terms of, even if you have all of the existing protocols and liquidity aggregated, even if you are able to execute, find the best option, mix and match all of these puzzles, handle them to an execution, even then, you won't be able to support even the Lite, the active pre-embedding right now, because simply all of these protocols are limited in terms of scalability, high amount of infrastructure overhead, and a lot of different issues and different tech requirements on top of that. So then comes the requirement of building a comprehensive liquidity layer, which can take in all of these different liquidity avenues and enable them to interact across chains and seamlessly hold money from any source to any destination. And the main part of this is because all of the existing protocols are not even able to scale between other chains. There is literally not a single protocol or solution which works across all chains. So either they work across 10 chains, 15, 20, 50, maximum 100, and apart from that, if there are 300 chains, they won't be able to work. Even if, let's say, a particular solution is working, supports 100 chains, they will not support liquidity for more than top 3, 4, 5, or 10 assets on the chain. They won't be able to support all the liquidity across all these chains. So that's where Lex protocol comes in. Lex builds upon the growth of intent-based bridges and protocols and improves it further for scalability. The main objective of Lex is to improve the intent-based mechanisms and make them scalable. The current intent-based mechanisms have solved the user experience issue. And are able to get the user a specific asset for whatever their intent is, fulfilled by pushing it on to third parties who execute this on their own. The problem with this is the overall, the thought and the logic is good, and the problem is with the overall infrastructure requirements. Intent-based widgets work because they fulfill the user's intent regardless of the underlying entity, provider, or liquidity, whoever that is, and get this done. But the problem lies wherein, once the user's intent is fulfilled, the liquidity provider or the solver who may be involved, they have to go through a learning process which is infrastructure-ready, costly after multiple transactions, and time consuming because they have to prove to the protocol that they fulfilled the user's intent. There are validators who verify the request for fulfillment, then there is a settlement process which takes a lot of time, sometimes a few days, sometimes a few hours, and that makes the guaranteed intent protocols inefficient. So the next protocol improves the intent-based engines and removes all the unnecessary complexities and infrastructure requirements and fulfilling a single goal of enabling users to access liquidity on any new chain, solvers for them to be able to solve liquidity regardless of the architecture or smart contract by the protocol and for validators to efficiently and at speed and low cost verify all of these transactions across any chain, regardless of whether the chain is linear, non-linear, modular, or whatever in the near future. So by overall, if you consider the stack, it solves for aggregation, distribution, order flow, execution, and settlement. By adding all of this together, you combine all of this stack and then comes the full end-to-end life cycle of liquidity moving across chains for the future of enabling chains. #### #### Rethinking Web3 From First Principles **Users** \ Most user interactions with a dApp involve a transfer of value.. Does a user care what consensus mechanism or VM the dApp is deployed on? No. **Developers** \ When building dApps, developers choose blockchains that best fit their technical needs - for speed, cost, or innovation. Should these technical decisions become a barrier for potential users holding assets on other chains? No. **Intermediaries** \ Intermediaries bridge one gap: matching asset conversion needs with the best available liquidity source. If the conversion is fast, secure, and maximised, does it require complex infrastructure? No. ### *By going back to basics, BlockEnd addresses Web3’s core need: seamless value transfer.* --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.blockend.com/about-blockend/thesis-old.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.