This page serves as a high-level introduction to the Polkadot protocol with terminology that may be specific to Polkadot, notable differences to other chains that you may have worked with, and practical information for dealing with the chain.
- Token decimals: 12
- Balance type:
In Polkadot (and most Substrate chains), user accounts are identified by a 32-byte (256-bit)
AccountId. This is simply the public key for the cryptography used by Substrate.
Polkadot (and Substrate) use the SS58 address format. This is a broad "meta-format" designed to handle many different cryptographies and chains. It has much in common with Bitcoin's Base58Check format such as a version prefix, a hash-based checksum suffix, and base-58 encoding.
See the SS58 page in the Substrate wiki for encoding information and a more comprehensive list of network prefixes.
Relevant SS58 prefixes for this guide:
- Polkadot: 0
- Kusama: 2
- Westend: 42
Polkadot supports the following cryptographic key pairs and signing algorithms:
- Sr25519 - Schorr signatures on the Ristretto group
- ECDSA signatures on secp256k1
Note that the address for a secp256k1 key is the SS58 encoding of the hash of the public key in order to reduce the public key from 33 bytes to 32 bytes.
Polkadot uses an existential deposit (ED) to prevent dust accounts from bloating state. If an account drops below the ED, it will be reaped, i.e. completely removed from storage and the nonce reset.
Wallets and custodians who track account nonces for auditing purposes should take care not to have
accounts reaped, as users could refund the address and try making transactions from it. The
Balances pallet provides a
transfer_keep_alive function that will return an error and abort
rather than make the transfer if doing so would result in reaping the sender's account.
Free vs. Reserved vs. Locked vs. Vesting Balance
Account balance information is stored in
Polkadot primarily deals with two types of balances: free and reserved.
For most operations, free balance is what you are interested in. It is the "power" of an account in staking and governance, for example. Reserved balance represents funds that have been set aside by some operation and still belong to the account holder, but cannot be used.
Locks are an abstraction over free balance that prevent spending for certain purposes. Several
locks can operate on the same account, but they overlap rather than add. For example, an account
could have a free balance of 200 DOTs with two locks on it: 150 DOTs for
Transfer purposes and
100 DOTs for
Reserve purposes. The account could not make a transfer that brings its free balance
below 150 DOTs, but an operation could result in reserving DOTs such that the free balance is below
150, but above 100 DOTs.
Bonding tokens for staking and voting in governance referenda both utilize locks.
Vesting is another abstraction that uses locks on free balance. Vesting sets a lock that decreases over time until all the funds are transferable.
Extrinsics and Events
Extrinsics constitute information from the outside world and take on three forms:
- Signed Transactions
- Unsigned Transactions
As an infrastructure provider, you will deal almost exclusively with signed transactions. You will, however, see other extrinsics within the blocks that you decode. Find more information in the Substrate documentation.
Inherents contain information that is not provably true, but validators agree on based on some measure of reasonability. For example, a timestamp cannot be proved, but validators can agree that it is within some delta of their system clock. Inherents are not gossiped on the network, and only block authors insert them into blocks.
Signed transactions contain a signature of the account that issued the transaction and stands to pay a fee to have the transaction included on chain. Because the value of including signed transactions on-chain can be recognized prior to execution, they can be gossiped on the network between nodes with a low risk of spam. Signed transactions fit the concept of a transaction in Ethereum or Bitcoin.
Some transactions cannot be signed by a fee-paying account and use unsigned transactions. For example, when a user claims their DOTs from the Ethereum DOT indicator contract to a new DOT address, the new address doesn't yet have any funds with which to pay fees.
Extrinsics can be mortal or immortal. The transaction payload includes a block number and block hash checkpoint from which a transaction is valid and a validity period (also called "era" in some places) that represents the number of blocks after the checkpoint for which the transaction is valid. If the extrinsic is not included in a block within this validity window, it will be discarded from the transaction queue.
Setting the block checkpoint to zero, using the genesis hash, and a validity period of zero will make the transaction "immortal".
NOTE: If an account is reaped and a user re-funds the account, then they could replay an immortal transaction. Always default to using a mortal extrinsic.
While extrinsics represent information from the outside world, events represent information from
the chain. Extrinsics can trigger events. For example, the Staking pallet emits a
when claiming staking rewards to tell the user how much the account was credited.
Polkadot uses weight-based fees that, unlike gas, are charged pre-dispatch. Users can also add a "tip" to increase transaction priority during congested periods. See the transaction fee page for more info.
Parity's integration tools should allow you to deal with decoded data. If you'd like to bypass them and interact directly with the chain data or implement your own codec, Polkadot encodes block and transaction data using the SCALE codec.
The Polkadot Relay Chain does not support smart contracts.
Besides running a private network, Polkadot has two other networks where you could test infrastucture prior to deploying to the Polkadot mainnet.
Kusama Canary Network: Kusama is Polkadot's cutting-edge cousin. Many risky features are deployed to Kusama prior to making their way into Polkadot.
Westend Testnet: Westend is Polkadot's testnet and uses the Polkadot runtime.
Can an account's balance change without a corresponding, on-chain transaction?
No, but not all balance changes are in a transaction, some are in events. You will need to run an archive node and listen for events and transactions to track all account activity. This especially applies to locking operations if you are calculating balance as the spendable balance, i.e. free balance minus the maximum lock.
What chain depth is considered "safe"?
Polkadot uses a deterministic finality mechanism. Once a block is finalized, it cannot be reverted except by a hard fork. Kusama has had hard forks that had to revert four finalized blocks in order to cancel a runtime upgrade. Using a finalized depth of ten blocks should be safe.
Note that block production and finality are isolated processes in Polkadot, and the chain can have a long unfinalized head.
Do users need to interact with any smart contracts?
No, users interact directly with the chain's logic.
Does Polkadot have state rent?
No, Polkadot uses the existential deposit to prevent dust accounts and other economic mechanisms like locking or reserving tokens for operations that utilize state.
What is an external source to see the current chain height?