# How XCM will actually be used with XCMP **URL:** \ **Category:** Tech Talk\ **Tags:** xcm\ **Created:** [August 27, 2022, 4:04pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190 "2022-08-27T16:04:22Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![shawntabrizi](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/shawntabrizi/32/14_2.png) [@shawntabrizi](https://forum.polkadot.network/u/shawntabrizi)\ **Post date:** [August 27, 2022, 4:04pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/1 "2022-08-27T16:04:22Z")
> **NOTE:** This was a thread which took place in the internal Parity Forum on July 12, 2022, and would like to now migrate to this public forum now that it exists. I will try to copy and paste relevant parts of the conversation, and would love for us to continue the conversation here. In a conversation here at the Polkadot Blockchain Academy in Cambridge it became more clear to me how to describe how XCMP / Polkadot can be used effectively versus some of the misunderstandings other have about it in our ecosystem. I am of course not an expert on all things here, so maybe some of this is wrong, would love to hear from experts like @rob and @gav Polkadot’s bet is quite simple: - Scale by parallelizing transactions to multiple blockchains. (sharding) - Scale by having those multiple blockchains be specialized and optimized for a particular use case. (heterogeneous) However, these choices also come at costs: - Technical overhead and complexity of building these systems safely and securely. Mostly on Polkadot protocol development side, presumably why something like this takes 5+ years to develop, and many more to come. Something we can overcome. - Sending messages across blockchain shards is slow. Like WAY slower than you can expect for any “cross contract” communication that people have become use to with defi and all that. Something which I argue cannot be solved. It seems to me that people want to duplicate multi-contract scenarios with parachains, but if we do this, Polkadot will look bad, because Polkadot (or anyone else) simply cannot do this. It is literally beyond what physics allows. Polkadot instead makes the bet that a user will not actually move assets across Parachains that much, and when they do, the advantages of a specialized chain will be worth it. Let’s imagine two dapps: a DEX and and a privacy layer like Tornado cash. Let’s assume a DEX contract on Ethereum can perform a swap in .2 seconds. While a dedicated DEX parachain can perform a swap in .1 seconds. Let’s assume a tornado cash contract can perform a privacy operation in 1 second. While a dedicated privacy parachain can perform the same operation in .5 seconds. > NOTE: I think this is a vast underestimate. I think there is evidence that parachains are hundreds or thousands of times faster than their contract counterparts. Now let’s assume that on Ethereum, moving a dex swap token into a privacy layer is basically 0 overhead. While on Polkadot, we should expect at least 12 seconds for an XCMP transfer between the two parachains. This means, if we are trying to highlight scenarios where a user can quickly transfer some token to a dex, swap some token, then move it to a privacy layer to hide their trades, and then back to some final account, we will be so far behind Ethereum it is not even reasonable. Instead, the scenario which highlights Polkadot’s advantage is when you are doing 10,000 dex swaps, then a single transfer to a privacy layer to hide all those operations. Here, you would actually save much more time, because each of those dex operations have been optimized on a dedicated blockchain, and the overhead of XCMP is shadowed by all of the time (and fees) saved by doing it in a more optimized environment. What does this imply about how users and products will be built on Polkadot? Well, Parachains won’t actually be THAT focused, at least, they will all likely provide “good enough” solutions to common operations like DEX (if they manage multiple tokens), smart contracts to a certain extent (for extending funtionality on their chain), etc… These parachains will have these applications as secondary features compared to their main product. And they can achieve these features quite simply thanks to Substrate and our modular pallet system. Adding a dex to any parachain will be as simple as adding a new pallet to their runtime. However, this does not mean the death of DEX parachains, since we all know that systems like a DEX are optimized where there is high liquidity, lots of different available assets, and only a dedicated DEX chain will be able to provide that as a primary feature. If you are doing a small conversion for some scenario, probably you don’t mind too much about a super optimized dex trade, but if you are doing big trades, probably you will want to eat the time cost of transferring the asset to an appropriately competitive DEX parachain. Same with contract parachains. This also implies that users will probably end up having a “usable” amount of assets on each chain they care about. It will not be a normal scenario that a user wants to perform one action on a parachain, so they start with their tokens on DOT, initiate a transfer with “just enough”, and perform that one operation. Instead, they will probably predict how much they will use another parachain over a long period of time, transfer enough assets to that chain to handle all of those operations (and more), and just manage that balance on the other parachain. This means we probably should be directing teams to build less UIs which execute operations across multiple parachains, and instead focus on dedicated UIs for all the operations on a single parachain, and a really amazing UI for managing your assets across multiple chains, and making that one time transfer. Does this mean that all of the programmability of XCM is useless? No, since XCM is also targeting contracts where all of these cross contract calls are free (our initial assumption), but likely XCMP and cross parachain programmability will be minimal, since the amount of “actions” you can take on either side of the XCMP operation won’t be that large, and thus does not really outweigh the large overhead of the transfer itself. There are probably a lot more that we can derive about behaviors and what will actually be successful on Polkadot if we continue to think down this path. Is there anything here which I am getting wrong? Are there any bets we are making which would change if this is right? ---
**Author:** ![shawntabrizi](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/shawntabrizi/32/14_2.png) [@shawntabrizi](https://forum.polkadot.network/u/shawntabrizi)\ **Post date:** [August 27, 2022, 4:05pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/2 "2022-08-27T16:05:31Z")
Here is a collection of responses from the thread: 1. Gav 2. @santi 3. @natalie 4. @shawntabrizi 5. Travis Kassab NOTE: some comments skipped here… 1. Gav 2. Gav * * * There are a few more posts after this, but will let the conversation restart here. ---
**Author:** ![kckyeung](https://avatars.discourse-cdn.com/v4/letter/k/e8c25b/32.png) [@kckyeung](https://forum.polkadot.network/u/kckyeung)\ **Post date:** [August 27, 2022, 6:08pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/3 "2022-08-27T18:08:14Z")
Reposting from Internal Parity Forum: > [@shawntabrizi](#): > > Now let’s assume that on Ethereum, moving a dex swap token into a privacy layer is basically 0 overhead. > While on Polkadot, we should expect at least 12 seconds for an XCMP transfer between the two parachains. > > This means, if we are trying to highlight scenarios where a user can quickly transfer some token to a dex, swap some token, then move it to a privacy layer to hide their trades, and then back to some final account, we will be so far behind Ethereum it is not even reasonable. > [@shawntabrizi](#): > > Well, Parachains won’t actually be THAT focused, at least, they will all likely provide “good enough” solutions to common operations like DEX (if they manage multiple tokens), smart contracts to a certain extent (for extending funtionality on their chain), etc… I feel like such a conclusion is narrowly focused on the use case of DeFi or DEXes. It’s normal for these businesses to be time-sensitive, but for other kinds of usages where waiting for execution isn’t really a big deal such as identity verification (like Kilt or Litentry), then I don’t really see why they can’t continue to focus on being a parachain that focuses on a single use-case. I don’t foresee them ever adding an on-chain DEX, if that’s what the implications are from this thread. But I do see the need for other DeFi or DEX chains adding on an on-chain identity verification pallet, should they want to verify the identity of the origin for every transaction they make. It would be too costly in terms of time to use XCM and communicate with an DID parachain to get an individual verified for each tx. This would sound to me that for applications that are time-critical, they’ll really be deploying their own versions of various services on their own chain, and if this is the direction that we’re heading towards, then it would make sense to encourage non-time-critical applications to provide a pallet-as-a-service to time-critical parachains. ---
**Author:** ![sam](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/sam/32/54_2.png) [@sam](https://forum.polkadot.network/u/sam)\ **Post date:** [August 29, 2022, 11:22am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/4 "2022-08-29T11:22:27Z")
> [@shawntabrizi](#): > > This means, if we are trying to highlight scenarios where a user can quickly transfer some token to a dex, swap some token, then move it to a privacy layer to hide their trades, and then back to some final account, we will be so far behind Ethereum it is not even reasonable. > [@kckyeung](#): > > I feel like such a conclusion is narrowly focused on the use case of DeFi or DEXes The above two quotes really stood out for me. There has been discussion among some of the polkadot communities I am a part of that we are at risk of trying to make polkadot do what Ethereum does. Given that is where the majority of traffic is I understand the decision but as @shawntabrizi highlighted above, Polkadot can’t and should not compete there. Those same users are arguably not our key demographic given how they use it. The key selling point of Polkadot for us was interoperability, XCM is core to that. However, what needs to be highlighted is how it is currently being used as a token transfer mechanism which while works is really just a low-hanging fruit IMHO, The true value of XCM is in the communication between chains, that communication is what drives the innovation. Similar to how the smartphone boom happened, now your phone could be much more than a phone. It had apps, maps, and social media to name but a few. All made possible because your phone can communicate with other services. We need to look at that as the next frontier to drive the industries that Gav mentioned above Also, I agree that `Transact` could do that, we have done it before where we had the same pallet in 2 chains and used `Transact` to call functions in other chains but that was a rudimentary hack to work around the fact that XCM was one way and did not provide a response. That said, I think Transact will need to be worked on a bit to make it more intuitive for a blockchain developer. Documentation and education will also help. Make devs realise it’s potential I also agree there are a lot of teams waiting for Parity to define what “good” looks like, how they communicate or a best practice. I would go as far as to say Parity themselves do not know, how could they when it has not been done before? Honestly, I think it is unreasonable to expect them to define it either given each chain is focused on it’s own business use case My question is why not focus on communication, abstract away “how” chains communicate and just build demos and proof of concepts on what could be done with the communication? show the end user where the true value is even if we simulate the communication while we get more devs to understand how to utilise `Transact`? We don’t need Parity to do this. We - the builders - can. This gives us invaluable feedback as to how people will want to utilise this communication as well as give us an idea to what an ideal set-up should look like and give Parity ideas on how to improve on `Transact` I would also be remiss to say that we need to move away from the DEFI narrative and think about who our target users are. If we are to push for that next wave of adoption of users then I am not certain DEFI is what they want to use on a day-to-day bases. DEFI should be a means to an end, not an end itself. In summary, the post questions how XCM will be used with XCMP? I would go further and ask how can the value of communication between chains be demonstrated conclusively. Not in theory but also in practice ---
**Author:** ![girazoki](https://avatars.discourse-cdn.com/v4/letter/g/c4cdca/32.png) [@girazoki](https://forum.polkadot.network/u/girazoki)\ **Post date:** [August 31, 2022, 8:43am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/5 "2022-08-31T08:43:45Z")
> [@shawntabrizi](#): > > Instead, the scenario which highlights Polkadot’s advantage is when you are doing 10,000 dex swaps, then a single transfer to a privacy layer to hide all those operations. Here, you would actually save much more time, because each of those dex operations have been optimized on a dedicated blockchain, and the overhead of XCMP is shadowed by all of the time (and fees) saved by doing it in a more optimized environment. I fully agree with the point made here. And I also think, like it has been said in the thread, that the more specialized a chain is on some task the more users will be willing to wait. > [@shawntabrizi](#): > > This also implies that users will probably end up having a “usable” amount of assets on each chain they care about. It will not be a normal scenario that a user wants to perform one action on a parachain, so they start with their tokens on DOT, initiate a transfer with “just enough”, and perform that one operation. Instead, they will probably predict how much they will use another parachain over a long period of time, transfer enough assets to that chain to handle all of those operations (and more), and just manage that balance on the other parachain. I think this is key. I dont think it would be very smart to transfer just enough everytime we want to take perform an action on a different chain. This makes even less sense when we think about how users will be able to do cross-chain interactions. We are starting to experiment with the scenario in which the parachain A allows an account on parachain A to control one and only one specific account on parachain B (through the DescendOrigin instruction + an address defrivation). In this scenario, this derived account on parachain B is sort of an extension (only xcm-controllable) of the account on parachain A, something that the user will use everytime it has to interact with parachain B. Thus, it is completely logical to fund this address for operations that will be performed over a large period of time. The same thing applies with other use-cases. If we have a cross-chain liquid-staking scenario, it is more efficient to just stake once every session than everytime that the SC receives liquidity. We have a use-case around this (Lido with DOT), and this is the approach taken. However, how do we deter the usage of cross-chain messages that go against this philosophy? This might organically happen because of two reasons: - Fees: Sending cross-chain messages incurs on higher fees, therefore one would expect that the use-cases that arise take this into account. - Byte/Weight limit: At least in the case of the Polkadot ecosystem, a cross-chain interaction is capped by size (defined by the HRMP channel config) and weight (defined by the target parachain). The more cross-chain actions taken, the more difficult it will be to fight for this space and the more a user/SC will have to wait for its cross-chain action to complete. Because of these two reasons I think usecases will organically adapt to the philosophy of “just perform a cross-chain action when you trully need it”. ---
**Author:** ![crystalin](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/crystalin/32/343_2.png) [@crystalin](https://forum.polkadot.network/u/crystalin)\ **Post date:** [August 31, 2022, 9:07am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/6 "2022-08-31T09:07:57Z")
I agree with this. I wrote it before in [[Discussion/Idea] Domain/Pallet specific XCM language · Issue #30 · paritytech/xcm-format · GitHub](https://github.com/paritytech/xcm-format/issues/30) (for different reasons), that we are not in a spot right now where we can define XCM properly. I believe there will be more to XCM but we also have to be realistic. Until there is a technological breakthrough, the majority of activity will be around Token/NFT transfers. New scenarios are coming but those are very limited (by the nature of blockchains) Interacting from a blockchain with the real world (which is what people want to at the end, specially if we want to do something else than Defi) requires to either trust the interaction (like our current society works) or use a physically/mathematically proven interaction (which we don’t have invented yet). Leaning into the “trust” scenario can work (Ex: people trust tokens have real $ value) and might help to bring some new scenarios, but it is also not the direction of the promises of the blockchain technology. Working on XCM and cross-chain in general is about preparing the base/platform for that evolution, but we don’t know what it will look like, so I believe XCM can’t be designed for it now. However, we should still consider XCM, to help the ecosystem pave the road and learn from the challenges associated with cross-chain, in order maybe to evolve to another version or another language that will match the real scenarios we will have. My 2 cents, Alan ---
**Author:** ![hoonkim](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/hoonkim/32/998_2.png) [@hoonkim](https://forum.polkadot.network/u/hoonkim)\ **Post date:** [August 31, 2022, 1:42pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/7 "2022-08-31T13:42:19Z")
I think this is a very interesting thread. I wrote an article a while back regarding how XCMP could be used for parachains in the future. You can check it out [here](https://medium.com/astar-network/the-astar-vision-part-3-the-innovation-hub-of-web3-0-1cace547aba3). In this article, some examples I theorized might not be feasible, but overall, I think it still stands for most cases. Especially the limitations and considerations section. Overall, I agree with the point that if the end value is greater than the added overhead that is involved with XCMP, then this should not be a problem. I see that thinking in the way of ‘industry-specific’ blockchains is more realistic than ‘application-specific’ blockchains for XCMP use cases. So during the early phase of XCMP dApps, I imagine that most blockchains will be some sort of asset repositories but focused on assets for games, real-life assets, bridged assets, tokenized entities, automation parachains, etc. XCMP will revolve around mixing and matching these aspects with each other. This alone could be quite big. However, I personally do not think this is a long-term application that we are looking for in a truly interoperable Web3 world for mainly the fact that industry-specific blockchains have to do more with marketing than features. You can use the same smart contract platform and claim it’s for gaming or real-life assets, and it will still work well if your initial users are the right target. Of course, you can add custom features that help adoption in certain industries, but this isn’t selling a ‘feature’ as it’s more selling your ecosystem (which is all blockchains in a nutshell IMO). From my observations, public blockchains heavily rely on network effect and existing ecosystem, rather than new features (just look at Ethereum). Even if the value proposition and features of a blockchain is superior, if they don’t have a vast ecosystem with a lot of liquidity, most new projects won’t jump into the new blockchain. And considering that there are only a handful of industries right now that justifies a blockchain, I can easily imagine a future where only a handful of successful industry-specific blockchains have monopoly on the industry they target. Another case would be where parachains are relying on only a single parachain for specific assets or features, making a security dependency. Now having said that, this is part of the game, and I don’t think changing how XCMP works will fix anything. It’s more in the fact that the blockchain space is quite early, we don’t have a lot of use cases. I would go far as to say that we haven’t seen any major problems that interoperability solves (since we don’t have enough cases in general). I guess what I want to say is, we have a great protocol, but we also agree that trying to recreate the same thing that is available on a layer 1 blockchain, but spread out into multiple blockchains via XCMP is not reasonable. So this might be a good opportunity to think about what interoperability means, and what problems each parachains are trying to solve. I see XCMP as a way to unify ecosystems, not solutions. I’m open for discussions, I can’t say my view is entirely correct here 🙂 ---
**Author:** ![matt](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/matt/32/2040_2.png) [@matt](https://forum.polkadot.network/u/matt)\ **Post date:** [September 13, 2022, 3:00pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/8 "2022-09-13T15:00:36Z")
> [@girazoki](#): > > However, how do we deter the usage of cross-chain messages that go against this philosophy? I urge you to reconsider - XCM is what brings many of us to the Polkadot ecosystem. Deterring usage of XCM would deter users and developers from joining and building in Polkadot. > [@hoonkim](#): > > I would go far as to say that we haven’t seen any major problems that interoperability solves (since we don’t have enough cases in general). > [@shawntabrizi](#): > > Polkadot’s bet is quite simple: > > - Scale by having those multiple blockchains be specialized and optimized for a particular use case. (heterogeneous)." As Shawn highlighted, the main problem that interoperability solves is scalability. Interoperability (and thereby XCM) enables vertical scaling by removing the need for every chain to support every use case. We’ve seen this work time and time again in software development and with Web N+1. > [@sam](#): > > The key selling point of Polkadot for us was interoperability, XCM is core to that. However, what needs to be highlighted is how it is currently being used as a token transfer mechanism which while works is really just a low-hanging fruit > [@gavofyork (via shawn)](#): > > You can think of XCM, at its very basic level, as allowing one blockchain system to post a transaction to another blockchain system. Gavin seemingly agrees with Sam (as do I) on XCM being much more important than simply bridging tokens. Aligning on a solution to post transactions to another chain using XCM is undoubtedly imperative to the continued growth and long-term success of the Polkadot ecosystem. Given Gavin’s stated opinion that no clean solution exists to provide a generalized “custom proxy” solution [1], my conclusion is to agree with Sam - each parachain team must accept responsibility for their own proxy permissions. > [@sam](#): > > We don’t need Parity to do this. We - the builders - can. [1] [Adding Proxy Call Filters to other Time Delay Proxy Types · Issue #1823 · paritytech/polkadot · GitHub](https://github.com/paritytech/polkadot/issues/1823#issuecomment-734916373) ---
**Author:** ![girazoki](https://avatars.discourse-cdn.com/v4/letter/g/c4cdca/32.png) [@girazoki](https://forum.polkadot.network/u/girazoki)\ **Post date:** [September 13, 2022, 3:27pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/9 "2022-09-13T15:27:49Z")
> [@matt](#): > > I urge you to reconsider - XCM is what brings many of us to the Polkadot ecosystem. Deterring usage of XCM would deter users and developers from joining and building in Polkadot This was more of a rhetorical question. There is a much more important conclusion I throw at the end: > Because of these two reasons I think usecases will organically adapt to the philosophy of “just perform a cross-chain action when you trully need it”. ---
**Author:** ![brad.olson.587](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/brad.olson.587/32/246_2.png) [@brad.olson.587](https://forum.polkadot.network/u/brad.olson.587)\ **Post date:** [October 17, 2022, 6:26pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/10 "2022-10-17T18:26:19Z")
> [@shawntabrizi](#): > > It seems to me that people want to duplicate multi-contract scenarios with parachains, but if we do this, Polkadot will look bad, because Polkadot (or anyone else) simply cannot do this. It is literally beyond what physics allows. @shawntabrizi Here it’s worth looking into the latency solutions used by the traditional financial system and perhaps adapting them to our purposes. I agree that we run into physics constraints when low latency absolute finality is desired, but there’s still room to reduce latency if we substitute insured finality for absolute. I envision a smart contract layer that mathematically models the risk of a particular asset transfer or cross chain procedure call. The contract then adds a small fee to the transaction in return for guaranteeing its successful completion. This could be combined with batching of transactions where relevant to make things even more efficient. Which limitations of xcmp latency could such a system help with? Intuitively it seems to me that asset transfers would be well served by such a system, while procedure calls might be much tougher to insure. ---
**Author:** ![rphmeier](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/rphmeier/32/126_2.png) [@rphmeier](https://forum.polkadot.network/u/rphmeier)\ **Post date:** [October 17, 2022, 6:43pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/11 "2022-10-17T18:43:15Z")
When it comes to latency, we are to some extent bounded by the blockchain scaling trilemma: of security, throughput, and latency you cannot choose all 3. There are certainly ways of bypassing XCM latency via optimistic market methods: i.e. if an XCM routine coordinating many chains might take 30 seconds to complete, it is possible for entities which know that the result will eventually resolve to X to ‘frontrun’ that message and collect a small profit for frontrunning it. The service they provide is to make information or value available before it is confirmed by the consensus system. This is a way for the application layer to selectively trade off security for latency. ---
**Author:** ![brad.olson.587](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/brad.olson.587/32/246_2.png) [@brad.olson.587](https://forum.polkadot.network/u/brad.olson.587)\ **Post date:** [October 17, 2022, 8:51pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/12 "2022-10-17T20:51:33Z")
So the security tradeoff in this case might be as follows? Many instances of frontrunning fail in a tight window of time. This triggers payouts from the frontrunning party to other effected parties which cumulatively bankrupt the frontrunning account, leading to unhandled damages and more importantly unsent messages. ---
**Author:** ![matt](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/matt/32/2040_2.png) [@matt](https://forum.polkadot.network/u/matt)\ **Post date:** [October 19, 2022, 5:37pm UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/13 "2022-10-19T17:37:23Z")
> [@brad.olson.587](#): > > @shawntabrizi Here it’s worth looking into the latency solutions used by the traditional financial system and perhaps adapting them to our purposes. I agree that we run into physics constraints when low latency absolute finality is desired, but there’s still room to reduce latency if we substitute insured finality for absolute. I think about the latency in the traditional financial services system as evidence that instant finality isn’t necessary for many use cases. I’ve frequently heard the argument from banks (in the US) that much of the latency is desired (for fraud prevention). > [@brad.olson.587](#): > > I envision a smart contract layer that mathematically models the risk of a particular asset transfer or cross chain procedure call. The contract then adds a small fee to the transaction in return for guaranteeing its successful completion. This could be combined with batching of transactions where relevant to make things even more efficient. I think this is effectively Visa / Mastercard, who process transactions instantly while waiting for responses from multiple layers of banks. They charge ~3% of most transactions. 😵‍💫 ---
**Author:** ![lurpis](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/lurpis/32/2478_2.png) [@lurpis](https://forum.polkadot.network/u/lurpis)\ **Post date:** [December 1, 2022, 9:35am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/14 "2022-12-01T09:35:36Z")
At present, we are exploring the ability to provide cross-chain liquidity for other parachains based on XCM. By encapsulating the XCM call to Bifrost as a contract SDK, the contract application in the smart contract parachain can complete the remote liquidation of an asset by calling the contract (swap token), obtain the result of XCM asynchronous execution through queues and off-chain workers, and we will gain the trust of the opponent’s parachain through Bifrost Runtime version locking and verification. We don’t think this is the best use case based on XCM, but this is the direction we are trying to go, any issues with the idea are welcome to challenge (let us know, so that the cost of trial and error is reduced) ---
**Author:** ![brad.olson.587](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/brad.olson.587/32/246_2.png) [@brad.olson.587](https://forum.polkadot.network/u/brad.olson.587)\ **Post date:** [December 13, 2022, 8:28am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/15 "2022-12-13T08:28:23Z")
> [@matt](#): > > I think about the latency in the traditional financial services system as evidence that instant finality isn’t necessary for many use cases. I’ve frequently heard the argument from banks (in the US) that much of the latency is desired (for fraud prevention). Good point. Though the existence of even a minority of use cases requiring instant finality would likely be enough to motivate latency workarounds. ---
**Author:** ![brad.olson.587](https://dub1.discourse-cdn.com/flex005/user_avatar/forum.polkadot.network/brad.olson.587/32/246_2.png) [@brad.olson.587](https://forum.polkadot.network/u/brad.olson.587)\ **Post date:** [December 13, 2022, 8:36am UTC](https://forum.polkadot.network/t/how-xcm-will-actually-be-used-with-xcmp/190/16 "2022-12-13T08:36:39Z")
> [@matt](#): > > I think this is effectively Visa / Mastercard, who process transactions instantly while waiting for responses from multiple layers of banks. They charge ~3% of most transactions. 😵‍💫 Two systems can share some implementation details without sharing everything. As far as I can see the ~3% fee has more to do with a payment provider duopoly than the underlying tech. Your thought around the multiple layers of banks is more interesting to me though. I could imagine a state where the failure of one virtual finality system, through draining of a smart contract’s token pool for instance, leads to cascading failures across many such virtual finality systems spanning many chains. That might be such a risk as to motivate us to look elsewhere.