diff --git a/.vitepress/config.mts b/.vitepress/config.mts index 9c1ed562..742de0a3 100644 --- a/.vitepress/config.mts +++ b/.vitepress/config.mts @@ -11,9 +11,9 @@ export default withMermaid( description: "Your Gateway to Knowledge about the SORA Network", head: [ ["meta", { name: "keywords", content: "SORA ecosystem" }], - ['link', { rel: 'icon', href: '/favicon.ico', sizes: 'any' }], - ['link', { rel: 'icon', href: '/icon.svg', sizes: 'image/svg+xml' }], - ['link', { ref: 'apple-touch-icon', href: '/apple-touch-icon.png' }], + ["link", { rel: "icon", href: "/favicon.ico", sizes: "any" }], + ["link", { rel: "icon", href: "/icon.svg", sizes: "image/svg+xml" }], + ["link", { ref: "apple-touch-icon", href: "/apple-touch-icon.png" }], ], themeConfig: { // https://vitepress.dev/reference/default-theme-config @@ -144,10 +144,13 @@ export default withMermaid( text: "Staking in Fearless Wallet", link: "stake-in-fearless-wallet", }, - { text: "Nominating Validators", link: "nominating-validators" }, + { + text: "Nominating Validators", + link: "nominating-validators", + }, ], }, - + { text: "DEX", items: [ @@ -157,7 +160,7 @@ export default withMermaid( link: "provide-liquidity-to-xyk-pools", }, { text: "Advanced Trading", link: "advanced-trading" }, - + { text: "Other Polkaswap Features", link: "polkaswap-other-features", @@ -165,33 +168,38 @@ export default withMermaid( ], }, { - text: "Interoperability", + text: "Interoperability (HASHI)", link: "interoperability", items: [ { text: "EVM", - link: "evm", items: [ { - text: "HASHI", + text: "Ethereum", items: [ { text: "Adding a Token", link: "adding-tokens-to-hashi-bridge", }, - { - text: "Become a Relayer", - }, + { text: "Fixing a Stuck Transaction", link: "unstuck-bridge-tx", }, ], }, - { text: "Trustless" }, ], }, - { text: "Substrate", items: [{ text: "Become a Relayer" }] }, + { + text: "Substrate", + link: "substrate-bridge", + items: [ + { + text: "Establishing HRMP channel", + link: "establishing-hrmp-channel", + }, + ], + }, ], }, { text: "Referral System", link: "/referral" }, @@ -207,7 +215,10 @@ export default withMermaid( items: [ { text: "Overview", link: "polkaswap" }, { text: "Connect Wallet", link: "polkaswap-connect-wallet" }, - { text: "Connect with Google", link: "polkaswap-connect-with-google" }, + { + text: "Connect with Google", + link: "polkaswap-connect-with-google", + }, { text: "Send & Receive", link: "send-and-receive-polkaswap", @@ -227,7 +238,7 @@ export default withMermaid( { text: "Demeter Staking", link: "demeter-staking-polkaswap" }, ], }, - + { text: "DEX", items: [ @@ -236,8 +247,11 @@ export default withMermaid( text: "Provide Liquidity to XYK Pools", link: "provide-liquidity-to-xyk-pools-polkaswap", }, - { text: "Advanced Trading", link: "advanced-trading-polkaswap" }, - + { + text: "Advanced Trading", + link: "advanced-trading-polkaswap", + }, + { text: "Other Polkaswap Features", link: "polkaswap-other-features", @@ -285,7 +299,7 @@ export default withMermaid( ], }, ], - + socialLinks: [ { icon: "github", link: "https://github.com/sora-xor/sora-docs" }, ], @@ -300,8 +314,8 @@ export default withMermaid( outlineTitle: "Page Contents", docFooter: { prev: false, - next: false - } + next: false, + }, }, srcDir: "./src", lastUpdated: true, diff --git a/src/architecture/interoperability/evm.md b/src/architecture/interoperability/evm.md index aa30f463..06a2d797 100644 --- a/src/architecture/interoperability/evm.md +++ b/src/architecture/interoperability/evm.md @@ -1 +1 @@ -This page was moved to [EVM](../../evm). +This page was moved to [EVM](../interoperability). diff --git a/src/assets/fundsReceivedOnParachain.png b/src/assets/fundsReceivedOnParachain.png new file mode 100644 index 00000000..56679b54 Binary files /dev/null and b/src/assets/fundsReceivedOnParachain.png differ diff --git a/src/assets/sidechain-token-registration.png b/src/assets/sidechain-token-registration.png new file mode 100644 index 00000000..df5eaf24 Binary files /dev/null and b/src/assets/sidechain-token-registration.png differ diff --git a/src/assets/substrate-bridge-components.svg b/src/assets/substrate-bridge-components.svg new file mode 100644 index 00000000..cd38e6cc --- /dev/null +++ b/src/assets/substrate-bridge-components.svg @@ -0,0 +1 @@ +SORA parachainRelay chain(Polkadot/Kusama)XCMXCMOther parachainsSORA mainnetFederatedbridge \ No newline at end of file diff --git a/src/assets/thischain-token-registration.png b/src/assets/thischain-token-registration.png new file mode 100644 index 00000000..5370f5d2 Binary files /dev/null and b/src/assets/thischain-token-registration.png differ diff --git a/src/assets/token-burn.png b/src/assets/token-burn.png new file mode 100644 index 00000000..be67b040 Binary files /dev/null and b/src/assets/token-burn.png differ diff --git a/src/assets/transfer-to-parachain.png b/src/assets/transfer-to-parachain.png new file mode 100644 index 00000000..685ac342 Binary files /dev/null and b/src/assets/transfer-to-parachain.png differ diff --git a/src/assets/xcmMessageDispatchedOnMainnet.png b/src/assets/xcmMessageDispatchedOnMainnet.png new file mode 100644 index 00000000..0d300154 Binary files /dev/null and b/src/assets/xcmMessageDispatchedOnMainnet.png differ diff --git a/src/assets/xcmMessageSent.png b/src/assets/xcmMessageSent.png new file mode 100644 index 00000000..c8eba112 Binary files /dev/null and b/src/assets/xcmMessageSent.png differ diff --git a/src/establishing-hrmp-channel.md b/src/establishing-hrmp-channel.md new file mode 100644 index 00000000..e14187ff --- /dev/null +++ b/src/establishing-hrmp-channel.md @@ -0,0 +1,35 @@ +# Establish an HRMP channel + +To establish communication between your parachain and SORA, you must create HRMP channels that go through the Relay Chain to transfer messages between parachains. + +Remember that HRMP channels usually go in one direction. For two-way communication, you'll need to set up another channel going the opposite way. Therefore, the following is split into sub-sections: + +## Your Parachain to SORA + +1. Obtain the encoded call data of the `hrmp.hrmpInitOpenChannel` extrinsic on the relay chain. + +This unique code includes a `recipient` detail telling the relay chain which parachain you want to connect to. The recipient changes depending on what environment you are planning to establish the channel in. For Kusama, look at [this list](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fksm-rpc.stakeworld.io#/parachains), and for Rococo, go to [this list](https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Frococo-rpc.polkadot.io#/parachains). + +Combine this parachain id with the other info from the documentation. For example, for Rococo you'll have something like this: `0x3c00db070000e803000000900100`. + +2. Within your parachain, compose an XCM message that notifies the relay chain about the intent to open a channel with SORA. Refer to the [official documentation](https://docs.substrate.io/reference/how-to-guides/parachains/add-hrmp-channels/) for an illustrative example of the XCM message. + +::: info + +It is important to acknowledge that if your implementation of HRMP channel logic differs from the standard `polkadotXcm.send` pallet; you should modify this step accordingly. + +::: + +Once the extrinsic executes successfully, SORA needs to accept the channel establishment. + +3. Subsequently, the SORA team will accept the channel by incorporating the encoded call data of `hrmp.hrmpAcceptOpenChannel`. This data will feature your parachain's ID as a parameter and will be executed via the `xcmApp.sudoSendXCM` call. + +Upon successful execution, (an) HRMP channel(s) will be established from your parachain to SORA. + +## SORA to Your Parachain + +The steps here mirror those from the preceding sub-section. For steps (1) and (2) outlined earlier, SORA initiates an XCM message to propose channel establishment. Subsequently, it's your responsibility to encode `hrmp.hrmpAcceptOpenChannel` with SORA's parachain ID. For instance, in the case of Rococo, the encoded call data would be: `0x3c01db070000`. Execute an XCM message from your parachain in alignment with the [official guidelines](https://docs.substrate.io/reference/how-to-guides/parachains/add-hrmp-channels/), including the encoded call data containing SORA's parachain ID. + +Upon successful execution of this process, your parachain will be set up to receive messages from the SORA parachain. + +We will still need to register the assets to be transferred from one chain to another. On your parachain, you will need to register the SORA assets. On the SORA Mainnet, we will need to register your assets. diff --git a/src/evm.md b/src/evm.md deleted file mode 100644 index 23ffcd6f..00000000 --- a/src/evm.md +++ /dev/null @@ -1,21 +0,0 @@ ---- -title: SORA Network - Ethereum Mainnet Connectivity via HASHI Bridge | SORA Docs -head: - - - meta - - name: description - content: Explore the seamless connectivity between the SORA network and the Ethereum mainnet through the HASHI Bridge, enabling cross-chain interoperability and expanding access to multiple EVM-based networks and Substrate networks. - - - - meta - - name: keywords - content: SORA network, Ethereum mainnet, HASHI Bridge, cross-chain interoperability, EVM-based networks, Substrate networks, blockchain connectivity, decentralized finance, multi-chain ecosystem ---- - -# EVM Interoperability - -The SORA network is connected to the Ethereum mainnet via the [HASHI -Bridge](https://polkaswap.io/#/bridge/). Although currently there is only one network supported (ETH), -in the future the HASHI bridge will also feature connectivity to multiple EVM-based -networks, as well as Substrate networks. - -🚧 This chapter is currently under construction as more networks and -upgrades are added to the HASHI bridge. 🚧 diff --git a/src/interoperability.md b/src/interoperability.md index 0637f76f..2634cbe0 100644 --- a/src/interoperability.md +++ b/src/interoperability.md @@ -1 +1,19 @@ -Contents will be added as part of https://github.com/sora-xor/sora-docs/pull/44 +# Interoperability + +This article is about the HASHI bridge, a decentralized two-way bridge connecting SORA and other blockchains (such as Ethereum and Kusama). HASHI means bridge in Japanese, and it is the plumbing that links many different chains, like pipes connecting the world's assets. The initial version of this bridge was a significant component of the plans for the beta launch of the SORA network in Q1 2021. + +## History + +The SORA blockchain serves as an ecosystem for robust DeFi projects like SORA's decentralized global economic system and [Polkaswap](./polkaswap), a DEX specifically designed for an interoperable future. In line with this vision, we recognize that blockchain maximalism is no longer viable, and we acknowledge the importance of secure, fast, and efficient asset migration between blockchains. + +As an initial step towards achieving this, we have developed the source code for Ethereum Bridge. In addition to Ethereum, SORA aims to establish connections with various ecosystems. Being built on Substrate, it is advantageous to utilize the built-in cross-chain transfer capabilities to facilitate communication with projects running on the Polkadot and Kusama ecosystems. To achieve this, the [Substrate bridge](./substrate-bridge) was developed. + +With multiple bridges already in operation, it becomes necessary to streamline the bridge interface to ensure consistent software components for cross-chain transfers across different heterogeneous blockchains. As a solution, the HASHI bridge is aggregating several bridge technologies to serve as the gateway between the SORA mainnet and the external world. + +The HASHI bridge currently comprises two bridges: the Federated EVM Bridge, and the Federated Substrate Bridge. As [Polkadot's BEEFY](https://wiki.polkadot.network/docs/learn-consensus#bridging-beefy) protocol is currently still in development, HASHI uses a _federated approach_ for now. **Federated bridges** combine aspects of both **trusted** and **trustless** bridges. While **trusted** bridges rely on a central entity or a group of trusted parties to help move assets and data between different blockchains and **trustless** bridges use smart contracts or decentralized protocols to enable cross-chain transfers and avoid the use of intermediaries, **federated bridges** involve a group of trusted **relayers** working together to manage and secure cross-chain transactions. + +A federated bridge follows the following workflow; The user initiates a transfer by calling an extrinsic. Upon detecting a new transaction on the source network, each peer signs it with their respective key and registers the signature on the source network. Subsequently, active peers add their signatures to the user's transaction. Once a sufficient number of signatures are gathered, the transaction is forwarded to the target network via relayers. The relayers sign the messages before transmitting them. As a result, only the owner of the peer's private key can initiate this process. The target blockchain then verifies the recipient's compliance with the signature authority based on the consensus mechanism. If the verification is successful, the tokens will be released to the designated transfer agent's address on the new network. + +## Security + +As all bridges are quite technically complex, teams building on the SORA network may want guarantees that there will not be financial loss resulting from any technical difficulties with the bridge. While this will be explained more in a future article, the SORA Parliament will provide insurance for infrastructure that is deemed systemically important to the ecosystem. [Systemically Important Infrastructure (SII)](./social-insurance) will need to concede governance to the SORA Parliament, but in exchange, the Parliament will commit to socialize any losses, in order to give network participants the confidence to use the SORA network. Details will be laid out in a future article. diff --git a/src/substrate-bridge.md b/src/substrate-bridge.md new file mode 100644 index 00000000..fb30ad7d --- /dev/null +++ b/src/substrate-bridge.md @@ -0,0 +1,220 @@ +# Substrate Bridge + +## Main Components + +SORA interaction with Polkadot/Kusama and other relay chains is visualised in the following diagram: + +![](./assets/substrate-bridge-components.svg) + +
+ UML diagram code + +``` + +@startuml + +skinparam component { + BorderColor white + BackgroundColor red + FontColor white +} + +skinparam interface { + BorderColor black + BackgroundColor red +} + +Component [SORA mainnet] +interface "Federated\nbridge" as FB + +cloud { + [SORA parachain] as SP + [Relay chain\n(Polkadot/Kusama)] as RC + interface "XCM" as XCM1 + interface "XCM" as XCM2 + [Other parachains] as OP +} + +[SORA mainnet] - FB +FB - SP +SP - XCM1 +XCM1 - RC +RC - XCM2 +XCM2 - OP +@enduml + +``` + +
+ +Let's go through all the components mentioned in the figure: + +### SORA Mainnet + +A standalone network developed on top of the Substrate blockchain is the main object of this documentation. It has all the incoming and outgoing messages to other systems crossing the **Federated Bridge**, which is a central gateway to an external ecosystem. + +### Federated Bridge + +You can read about the Federated Bridge in [Interoperability](./interoperability). + +### SORA Parachain + +The SORA parachain serves as a blockchain gateway, allowing seamless integration between SORA and any relay chain ecosystem. It facilitates automatic token transfers, eliminating the need for users to send tokens via extrinsics on the SORA parachain. +By design, the SORA parachain eliminates the requirement for additional transaction signing. The parachain maintains a comprehensive record of tokens that can be transferred, with registration information stored in the XCMApp pallet. This information includes the mapping between the SORA mainnet AssetId and XCM Multilocation for each token. + +### Relay chain + +In the Polkadot and Kusama ecosystems, the relay chain refers to the main blockchain network that serves as the backbone for the entire network of connected parachains. It acts as a hub or coordinator for multiple parachains, facilitating their communication and interoperability. + +The relay chain provides several important features, including cross-chain messaging (XCM), shared security, scalability, and upgradeability. It enables parachains to communicate with each other through the Cross-Chain Message Passing protocol (usually utilising XCM messaging format), allowing the transfer of assets and data between different chains. + +### Parachains + +Parachains are specialized blockchains that connect to the relay chain. They can have their own consensus mechanisms, governance models, and specific functionality. They rely on the relay chain for security and the ability to interact with other parachains within the ecosystem. As the name suggests, the SORA parachain is also a parachain within this architecture. + +::: warning + +The execution of XCM transfers and the handling of incoming messages will vary between different chains. Each connected parachain should have its own dedicated reference in the documentation, specifically detailing the implementation in client applications. This reference should specify the exact version of the XCM message being used, as well as the junctions utilized and populated. + +::: + +## Flows + +Delving into the details of cross-chain transfers, you can consult the following top-level diagrams that illustrate the various directional flows: + +### SORA to Parachain + +```mermaid +sequenceDiagram + actor A as Alice + participant S as SORA + participant R as Relayer + participant P as Parachain + + A ->> S: Call bridgeProxy.burn + S ->> S: Burn (sidechain assets) / Reserve (thischain assets)¹ + S ->> S: Add message to commitment + S ->> R: Prepare commitment + R ->> R: Sign commitment + R ->> S: Approve commitment + S ->> R: Get signatures + R ->> P: Submit commitment + P ->> A: Send tokens via XCM +``` + +_¹ A sidechain asset (registered through [register_sidechain_asset](https://sora-xor.github.io/sora2-network/master/doc/substrate_gen/runtime/runtime_types/parachain_bridge_app/pallet/enum.Call.html#variant.register_sidechain_asset) ) will be burned. A SORA mainnet asset (registered via [register_thischain_asset](https://sora-xor.github.io/sora2-network/master/doc/substrate_gen/runtime/runtime_types/parachain_bridge_app/pallet/enum.Call.html#variant.register_thischain_asset)) will be reserved._ + +### Parachain to SORA + +```mermaid +sequenceDiagram + actor A as Alice + participant P as Parachain + participant R as Relayer + participant S as SORA + + A ->> P: Send tokens via XCM¹ + P ->> P: Add message to commitment + P ->> R: Prepare commitment + R ->> R: Sign commitment + R ->> P: Approve commitment + P ->> R: Get signatures + R ->> S: Submit commitment + S ->> A: Mint/Send tokens +``` + +_¹ The assets can originate from various sources, including other parachains or the Relay Chain, and the resulting action (reserve or burn) on the source chain is dependent on its specific implementation (typically initiated by calling either `xcmPallet.reserveTransferAssets` or `xTokens.transfer`). Ultimately, SORA parachain remains unaware of the final outcome, as it only receives an XCM message that will be subsequently relayed to the mainnet._ + +## Common Pallets + +There are several common pallets used in the SORA project, providing bridge functionality on both the parachain and SORA mainnet sides: + +- **SubstrateDispatch**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/dispatch)). This pallet decodes and checks messages, performs runtime calls, and creates a bridge origin to execute **XCMApp** and **ParachainBridgeApp** extrinsics. Only the bridge origin can call these extrinsics. + +- **SubstrateBridgeInboundChannel**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/substrate-channel/src/inbound)). This pallet handles the submission of incoming messages. While submitting messages can be called from any account, a relayer is used for this function. It utilizes **BeefyLightClient** or **MultisigVerifier** for message verification and **SubstrateDispatch** for message calling. + +- **SubstrateBridgeOutboundChannel**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/substrate-channel/src/outbound)). This pallet is responsible for sending outgoing messages. It is used by the **ParachainBridgeApp** and **XCMApp** to send messages to other networks. + +### SORA Mainnet Pallets + +On the SORA Mainnet side, the following pallets are used: + +- **ParachainBridgeApp**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/parachain-app)). This pallet serves as the main entry point for clients to send assets through the bridge. It also sends messages to the parachain (**XCMApp**) to register assets. The bridge requires bonding of **ParachainBridgeApp** on the Mainnet and **XCMApp** on the Parachain. It utilizes SubstrateBridgeOutboundChannel to send messages through the bridge and is used by **SubstrateDispatch** to execute messages. + +Root extrinsics: `finalizeAssetRegistration`, `registerThischainAsset`, `registerSidechainAsset`, `addAssetIdParaId`, `removeAssetIdParaId`, `mint`. +Extrinsic to be called by user: `burn`. + +- **Assets**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-network/tree/master/pallets/assets)). This pallet implements assets on the SORA 2 Mainnet. It is used by **ParachainBridgeApp** to register, mint, and burn assets. + +### SORA Parachain Components + +On the SORA parachain side, the following components are used: + +- **XCMApp**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-parachain/tree/develop/pallets/xcm-app)). This pallet establishes the connection between the SORA 2 Mainnet and a relay chain/parachain. It maintains a mapping from the SORA 2 Mainnet AssetId (a 32-byte array) to a general XCM Multilocation. It enables the transfer of assets between SORA 2 Mainnet and a relay chain/parachain. Only the bridge origin can access the pallet's extrinsics. It utilizes **SubstrateBridgeOutboundChannel** to send messages through the bridge and is used by **SubstrateDispatch** to execute messages. + +- **XTokens**: Developed by the Open Web3 Stack ([source code](https://github.com/open-web3-stack/open-runtime-module-library)). This component is used by **XCMApp** to send tokens to a relay chain/parachains. + +- **XCMExecutor**: Developed by Parity. While not a pallet, it is a crucial component for executing XCM Messages. It utilizes **XCMApp** as a transactor and AssetId converter. + +### Federated Bridge Pallets + +The Federated Bridge in SORA relies on the following pallets: + +- **BridgeDataSigner**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/data-signer)). This pallet is responsible for collecting signatures from different relayers and checks that message is signed by a valid peer. + +Root extrinsics: `registerNetwork`, `addPeer`, `removePeer`, `submit`. +Messages: see [`BridgeCall` enum](https://github.com/sora-xor/sora2-common/blob/2f0aeec218e7646c295f371c4f553f4260e59eff/pallets/types/src/substrate.rs#L126) + +- **MultisigVerifier**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-common/tree/develop/pallets/multisig-verifier)). This independent pallet is used by **SubstrateBridgeInboundChannel** and **BeefyLightClient** for message verification. It is also used by `SubstrateDispatch` to decode and dispatch bridge calls. + +Root extrinsics: `initialize`, `addPeer`, `removePeer`. + +- **The Relayer**: Developed by SORAMITSU ([source code](https://github.com/sora-xor/sora2-network/tree/master/relayer)). The Relayer is a separate service and not a pallet. It plays a crucial role in the Federated Bridge, passing through messages and holding private keys for signatures, similar to the Beefy bridge implementation. + +## Guides + +### Transfers + +::: warning + +Only specific XCM messages for/from the corresponding networks have been tested and utilised in the client applications, such as Polkaswap. When constructing your own messages, exercise caution: there is a possibility that your funds could be permanently lost. + +::: + +#### SORA mainnet -> Relaychain / Other Prachain + +To execute a cross-chain token transfer, a registration process is required beforehand. Token registration involves using the root extrinsics `ParachainBridgeApp.registerSidechainAsset` and `ParachainBridgeApp.registerThischainAsset`. For instance, to register a native token on the Rococo network, the following procedure is followed: + +![Image: Example of registering a Rococo native token](./assets/sidechain-token-registration.png) + +Similarly, to register a native token from another blockchain as transferable through a parachain, the process is as follows: + +![Image: Example of registering a native blockchain for transfer via parachain](./assets/thischain-token-registration.png) + +These extrinsics send messages to the SORA 2 Parachain, enabling the registration of asset mappings. Without this registration, tokens cannot be transferred through the parachain. + +Once the token is successfully registered, transfers can be initiated. To transfer a token to a relaychain, the extrinsic `ParachainBridgeApp.burn` is used. For instance, to transfer a ROC token to the Rococo relay chain, the following procedure is followed: + +![Image: Example of transferring ROC to the Rococo relay chain](./assets/token-burn.png) + +To specify a parachain as the transfer destination, the following request needs to be made: + +![Image: Example of indicating a parachain as the transfer target](./assets/transfer-to-parachain.png) + +By following these steps, cross-chain transfers can be successfully executed, allowing for seamless movement of tokens between different chains within the network. + +### How to Track the Status of the Transfer + +#### Other Parachain -> SORA mainnet + +1. After executing the transaction initiating a XCM message, the `xcmpQueue.XcmpMessageSent` event is emitted. + +![](./assets/xcmMessageSent.png) + +2. After a certain period of time and upon successful arrival of the message to the SORA Parachain, the `xcmpQueue.Success` event is emitted. This event will have the same message hash as shown in the example from (1). As a result, it will be possible to find `substrateBridgeOutboundChannel.MessageAccepted` from the same extrinsic. The event will contain the nonce of the message, which will be passed to the mainnet. + +![](./assets/fundsReceivedOnParachain.png) + +3. The Parachain routes the message to the mainnet. Once it arrives, the `substrateDispatch.MessageDispatched` event with the same nonce as in (2) is emitted. + +![](./assets/xcmMessageDispatchedOnMainnet.png)