A genesis file is a JSON document file which contains a set of parameters that outline the initial state of a network.
The state defined in the Oasis Network’s genesis file contains all of the necessary information for launching the Oasis Network Mainnet, including initial token allocations, network parameters, and more.
We will discuss some of the key parameters in the genesis file this document. You can view all of the parameters in their raw form in the full genesis file linked at the top of this document.
When Oasis Node loads a genesis file (i.e. a JSON document) it converts it to a genesis document.
The important thing to note is that the genesis document is used to compute the genesis document's hash. This hash is used to verify for which network a given transaction is intended for.
The genesis_time parameter is an ISO8601 UTC timestamp that specifies when the blockchain is officially going to launch. At the time of genesis, validators are expected to come online and start participating in the consensus process for operating the network. The network will start once validators representing more than 2/3 of stake in the initial consensus committee are online.
The chain_id is a human-readable version identifier for a blockchain. It is important to note, that this value alone doesn't dictate the version of the genesis file. To determine the correct version of a genesis file, the shasum of that genesis file will need to be generated. This can be done on Linux/macOS like so:
shasum -a 256 genesis.json
The interval parameter specifies the number of blocks in an epoch. Epochs are used as a measure of time for staking reward schedules, debonding intervals, non-Mainnet test network expiration periods, and more. This value is set to 600, indicating that a new epoch on the Oasis Network transpires each time 600 new blocks are generated.
Within the registry object, there are a broad range of parameters that specify the initial set of node operators and their corresponding initial node statuses.
max_node_expiration - The maximum duration (in epochs) that node registrations last. The starting value is set to 2 in order to ensure that a node is continuously online, since the node’s registration would expire each time 2 epochs pass, requiring the node to re-register.
entities - The entity registrations for initial node operators, including public key and signature information. The values here were obtained during the entity package collection process that took place during early September.
nodes - The node registrations for initial node operators, including public key and signature information.
The following parameters define the gas costs for various types of transactions on the network:
compute_commit - The cost for a compute commit for a ParaTime node. The value is set to 10000 gas.
merge_commit - The cost for a ParaTime merge commit. The value is set to 10000 gas.
add_escrow - The cost for an add_escrow (staking) transaction. The value is set to 1000 gas.
burn - The cost for a burn transaction. The value is set to 1000 gas.
reclaim_escrow - The cost for a reclaim_escrow transaction (for withdrawing staked tokens). The value is set to 1000 gas.
transfer - The cost for a transfer transaction (for sending tokens). The value is set to 1000 gas.
amend_commission_schedule - The cost for amending, or changing, a commission schedule. The value is set to 1000 gas.
There are several threshold parameters that specify the minimum number of tokens that need to be staked in order for a particular entity or a particular type of node to participate in the network. The minimum threshold specified for the entity, node-compute, node-keymanager, node-storage, and node-validator parameters is set to 100000000000 nROSE for each, indicating that you need to stake at least 100 ROSE tokens in order to have your entity or any of the specified nodes go live on the network.
There are also minimum thresholds for registering new runtimes. The minimum thresholds for registering runtime-compute and runtime-keymanager are set to 50000000000000 nROSE, indicating that you need to stake at least 50000 ROSE tokens in order to register a runtime.
These key parameters are related to staking and rewards on the network:
debonding_interval - The period of time (in epochs) that must pass before staked or delegated tokens that are requested to be withdrawn are returned to the account's general balance. The value is set to 336 epochs, which is expected to be approximately 14 days.
reward_schedule - The staking reward schedule, indicating how the staking reward rate changes over time, defined at an epoch-by-epoch granular basis. The reward schedule uses a tapering formula with higher rewards being paid out at earlier epochs and then gradually decreasing over time.
signing_reward_threshold_numerator and signing_reward_threshold_denominator - These parameters define the proportion of blocks that a validator must sign during each epoch to receive staking rewards. A proportion of 3/4 means that a validator must maintain an uptime of at least 75% during an epoch in order to receive staking rewards for that period.
rate_change_interval - The granularity at which at rate changes can be specified in a commission schedule. This limits the complexity of the commission schedule; the value is set to 1, indicating that the commission rate can change once per epoch.
rate_bound_lead - The minimum lead time (in epochs) needed for changes to commission rate bounds. Operators need to wait before any rate bound changes go into effect. The value is set to 336, which is expected to be approximately 14 days.
max_rate_steps - The maximum allowed number of rate step changes in a commission schedule.The value is set to 10, indicating that the commission schedule can have a maximum of 10 rate steps.
max_bound_steps - The maximum allowed number of commission rate bound step changes in the commission schedule. The value is set to 10, indicating that the commission schedule can have a maximum of 10 bound steps.
min_delegation - The minimum amount of tokens required in a delegation. The value is set to 100000000000 nROSE, or 100 ROSE tokens.
fee_split_weight_propose - The block proposer's share of transaction fees, set to a value of 2.
fee_split_weight_next_propose - The next proposer's share of transaction fees, set to a value of 1.
fee_split_weight_vote - A signer’s/voter’s share of transaction fees, set to a value of 1.
reward_factor_epoch_signed - The factor for rewards distributed to validators who signed at least threshold blocks in a given epoch, set to a value of 1.
reward_factor_block_proposed - The factor for rewards earned for block proposal. Set to 0, indicating validators get no extra staking rewards for proposing block.
The following parameters specify the total token supply, total token pool reserved for staking rewards, and account balances across the network at the time of genesis:
total_supply - Specifies the total token supply for the network, which is fixed at 10 billion ROSE tokens.
common_pool - The tokens reserved for staking rewards to be paid out over time.
ledger - The staking ledger, encoding all accounts and corresponding account balances on the network at the time of genesis, including accounts for initial operators, backers, custodial wallets, etc.
delegations - The encoding of the initial delegations at the time of genesis.
These parameters specify key values for the network's slashing mechanism:
amount - The amount of tokens to slash for double signing. The value is set to 100000000000 nROSE, or 100 ROSE tokens.
freeze_interval - The duration, in epochs, for which a node that has been slashed for double signing is “frozen,” or barred from participating in the network's consensus committee. A value of 18446744073709551615 (the maximum value for a 64-bit unsigned integer) means that any node slashed for double signing is, in effect, permanently banned from the network.
The following parameters are used to define key values for the network's consensus protocol:
min_validators - The minimum size for the consensus committee, set to 15 validators.
max_validators - The maximum size for consensus committee, set to 80 validators.
max_validators_per_entity - The maximum number of nodes from a given entity that can be in the consensus committee at any time. Set to a value of 1.
backend - Defines the backend consensus protocol. Specified as "tendermint".
timeout_commit - Specifies long to wait after committing a block before starting a new block height, in nanoseconds (this affects block interval). Set to 5000000000 nanoseconds, or 5 seconds.
max_tx_size - Maximum size for consensus-layer transactions, in bytes, set to 32768 bytes.
max_block_size - Maximum block size, in bytes, set to 22020096 bytes
max_block_gas - Maximum block gas, set to 0, which specifies an unlimited amount of gas.
public_key_blacklist - A list of the public keys that cannot be used on the network.
Please note that transfers will be disabled for Mainnet Beta and we expect once proposed by the community and adopted enabled to begin Mainnet. Transfers are enabled on Mainnet Dry Run to test this feature out completely.
We look forward to receiving the community’s feedback on the Oasis Network’s genesis file! If you have any specific feedback or questions, please let us know via the genesis file feedback form.