Before connecting to the production Spiritnet, it is recommended to test applications using its canary network Peregrine. In contrast to running your own blockchain, you will neither have control over the blockchain, nor have any initial funds.
In this section we will guide you through the process of receiving funds on Peregrine and connecting to one of the network nodes. Additionally, we explain the difference between the Standalone and Parachain runtimes.
Since the native token of Peregrine, the PILT, does not have any economic value, you can request 100 PILT from the Peregrine faucet.
Connect to the Network
Replace the WebSocket address of your script or application with
You can either use your own frontend or the Polkadot JS Apps to interact with the chain. Moreover, you can use Subscan as a chain explorer. For a full list of deployments and services, take a look here.
Standalone vs. Parachain (Peregrine/Spiritnet)
The standalone chain is very close in functionality to our parachains but there are a few fundamental differences between them.
While governance is a very important part of our parachains, it is not used in the standalone version and is replaced by the Sudo pallet. None of the following pallets are part of the standalone chain, but they are all part of the parachain runtime:
Staking is part of the consensus protocol and is used to elect who is allowed to produce blocks. It is important for parachains to have this election process as decentralized as possible. On the other hand, for a standalone development chain it is not necessary since all nodes are most likely controlled by you or your organization.
Deploying a parachain is more complex than deploying a standalone chain. For the standalone node, a single Docker command is sufficient. In contrast, the task of spinning up a parachain can be split up in three steps.
- Setup a Relay Chain with 4 validators.
- Start and connect your parachain node to the Relay Chain.
- Register your parachain using the runtime WASM and the genesis state.
Since these steps are not trivial to execute and take quite some time to do manually, we provide a minimal Docker-based setup script which automates them.
Before transactions are sent to the chain, they are encoded and signed.
The encoding depends on the runtime and can differ from chain to chain.
Even the same call in the same pallet can have a different encoding for different chains, for instance the
vest() call of the
|Chain||Encoding of Vesting.vest()|