diff --git a/docs/concepts/05_credentials/02_ctypes.md b/docs/concepts/05_credentials/02_ctypes.md index f902ba161..11aa11918 100644 --- a/docs/concepts/05_credentials/02_ctypes.md +++ b/docs/concepts/05_credentials/02_ctypes.md @@ -16,7 +16,7 @@ The schema defines which properties exist and what their type should be, e.g., a ## CType model JSON schema -The following are all required properties of the JSON schema for [CType models](https://github.com/KILTprotocol/sdk-js/blob/master/packages/core/src/ctype/CType.schemas.ts): +The following are all required properties of the JSON schema for CType models: - `$id`: An **identifier**: in the format `kilt:ctype:0x{cTypeHash}`. - `$schema`: A **reference to CType metaschema**: Describes what a valid CType must looks like. You can find the latest metaschema on IPFS at the following address [ipfs://bafybeiah66wbkhqbqn7idkostj2iqyan2tstc4tpqt65udlhimd7hcxjyq/](ipfs://bafybeiah66wbkhqbqn7idkostj2iqyan2tstc4tpqt65udlhimd7hcxjyq/). diff --git a/docs/concepts/07_dip/04_user_account_kilt.md b/docs/concepts/07_dip/04_user_account_kilt.md index 834c3d736..97c5fb035 100644 --- a/docs/concepts/07_dip/04_user_account_kilt.md +++ b/docs/concepts/07_dip/04_user_account_kilt.md @@ -50,7 +50,7 @@ The command requires the following variables: - `relayApi` The [`ApiPromise`](https://polkadot.js.org/docs/api/examples/promise/) instance for the parent relay chain. - `signer` The signing callback to sign the cross-chain transaction. - `submitterAddress` The address of the transaction submitter on the consumer chain. -- `keyRelationship` The [`VerificationKeyRelationship`](https://kiltprotocol.github.io/sdk-js/types/types_src.VerificationKeyRelationship.html) required for the DIP operation authorized on the relay chain. +- `keyRelationship` The `VerificationKeyRelationship` required for the DIP operation authorized on the relay chain. And the following optional environment variables: diff --git a/docs/develop/02_chain/04_fullnode.md b/docs/develop/02_chain/04_fullnode.md index d056efcc4..80264abf7 100644 --- a/docs/develop/02_chain/04_fullnode.md +++ b/docs/develop/02_chain/04_fullnode.md @@ -41,7 +41,7 @@ This can either be `peregrine` or `spiritnet`. Hence, to start a full node for the Spiritnet network, the parameter would be `--chain=spiritnet`. Unfortunately, there is no hardcoded chain spec for the Peregrine network, so the full path of the chainspec file must be provided `--chain=/node/dev-specs/kilt-parachain/peregrine-kilt.json`. -Please refer to the [KILT node repository](https://github.com/KILTprotocol/kilt-node/blob/master/dev-specs/kilt-parachain/peregrine-kilt.json) or the [Docker image](https://hub.docker.com/r/kiltprotocol/kilt-node/tags) for more information. +Please refer to the [KILT node repository](https://github.com/KILTprotocol/kilt-node/blob/master/chainspecs/peregrine/peregrine-paseo.json) or the [Docker image](https://hub.docker.com/r/kiltprotocol/kilt-node/tags) for more information. ### Specify the Blockchain Storage Path diff --git a/docs/develop/09_polarpath/01_overview.md b/docs/develop/09_polarpath/01_overview.md new file mode 100644 index 000000000..e4e212740 --- /dev/null +++ b/docs/develop/09_polarpath/01_overview.md @@ -0,0 +1,79 @@ +--- +id: what-is-polarpath +title: Overview +--- + +:::version-label[polarPath] + +::: + +Polar path consists of an `asset-swap` pallet for parachain runtimes and extrinisics that let parachain developers make their native token accessible on the Ethereum network using [the Snowbridge bridge](https://docs.snowbridge.network) between Polkadot and Ethereum. + +Polar path provides parachains with a solution for creating an ERC-20 wrapper around their native tokens, enabling a trustless, one to one conversion of any existing native parachain token (TOKEN) into a wrapped parachain token (eTOKEN) on Ethereum while maintaining the trustlessness guarantees Snowbridge provides. The switch also sends a corresponding amount of the native token to the parachain's sovereign account on the Asset Hub (wTOKEN). + +## Setup + +:::tip Asset Hub +The Polkadot Relay Chain doesn't natively support assets apart from DOT. Instead, parachains support this functionality, and for Polkadot, this parachain is the [Asset Hub](https://wiki.polkadot.network/docs/build-integrate-assets). +::: + +Making a Parachain token usable on Ethereum requires the following steps: + +1. The involved AssetHub account need enough balance of wTOKEN to cover the switch. This includes the amount of the switch, fees, and an existential deposit. The balance can be in DOT, KSM, ETH, or USDC. + + :::danger + If you don't have enough balance when you perform the switch, you will lock your funds, requiring a public KILT governance referendum to unlock them. + ::: + +2. Deploy an ERC-20 contract token to Ethereum with a fixed supply based on the parachain needs. + + :::tip Asset Hub + Usually, the total supply should match the parachain max supply. + ::: + +3. [Disable the token issuer rights](https://ethereum.org/en/guides/how-to-revoke-token-access/) on the ERC-20 contract. +4. [Register the ERC-20 token on Asset Hub](https://docs.snowbridge.network/applications/token-transfers#token-registration). +5. The parachain must have a representative asset on the state of the reserve XCM fees asset. + + For example, in the case of Asset Hub, the parachain should implement, `pallet-assets` to manage DOT on their chain. + +6. The entity holding ERC-20 funds performs a one-time transfer of all tokens from their Ethereum account, minus the amount of tokens previously locked with the parachain, to the parachain's sovereign account on Asset Hub. +7. Parachain governance recognizes the wrapper around the ERC-20 token by pairing the ERC-20 token to the parachain token in the swap pallet and enable the token issuer rights. + +Holders of the token on the parachain can can now switch tokens between it and Ethereum. + +## Use cases + +After setup, the following flows are possible: + +:::tip XCM +Polar path uses Polkadot's [Cross-Consensus Message Format (XCM)](https://wiki.polkadot.network/docs/learn-xcm), a messaging format and language used to communicate between consensus systems. +::: + +### Sending tokens from the parachain to Ethereum + +1. Transmit custom parachain tokens, "TOKEN", from the parachain to tokens "eTOKEN" on Asset Hub via XCM +2. Send eTOKENs from Asset Hub to the ERC-20 contract on Ethereum via Snowbridge + +### Sending tokens from Ethereum to the parachain + +1. Send eTOKENs from the ERC-20 contract on Ethereum to Asset Hub via Snowbridge +2. Send wTOKENs on Asset Hub to TOKENs on the parachain via XCM + +## Extrinsics + +Before performing a switch, the `origin` account first needs to create a switch pair between the parachain token and the ERC-20 token using the `setSwitchPair` extrinisc. Then you can use any of the other extriniscs with the switch pair, including pausing, resuming, and performing the switch itself using the `switch` extrinisc. + +Read [the `switch` pallet's documentation](./02_switch_pallet.md) for more information on the extriniscs. + +:::tip KILT example +The KILT parachain uses the `Root` origin account, so creating a switch pair requires a referendum to dispatch the extrinsic. +::: + +:::info Local and remote assets +A **local asset** is the identifier of the asset considered to be the parachain token. +This is a [Junction](https://wiki.polkadot.network/docs/learn/xcm/fundamentals/multilocation-junctions) type, referring where in the current hierarchy to find the asset. + +A **remote asset** is the identifier of the asset considered to be the other side of the switch pair. +For an ERC20 token, this is a [MultiLocation](https://wiki.polkadot.network/docs/learn/xcm/fundamentals/multilocation-summary) type (in XCM terms) pointing directly to an address on one of the many EVM-based deployments. +::: diff --git a/docs/develop/09_polarpath/02_switch_pallet.md b/docs/develop/09_polarpath/02_switch_pallet.md new file mode 100644 index 000000000..78693d165 --- /dev/null +++ b/docs/develop/09_polarpath/02_switch_pallet.md @@ -0,0 +1,153 @@ +# Asset switch pallet + +The asset switch pallet allows for switching the chain local currency 1:1 with a remote asset at a remote destination, according to the provided configuration, and using XCM. + +This is possible by creating a *switch pair*, which contains information about the remote asset's identifier (e.g., its `Location`), the remote location where the asset lives (and with which XCM communication takes place), the circulating supply of the remote asset, which can be switched back for the local currency, and additional information relevant for the XCM communication, which is explained more in-depth later on. + +## Summary + +The pallet lets users on the local chain lock `N` tokens of the chain's native currency into a switch pair-specific account to receive `N` remote assets on the configured remote location, which are transferred to them from the source chain's sovereign account on the remote chain. + +## Design choices + +The pallet aims to be generic enough for most parachains to be able to add one or more instances of the asset switch pallet into their runtime, after configuring it according to their needs. + +The pallet makes the following assumptions: + +* The local asset to switch is always the chain local currency, implementing the `fungible::Mutate` trait. +* The switch ratio is pre-defined to be 1:1, i.e., one unit of local currency for one unit of remote asset. +* The pallet only exposes calls to allow local -> remote switches. The reverse is assumed to happen via XCM reserve transfer from the configured remote location, for which the pallet crate provides all the XCM components that are dynamically configured based on the switch pair information stored within each instance of this pallet. +* The sovereign account of the source chain at destination owns the remote assets in the amount that is specified when the switch pair is created. The validation of this requirement is delegated to the source chain governance in the act leading to the creation of the switch pair, as the source chain itself has currently no means of doing that. +* To account for failure on the remote destination, the pallet stores unconfirmed operations in a storage map. The remote chain then sends `Report` messages back to either confirm or revert a transfer. In the meanwhile, the source chain (where this pallet is deployed) assumes the transfer will be successful and updates all related counters tracking the destination state, to then revert them in case of failures. + +## Add the pallet to the runtime + +Add the following line to the runtime `Cargo.toml` dependencies section: + +```toml +pallet-asset-switch = {git = "https://github.com/KILTprotocol/kilt-node.git", branch = "release-1.14.0"} +``` + +The asset switch pallet is available in the KILT node release 1.14.0 and later. + +## Configure the pallet + +The pallet can be added one or more times to the runtime. + +For multiple deployments of the same pallet (e.g., to bridge the local currency to different remote assets), pass runtime configuration to the pallet's `Config` trait. + +```rust,ignore +pub type SwitchPool1 = pallet_asset_switch::Instance1; +impl pallet_asset_switch::Config for Runtime { + // Config +} + +pub type SwitchPool2 = pallet_asset_switch::Instance2; +impl pallet_asset_switch::Config for Runtime { + // Config +} +``` + +If a single instance is required, then use the default instance: + +```rust,ignore +impl pallet_asset_switch::Config for Runtime { + // Config +} +``` + +## The `Config` trait + +As the pallet is generic over the runtime specifics, the `Config` trait requires the following configuration parameters passed to it: + +- `type AccountIdConverter: TryConvert`: Because the `AccountId` type can be anything in the runtime, the converter is responsible for converting such a `AccountId` into a `Junction`, which is then used for some XCM processing. +- `type AssetTransactor: TransactAsset`: This component is used when charging the extrinsic submitter with the XCM fees that the chain will pay at the remote chain. For instance, if the transfer on the remote chain will cost 0.1 DOTs, the `AssetTransactor` might deduct 0.1 DOTs from the user's previously topped up balance on the source chain (more details below). +- `type FeeOrigin: EnsureOrigin`: The origin that can update the XCM fee to be paid for the transfer on the remote chain. +- `type LocalCurrency: MutateFungible`: The chain's local currency. +- `type PauseOrigin: EnsureOrigin`: The origin that can pause a switch pair, e.g., if a vulnerability is found. +- `type RuntimeEvent: From> + IsType<::RuntimeEvent>`: The aggregate `Event` type. +- `type SubmitterOrigin: EnsureOrigin`: The origin that can call the `switch` extrinsic and perform the switch. +- `type SwitchHooks: SwitchHooks`: Any additional runtime-specific logic that can be injected both before and after local tokens are exchanged for the remote assets, and before and after the remote assets are converted into local tokens. +- `type SwitchOrigin: EnsureOrigin`: The origin that can set, resume, and delete a switch pair. +- `type UniversalLocation: Get`: The location of the parachain relative to the global consensus space. +- `type WeightInfo: WeightInfo`: The computed weights of the pallet after benchmarking it. +- `type XcmRouter: SendXcm`: The component responsible for routing XCM messages to the switch pair remote location to perform the remote asset transfer from the chain's sovereign account to the specified beneficiary. + +### Benchmark-only `Config` components + +- `type BenchmarkHelper: BenchmarkHelper`: Helper trait to allow the runtime to set the ground before the benchmark logic is executed. It allows the runtime to return any of the parameters that are used in the extrinsic benchmarks, or `None` if the runtime has no special conditions to fulfil. + +## Storage + +The pallet has a single `SwitchPair` storage value that contains a `Option`. +If unset, no switch pair is configured hence no switch can happen. +When set and its status is `Running`, switches are enabled in both directions. + +Two more storage components, `PendingSwitchConfirmations` and `NextQueryId`, are used for error recovery. +Specifically, the former stores information about transfers executed locally but that have not been confirmed on the remote destination. +Once a transfer either succeeds or fails, the entry is removed from the storage and additional actions are taken as needed, e.g., reverting the transfer locally as well.Th +The latter stores an ever-increasing counter, which wraps around itself when it would overflow, and provides the value the `PendingSwitchConfirmations` storage map uses to keep track of pending confirmations. + +## Events + +The pallet generates the following events: + +- `SwitchPairCreated`: when a new switch pair is created by the required origin, e.g., governance. +- `SwitchPairRemoved`: when a switch pair is removed by the root origin. +- `SwitchPairResumed`: when a switch pair has (re-)enabled local to remote asset switches. +- `SwitchPairPaused`: when a switch pair has been paused. +- `SwitchPairFeeUpdated`: when the XCM fee for the switch transfer has been updated. +- `LocalToRemoteSwitchExecuted`: when a switch of some local tokens for the remote asset has taken place. +- `RemoteToLocalSwitchExecuted`: when a switch of some remote assets for the local tokens has taken place. +- `LocalToRemoteSwitchReverted`: when a switch fails on the remote destination and is reverted on the source chain as well. +- `LocalToRemoteSwitchFinalized`: when a switch is confirmed to have successfully taken place at the remote destination. + +## Calls + +1. `pub fn set_switch_pair(origin: OriginFor, remote_asset_total_supply: u128, remote_asset_id: Box, remote_asset_circulating_supply: u128, remote_reserve_location: Box, remote_asset_ed: u128, remote_xcm_fee: Box) -> DispatchResult`: Set a new switch pair between the local currency and the specified `remote_asset_id` on the `reserve_location`. The specified `total_issuance` includes both the `circulating_supply` (i.e., the remote asset amount that the chain does not control on the `reserve_location`) and the locked supply under the control of the chain's sovereign account on the `reserve_location`. For this reason, the value of `total_issuance` must be at least as large as `circulating_supply`. It is possible for `circulating_supply` to be `0`, in which case it means this chain controls all the `total_issuance` of the remote asset, which can be obtained by locking a corresponding amount of local tokens via the `switch` call below. + + Furthermore, the pallet calculates the account that will hold the local tokens locked in exchange for remote tokens. This account is based on the pallet runtime name as returned by the `PalletInfoAccess` trait and the value of `remote_asset_id`. The generated account must already have a balance of at least `circulating_supply`, ensuring enough local tokens are locked to satisfy all requests to exchange the remote asset for local tokens. The balance of such an account can be increased with a simple transfer after obtaining the to-be-created switch pair pool account by interacting with the [asset-switch runtime API][asset-switch-runtime-api]. + + This requirement can be bypassed with the `force_set_switch_pair` call. Only `SwitchOrigin` can call this, and in most cases it will most likely be a governance-based origin such as the one provided by referenda or collectives with high privileges. +2. `pub fn force_set_switch_pair(origin: OriginFor, remote_asset_total_supply: u128, remote_asset_id: Box, remote_asset_circulating_supply: u128, remote_reserve_location: Box, remote_asset_ed: u128, remote_xcm_fee: Box) -> DispatchResult`: The same as the `set_switch_pair`, but skips the check over the switch pair pool account balance, and requires the `root` origin for the call to be dispatched. +3. `pub fn force_unset_switch_pair(origin: OriginFor) -> DispatchResult`: Forcibly remove a previously-stored switch pair. This operation can only be called by the `root` origin. + + **Any intermediate state, such as local tokens locked in the switch pair pool or remote assets that are not switchable anymore for local tokens, must be taken care of with subsequent governance operations.** +4. `pub fn pause_switch_pair(origin: OriginFor) -> DispatchResult`: Allows the `PauseOrigin` to immediately pause switches in both directions. +5. `pub fn resume_switch_pair(origin: OriginFor) -> DispatchResult`: Allows the `SwitchOrigin` to resume switches in both directions. +6. `pub fn remote_xcm_fee(origin: OriginFor, new: Box) -> DispatchResult`: Allows the `FeeOrigin` to update the required XCM fee to execute the transfer of remote asset on the reserve location from the chain's sovereign account to the beneficiary specified in the `switch` operation. + + For example, if the cost of sending an XCM message containing a `TransferAsset` instruction from the source chain to AssetHub (reserve location) changes from 0.1 DOTs to 0.2 DOTs, the fee will need to be updated accordingly to avoid transfers failing on AssetHub, leaving the whole system in an inconsistent state. Since the pallet refunds any unused assets on the reserve location to the account initiating the switch on the source chain, it is not a big issue to overestimate this value here since no funds will be burnt or unfairly taken from the user during the switch process. +7. `pub fn switch(origin: OriginFor, local_asset_amount: LocalCurrencyBalanceOf, beneficiary: Box) -> DispatchResult`: Allows the `SubmitterOrigin` to perform a switch of some local tokens for the corresponding amount of remote assets on the configured `reserve_location`. The switch will fail on the source chain if any of the following preconditions are not met: + 1. The submitter does not have enough balance to pay for the tx fees on the source chain or to cover the amount of local tokens requested. Hence, the user's local balance must be greater than or equal to the amount of tokens requested in the switch + the cost of executing the extrinsic on the source chain. + 2. No switch pair is set or the switch pair is currently not allowing switches. + 3. There are not enough locked remote assets on the `reserve_location` to cover the switch request. e.g., if the chain sovereign account on the `reserve_location` only controls `10` remote assets, users can only switch up to `10` local tokens. Once the limit is reached, someone needs to perform the reverse operation (remote -> local switch) to free up some remote tokens. + 4. The switch pair `reserve_location` is not reachable from the source chain, because the configured `XcmRouter` returns an error (e.g., there is no XCM channel between the two chains). + 5. The configured `SwitchHooks` returns an error in either the `pre-` or the `post-` switch checks. + 6. The user does not have enough assets to pay for the required remote XCM fees as specified in the switch pair info and as returned by the configured `AssetTransactor`. + +## XCM components + +Because the switch functionality relies on XCM, the pallet provides a few XCM components that should be included in a runtime to enable the whole set of interactions between the source chain and the configured remote reserve location. + +* `AccountId32ToAccountId32JunctionConverter` in [xcm::convert][xcm-convert]: provides an implementation for the pallet's `AccountIdConverter` config component, that converts local `AccountId32`s into a `AccountId32` XCM `Junction`. This works only for chains that use `AccountId32` as their overarching `AccountId` type. +* `MatchesSwitchPairXcmFeeFungibleAsset` in [xcm::match][xcm-match]: provides an implementation of the `MatchesFungibles` that returns the input `Asset` if its ID matches the XCM fee asset ID as configured in the switch pair, if present. If no switch pair is present or if the ID does not match, it returns a [XcmExecutorError::AssetNotHandled][XcmExecutorError::AssetNotHandled], which does not prevent other matchers after it to apply their matching logic. It can be used for the `AssetTransactor` property of the [XcmExecutor::Config][XcmExecutor::Config] and as the `AssetTransactor` component of this pallet in the runtime. +* `UsingComponentsForXcmFeeAsset` in [xcm::trade][xcm-trade]: provides an implementation of `WeightTrader` that allows buying weight using the XCM fee asset configured in the switch pair. That is, if the XCM fee asset is DOT, and users need to send DOTs to this chain in order to pay for XCM fees, this component lets them use those very same DOTs that are being sent to pay for the XCM fees on this chain. Any unused weight is burnt, since this chain's sovereign account already controls the whole amount on the reserve location due to the nature of reserve-based transfers. It can be used for the `Trader` property of the [XcmExecutor::Config][XcmExecutor::Config]. +* `UsingComponentsForSwitchPairRemoteAsset` in [xcm::trade][xcm-trade]: provides an implementation of `WeightTrader` that allows buying weight using the remote asset configured in the switch pair when sending it to this chain to be switched for local tokens. Any unused weight is transferred from the switch pair account to the configured `FeeDestinationAccount`, as those local tokens do not need to back any remote assets because they have been used to pay for XCM fees. It can be used for the `Trader` property of the [XcmExecutor::Config][XcmExecutor::Config]. +* `SwitchPairRemoteAssetTransactor` in [xcm::transact][xcm-transact]: provides an implementation of `TransactAsset::deposit_asset` that matches the asset to be deposited with the remote asset configured in the switch pair '(else it returns [Error::AssetNotFound][Error::AssetNotFound]) and moves as many local tokens from the switch pair account to the specified `who` destination. It also calls into the `SwitchHooks` pre- and post- checks, and generates a `RemoteToLocalSwitchExecuted` if everything is completed successfully. It can be used for the `AssetTransactor` property of the [XcmExecutor::Config][XcmExecutor::Config]. +* `IsSwitchPairXcmFeeAsset` in [xcm::transfer][xcm-transfer]: provides an implementation of `ContainsPair` that returns `true` if the given asset and sender match the stored switch pair XCM fee asset and reserve location respectively. It can be used for the `IsReserve` property of the [XcmExecutor::Config][XcmExecutor::Config]. +* `IsSwitchPairRemoteAsset` in [xcm::transfer][xcm-transfer]: provides an implementation of `ContainsPair` that returns `true` if the given asset and sender match the stored switch pair remote asset and reserve location respectively. It can be used for the `IsReserve` property of the [XcmExecutor::Config][XcmExecutor::Config]. + +The pallet itself implements the [OnResponse trait][on-response-trait], that must be added to runtimes that deploy this pallet to allow for the error-recovery process to take place. +The trait implementation validates the received query response message based on the state of the switch pair, and then performs the required action on the pending transfer info accordingly. + +[asset-switch-runtime-api]: https://github.com/KILTprotocol/kilt-node/tree/develop/runtime-api/asset-switch +[xcm-convert]: https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/convert/mod.rs +[xcm-match]: https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/match/mod.rs +[XcmExecutorError::AssetNotHandled]: https://github.com/paritytech/polkadot-sdk/blob/33324fe01c5b1f341687cef2aa6e767f6acf40f3/polkadot/xcm/xcm-executor/src/traits/token_matching.rs#L54 +[XcmExecutor::Config]: https://github.com/paritytech/polkadot-sdk/blob/33324fe01c5b1f341687cef2aa6e767f6acf40f3/polkadot/xcm/xcm-executor/src/config.rs#L31 +[xcm-trade]: https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/trade/mod.rs +[Error::AssetNotFound]: https://github.com/paritytech/polkadot-sdk/blob/e5791a56dcc35e308a80985cc3b6b7f2ed1eb6ec/polkadot/xcm/src/v3/traits.rs#L68 +[xcm-transact]: https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/transact/mod.rs +[xcm-transfer]: https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/transfer/mod.rs +[on-response-trait]: https://github.com/paritytech/polkadot-sdk/blob/33324fe01c5b1f341687cef2aa6e767f6acf40f3/polkadot/xcm/xcm-executor/src/traits/on_response.rs#L29 diff --git a/docs/develop/09_polarpath/_category_.json b/docs/develop/09_polarpath/_category_.json new file mode 100644 index 000000000..e617cba37 --- /dev/null +++ b/docs/develop/09_polarpath/_category_.json @@ -0,0 +1,5 @@ +{ + "label": "Polar path", + "collapsible": true, + "collapsed": true +} diff --git a/docs/participate/01_staking/01_become_a_collator/03_setup_node.md b/docs/participate/01_staking/01_become_a_collator/03_setup_node.md index d7d47eff5..f029d5870 100644 --- a/docs/participate/01_staking/01_become_a_collator/03_setup_node.md +++ b/docs/participate/01_staking/01_become_a_collator/03_setup_node.md @@ -74,7 +74,7 @@ This can either be `peregrine` or `spiritnet`. Hence, to start a collator node for the Spiritnet network, the parameter would be `--chain=spiritnet`. Unfortunately, there is no hardcoded chain spec for the Peregrine network, so the full path of the chainspec file must be provided `--chain=/node/dev-specs/kilt-parachain/peregrine-kilt.json`. -Please refer to the [KILT node repository](https://github.com/KILTprotocol/kilt-node/blob/master/dev-specs/kilt-parachain/peregrine-kilt.json) or the [Docker image](https://hub.docker.com/r/kiltprotocol/kilt-node/tags) for more information. +Please refer to the [KILT node repository](https://github.com/KILTprotocol/kilt-node/blob/master/chainspecs/peregrine/peregrine-paseo.json) or the [Docker image](https://hub.docker.com/r/kiltprotocol/kilt-node/tags) for more information. ### Specify the Blockchain Storage Path diff --git a/docusaurus.config.js b/docusaurus.config.js index 26bab7d0b..c18d33462 100644 --- a/docusaurus.config.js +++ b/docusaurus.config.js @@ -104,6 +104,11 @@ module.exports = { docId: 'develop/opendid/what-is-opendid', label: 'OpenDID Documentation', }, + { + type: 'doc', + docId: 'develop/polarpath/what-is-polarpath', + label: 'Polar path Documentation', + }, ], }, { @@ -282,5 +287,34 @@ module.exports = { }, }, ], + [ + 'docusaurus-plugin-remote-content', + { + // Pulls external files and adds them as files in the Docusaurus folder, rewriting the title and the file name + name: 'switch-pallet', + sourceBaseUrl: + 'https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/', + outDir: 'docs/develop/09_polarpath', + documents: ['README.md'], + modifyContent(filename, content) { + if (filename.includes('README')) { + const regex = /\.\/[^\/]+\/[^\/]+\/([^\/]+\/mod\.rs)/g + var trimContent = content.replaceAll( + regex, + 'https://raw.githubusercontent.com/KILTprotocol/kilt-node/develop/pallets/pallet-asset-switch/src/xcm/$1' + ) + var trimContent2 = trimContent.replace( + '../../runtime-api/asset-switch/', + 'https://github.com/KILTprotocol/kilt-node/tree/develop/runtime-api/asset-switch' + ) + return { + filename: '02_switch_pallet.md', + content: trimContent2, + } + } + return undefined + }, + }, + ], ], } diff --git a/src/versions.js b/src/versions.js index d9386b7f8..57b0edde9 100644 --- a/src/versions.js +++ b/src/versions.js @@ -1,5 +1,12 @@ export const nodeVersions = { - '1.13.0':{ + '1.14.0':{ + name: 'Polar Path', + features: [ + { polarPath: "Spiritnet" }, + { polarPath: "Peregrine" }, + ], + }, + '1.13.0':{ name: 'Dippy Duck', features: [ { DIP: "Spiritnet" },