This document describes how to add the Native Token Management features to an already running partner chain and how to remove it.
The Native Token Management feature in the Partner Chain Toolkit consists of the pallet, the primitives crate, and the supporting DB-Sync data source. It complements the main chain component by providing its observability.
Care must be taken when adding this feature to a running chain, because the data source and inherent data provider require runtime data for operation.
The native token management observability is configured using the following parameters:
illiquid supply validator address
- this is the address to which the native tokens are sent on the main chain to lock them so that they can be unlocked on the partner chain. This address is derived from the sidechain params and is present in the output of theaddresses
command of thepartner-chains-smart-contracts
CLI underaddresses/IlliquidCirculationSupplyValidator
. When using thepartner-chains-cli
wizard, it will be automatically set up in theprepare-configuration
step.- native token minting
policy ID
andasset name
- those should come from the Cardano Native Asset used to represent the partner chain's token on the main chain. Because each native asset used can have different logic in its minting policy, development and creation of the asset is left for each partner chain builder. When using thepartner-chains-cli
wizard, these can be set up in theprepare-configuration
step.
flowchart TB
id1["Obtain native token parameters from configuration"] --> id2["Update partner chain source code"] --> id3["Build new partner chain version"] --> id4["Deploy new partner chain version"] --> id5["Upgrade runtime"] --> id6["Set native token parameters"]
- Add the
native-token-management
pallet into the runtime. This requires implementing the traitTokenTransferHandler
, which is left for the developers of each particular partner chain to implement according to their needs and ledger structure. Consult the implementation inruntime/src/lib.rs
for an example with a mocked handler. - Wire the data source into the node.
Consult the reference implementation in
node/src/main_chain_follower.rs
for an example. - Add the inherent data provider to your inherent data provider creation logic.
Consult the implementation in
node/src/inherent_data.rs
for an example. Because the inherent data provider should only run after the pallet is added and fully configured in the runtime,new_if_pallet_present
factory function should be used instead ofnew
, when added to an already running chain. - Release or otherwise make available for deployment the new version of node and runtime.
The following steps need to be performed in order:
- Upgrade the nodes running the chain to the new node version containing the inherent data provider.
- Perform a runtime upgrade (using
sudo
or other governance feature) to the new runtime version containing the pallet. - Invoke the
set_main_chain_scripts
extrinsic on the newly added pallet, using the governance mechanism, to set the native tokenpolicy ID
andasset name
, and theilliquid supply validator address
. After this step all information necessary is present, and the native token data provider will start producing the inherent data based on observed native token transfers, triggering the pallet's inherent when necessary.
- Remove the pallet completely from the runtime. The
TokenTransferHandler
can be removed as well. To support syncing and validating historical blocks, the data source and inherent data provider must not be removed from the node. - Perform runtime upgrade.
After this step no further native token movement will be observed, even if performed on the main chain.
NOTE
Re-adding the pallet after it has been removed is not supported and its behavior is left unspecified.