Kusama
Kusama supports transfers, staking, governance and block production with distinct on-chain completion records.
Kusama is a live, value-bearing canary network where KSM holders, application users and builders can transfer assets, secure the network, govern changes and obtain execution capacity. Each action has a different commitment point and proof of completion: a finalized balance change, an active staking position, an enacted referendum or produced chain blocks. The network usually adopts experimental changes faster than Polkadot and generally has lower participation barriers. Inspect the relevant on-chain state before proceeding.
Key takeaway: KSM supports fees, staking, governance and coretime, while on-chain records show whether each action reached its intended state.
Four actions with different completion records
Transfers, staking, governance and chain deployment all change public state, yet each works through different machinery. A transfer moves an asset between accounts. Staking bonds KSM behind validator selection. OpenGov applies votes and deposits to a tracked referendum. A chain acquires coretime so its collator can propose blocks for relay-chain validation.
The required inputs include more than an account balance. The selected chain, spendable amount, permissions, fee asset and intended destination all matter. Completion evidence also differs. Balance events show transfers, staking ledgers show active or inactive positions, referendum records show an outcome and chain telemetry shows whether assigned capacity produced blocks.
A signed transaction proves intent, not always completion. Finality confirms the source state, while some actions also require evidence from a receiving chain or later governance stage.
KSM as the common input
KSM is the network's native token for transaction fees, staking, governance deposits and coretime. Its role changes with the operation. A spendable balance can be transferred or used for fees. Bonding, reserving or locking value changes how much remains spendable, even when the account still displays the full amount.
Transaction cost depends on the call and the chain that executes it. A simple balance transfer does less work than a smart-contract call or a cross-chain instruction. The fee estimate shown before signing should leave enough of the selected fee asset available for execution. A cross-chain action may also require fees at the destination.
Account survival has a separate condition. Kusama Hub requires an account to hold enough KSM or another qualifying sufficient asset. Dropping below the applicable minimum can remove the account state and destroy a residual balance. This live parameter belongs to the selected chain, so an old relay-chain figure may not describe the Hub account being used.
How do transfers reach a confirmed result?
A transfer reaches a confirmed result when the relevant chain finalizes the call and records the intended destination state. A same-chain payment needs one finalized state change. A cross-chain transfer has an origin outcome and a receiving outcome, which may appear at different times.
Transfers within one chain
A local transfer starts with a funded account, a valid destination and enough free balance for the amount and fee. The signer authorizes the call, the chain includes it in a block and finality fixes the resulting balances. An explorer event or direct state query can confirm execution. Finality does not correct a valid transfer sent to the wrong address.
Transfers between consensus systems
Cross-chain transfers use XCM instructions and an available delivery route. The destination must recognize the asset, accept the account and receive enough value to satisfy its asset rules and execution costs. Source-chain success shows that the origin processed its part. It does not, by itself, prove that the destination credited the beneficiary.
This distinction matters when an asset reaches the destination system but cannot enter the receiving account. Unsupported assets, an insufficient destination balance or unmet account requirements can interrupt the final credit. The message status and destination events identify that state more accurately than submitting the same transfer again.
What changes when KSM enters staking?
KSM becomes bonded for network security, reducing its immediate transferability while exposing it to reward variability, an unbonding delay and slashing risk. The chosen staking path determines who selects validators, who operates infrastructure and where completion appears on-chain.
Solo nomination
A solo nominator selects validator candidates under Nominated Proof of Stake. Bonding alone does not establish an active earning position. Elections determine which nominations receive active backing, while validator performance and commission affect rewards. The staking ledger and election result are therefore more useful than the submitted nomination transaction alone.
Nomination pools
A nomination pool combines member funds into one nominating position and lets the pool administration choose validators. Members receive pool points that represent their share, while commissions and validator choices affect their outcome. Members can vote in OpenGov with funds delegated to the pool because delegation staking keeps those funds under their ownership.
Validation
Validation adds node operation, session keys and continuous availability to the staking commitment. A registered validator is not necessarily active because the election still determines the set. The relevant result is active participation in consensus, not merely a successful registration call. Operational failures can reduce rewards or lead to slashing under the applicable rules.
OpenGov turns token commitment into network decisions
OpenGov separates proposals by tracks whose origins define what an approved referendum may execute. Each track has its own decision deposit, timing and approval conditions. KSM holders can vote directly or delegate voting power on selected tracks. Delegation permits the delegate to vote with that power but does not grant authority to transfer the holder's funds.
Conviction can increase voting weight in exchange for a longer lock. The lock depends on the chosen conviction and the referendum outcome, so removing a vote does not always make the balance immediately transferable. A referendum passing its approval and support conditions still proceeds through confirmation and enactment before the authorized state change occurs.
The useful completion record is the enacted call or final referendum status. A submitted preimage, decision deposit or cast vote is an intermediate state, not proof that the proposed change took effect.
Coretime provides capacity for chain production
Coretime is the relay-chain capacity that a registered chain needs to produce blocks under shared security. Agile Coretime lets a registered chain obtain scheduled capacity in bulk or order it on demand. Both paths require a registered chain, a running collator and a correct assignment before block production can follow.
Bulk coretime
Bulk coretime provides scheduled capacity across a defined sales region. A purchased region can be assigned to a chain and may support splitting or interlacing when continuous use is unnecessary. Those choices affect utilization and renewal eligibility. Ownership of the region is not enough; the assignment must point to the intended chain before its collator can use the capacity.
On-demand coretime
On-demand coretime suits intermittent production because capacity is ordered for individual opportunities rather than reserved continuously. Availability and price follow the current on-chain market. A successful order establishes access to scheduling, while a produced and finalized chain block provides the stronger completion signal. Persistent demand may make bulk capacity a more predictable option.
XCM separates message meaning from delivery
XCM is a language for expressing cross-consensus instructions, including asset movement and remote execution. It describes what participating systems should do but is not the transport protocol that carries the message. The route, origin conversion, accepted assets, execution weight and destination barriers determine whether a particular instruction can run.
Messages are asynchronous. The sending system can finalize its action before the receiving system completes execution, and a response may require a separate message. Applications should therefore display origin and destination states separately. Treating an origin transaction hash as universal proof hides the most important handoff in a cross-chain operation.
Kusama Hub carries everyday state
Kusama Hub is the primary user-facing system chain for balances, staking and governance. The balance migration from the relay chain occurred on October 7, 2025, and the related functions now operate on the Hub. The relay chain continues to coordinate consensus, shared security and core scheduling for connected chains.
The Hub also manages local and foreign assets and supports EVM-compatible smart contracts. Solidity developers can use familiar Ethereum-style tools, but the transaction must target the Kusama Hub network. A native 32-byte account created with an Ed25519 or Sr25519 key needs account mapping for Ethereum compatibility, while a secp256k1 account does not.
System chains distribute specialized functions without becoming unrelated security domains. Kusama Hub, Bridge Hub, People and Coretime each handle different state. XCM connects those functions, while relay-chain validators provide the shared validation context for attached chains.
Permissions reduce the reach of a single key
Proxy accounts can receive limited authority, such as governance or staking permissions, without receiving unrestricted transfer control. The selected proxy type defines the permitted calls. A misconfigured broad proxy creates more exposure than a narrowly scoped one, so the on-chain proxy definition is the relevant permission record.
Multisig changes authorization by requiring an agreed threshold of signatories. The same call data and timepoint must be coordinated across approvals. One submitted approval is therefore not completion unless it reaches the configured threshold and the call executes.
Social recovery addresses a different failure. Preselected recovery contacts can vouch for a new account after the configured threshold and delay. Successful recovery establishes a proxy that can act for the lost account; it does not reconstruct the missing private key. Recovery must already be configured before that key is lost.
Verify the receiving state before retrying
Consider a cross-chain asset transfer whose origin transaction has finalized, but the destination balance has not changed. The source is ready only when the account can cover the asset and fees. The commitment point is the signed call. The outcome then has two records: source finality and destination execution.
- Confirm that the source has enough spendable value for the asset and all known fees.
- Check that the destination supports the asset and can accept it into the intended account.
- Preserve the finalized origin transaction hash and its success or failure events.
- Inspect destination events and the resulting balance rather than relying on the source interface.
- If only the origin succeeded, trace the message or trapped asset before authorizing another transfer.
The expected state contains both a successful origin event and a destination credit after applicable fees. An observed source-only state means the transfer remains unresolved at the destination, not that nothing happened. Retrying immediately can create a second valid origin transfer while leaving the first message unresolved.
Where does Kusama differ from Polkadot?
Kusama and Polkadot are independent, value-bearing networks that share a similar architecture but pursue different operating priorities. Both use nominated staking, on-chain governance, connected chains, XCM and forkless runtime upgrades. Kusama generally applies shorter governance periods and lower participation barriers, which supports faster iteration under live economic conditions.
Polkadot follows a more conservative pace aimed at stability. Kusama is therefore more than a temporary rehearsal environment, and an application may remain there rather than migrate. The communities govern their networks separately, so successful deployment on Kusama does not guarantee that the same change will reach Polkadot.
Choose the next network action by matching the required state change to the available input, acceptable lock or capacity commitment and completion evidence for the intended receiving state.
Kusama: the short answers
Can I inspect Kusama activity without owning KSM?
Yes. Public chain data, finalized blocks, referenda and transaction events can be read without holding KSM. Signing a state-changing transaction is different because the selected chain must accept a fee asset and the account needs enough spendable balance. KSM is the normal fee asset for native Kusama activity. A cross-chain operation may also require execution fees at its destination, so a readable account is not automatically ready to submit the action.
Does every action on Kusama charge the same fee?
No. Fees reflect the chain, call, encoded length and execution weight, while congestion or configuration can affect the amount. A local balance transfer, governance submission, smart-contract call and cross-chain message perform different work. Cross-chain activity may consume fees in more than one place. Read the wallet's estimate before signing and retain enough spendable balance for the whole operation, because an amount that covers the asset transfer alone may not cover destination execution.
Do I need to run a validator to hold or transfer KSM?
No. Holding and transferring KSM only require control of a compatible account and enough spendable balance for fees. Validation is an operational role that runs infrastructure and participates in consensus. Nominating or joining a nomination pool provides other staking paths without operating a validator node. Those paths still introduce bonding, reward variability and slashing exposure. Election conditions also determine whether nominated stake becomes active, so staking should not be treated as an ordinary liquid balance.
Can Solidity contracts run on Kusama Hub?
Yes. Kusama Hub provides an EVM-compatible environment for Solidity smart contracts and exposes Ethereum-style tooling. The network configuration must identify Kusama Hub, since connecting a wallet to another chain changes where the transaction executes. A deployment is complete only when the contract creation transaction finalizes and the code appears at the resulting address. Contract behavior and security remain properties of the deployed code, not guarantees supplied by the wallet interface.
What happens if an account falls below its required minimum balance?
If an account falls below the required balance across its qualifying assets, the chain can reap that account and remove its state. Any dust left below the threshold may be destroyed, although the account identifier can later become active again after receiving enough qualifying value. The applicable minimum depends on the chain and asset configuration. A keep-alive transfer is appropriate when the account should remain active; a full-balance transfer intentionally permits closure.
Are deposits from every Kusama chain accepted by an exchange?
No. An exchange may support KSM deposits on one named chain while ignoring deposits delivered through a system chain, parachain or cross-chain route that it has not integrated. A valid on-chain address does not prove that its deposit system monitors the chosen origin. Match the exchange's stated deposit network before signing. If the interface names only one route, do not substitute another because the address format looks compatible.
Do new chains still use crowdloans to obtain Kusama blockspace?
No. Crowdloans and parachain slot auctions were replaced by Agile Coretime for obtaining relay-chain capacity. A registered chain can pursue bulk capacity for scheduled production or order capacity on demand, subject to the current market and runtime configuration. Old articles may still describe locking KSM in support of lease auctions, but that workflow does not describe the present route to new blockspace. Chain teams now verify coretime assignment and block production instead.
Last updated