Skip to main content

Architecture

This topic provides information about the architecture that's designed to facilitate the seamless transfer of FT4 assets across multiple chains within the Chromia blockchain platform. It is the foundation for enabling cross-chain asset movements and handling internally and externally minted assets, orchestrating the entire transfer process from asset registration to finalization.

Definitions​

To fully understand the architecture, here are some key definitions and concepts:

  • Internal assets: Assets that are minted directly on the local chain.
  • External assets: Assets used within the local chain but minted on a different chain.
  • Origin chain: The specific chain from which an asset can be received. This may or may not be the same as the issuing chain.
  • Issuing chain: The chain where an asset is initially minted.

Registration of assets​

To start a cross-chain asset transfer, you must first complete asset registration on both the sending and receiving chains. When you register external assets, specifying the origin chain is crucial.

For example, if asset "X" mints on chain A, chain A is the issuing chain for asset X. You can only mint asset X on its issuing chain, A.

If you need to use asset X on chain B, chain B must register asset X and specify that chain A is the origin chain.

Once you complete this registration process, chains A and B can freely exchange asset X.

Asset tree structure​

When chains register assets they become interconnected, resulting in a tree-like connection structure that outlines the flow of an asset across the network. This structure features a root (the issuing chain) and leaves (receiving chains).

Example 1:

  1. In this example, both chains B and C have registered an asset, with chain A set as the origin chain. Therefore, if chain B wants to transfer an asset to chain C, it must first send the asset to chain A, which will then route it to chain C.

The following diagram illustrates two possible transfer scenarios:

Example 2:

  1. Suppose chain C wants to transfer an asset to chain D. Chain C has registered the asset with chain A, which is the issuing chain. Chain D has registered its asset with chain B, and chain B has also registered with chain A. Therefore, when C initiates the transfer to D, the asset is routed in this sequence: C -> A -> B -> D.

The diagram provided below highlights two possible transfer scenarios where: B transfers an asset to C, and C transfers an asset to D:

Example 3:

  1. The following example illustrates the structure where element B serves as the connecting node between C and A. Consequently, when A wants to transfer an asset to C, the transfer must pass through B, which then routes it to C.

Below you can find the process of the asset transfer from A to C:

Validating origin chains​

The registration of any asset is a self-contained process, meaning that the origin chain is not notified about the registration on the source chain. Therefore, there is no way to verify whether the origin chain has ever registered the asset with the issuing chain.

For example, if chain A mints asset X and chain B lists A as its origin, and a new chain, C, wants to use asset X by registering it with chain Z as its origin, problems arise if Z has not registered asset X. In this case, when chain B attempts to send asset X to chain C, no connection path between the two chains is found, resulting in the transfer failing.

warning

Selecting trustworthy origin chains is crucial, as malicious or misconfigured chains could result in the user token being lost or stolen.

Operations in cross-chain transfers​

Cross-chain transfers involve three fundamental operations:

  1. init_transfer: Initiated on the source chain.
  2. apply_transfer: Executed on all intermediate and target chains.
  3. complete_transfer: Finalizes the transfer back on the source chain.

The direction of asset flow determines whether assets are locked, minted, unlocked, or burned during the process.

Anchoring and ICCF​

After the initial transfer, the following chain must verify the previous transaction's inclusion in a block. This verification process relies on the ICCF (Interchain Confirmation Facility) mechanism, which uses anchoring chains for proof verification. For a deeper understanding of ICCF, refer to the Interchain Confirmation Facility topic.