Skip to main content

Quickstart

Walks through the full upgradable-network flow from a fresh wallet:
  1. Connect + fund
  2. Stake as a validator
  3. Raise a networkFee proposal
  4. Vote on the proposal
  5. Wait for tally + activation
  6. Verify a fresh tx carries the new fee
This assumes you have an RPC URL, a funded mnemonic, and that the network has at least 3 active validators (so a 2/3 vote is meaningful).

0. Connect

1. Stake

After confirmation, your address shows up in getValidators() with status = "2" (ACTIVE).

2. Propose a parameter change

3. Vote

Each validator in the snapshot set runs:
Watch the live tally:

4. Wait for tally + activation

The proposal transitions automatically:
  • At snapshotBlock + VOTING_WINDOW_BLOCKS (100 by default) the chain tallies. Status flips pending → activating if 2/3 supermajority, else rejected.
  • At effectiveAtBlock the chain folds the new value into NetworkParameters. Status flips activating → active.
You don’t need to send any further transaction — just observe:

5. Verify a fresh tx carries the new fee

The SDK fetches getNetworkParameters() at sign-time, so any transaction signed after activation carries the new networkFee:
The same fee value will be deducted from the sender’s balance when the node validates and applies the transaction.

Troubleshooting

Your validator registered after the proposal’s snapshotBlock. The snapshot is taken at proposal-confirmation time and is final — validators added later don’t get to vote on this specific proposal.
A validator can have at most one pending/activating proposal at a time. Wait for the previous one to land (active/rejected) or the next-block proposer to fill its slot.
Two pending/activating proposals cannot target the same key simultaneously. The lock releases when the earlier proposal finalises.
The minimum stake is governed by MIN_VALIDATOR_STAKE env / Phase 1 minValidatorStake parameter. Default is 10^18. Top up your address before staking.