Chain Properties

Chain properties are the network's governable parameters: fees, block size, inflation rates, penalty rules, and more. There is no central authority that sets them — every active validator publishes their preferred values and the blockchain applies the median across all active validators.

---

How It Works

1. Validators Publish Preferences

Each validator submits their preferred parameters via versioned_chain_properties_update_operation:

[46, {
  "owner": "alice",
  "props": [3, {
    "account_creation_fee": "1.000 VIZ",
    "maximum_block_size": 131072,
    ...
  }]
}]

The [3, {...}] indicates version 3 (chain_properties_hf9, the current format).

2. Median Calculation

On every validator schedule update, the blockchain calls update_median_witness_props(). For each property independently, it:

1. Collects values from every active validator.
2. Sorts them.
3. Picks the median (index active.size() / 2).

Example — 5 validators vote account_creation_fee:
  0.5, 1.0, 1.0, 2.0, 5.0 VIZ
              ↑
         median = 1.0 VIZ

The median resists extremes: a single validator cannot cause a sudden large shift; a majority must agree to move any parameter significantly.

3. Application

The resulting median_props object is stored in the validator_schedule_object and enforced across all block processing.

---

All Governable Properties

Account and Delegation

Property	Type	Default	Description
account_creation_fee	asset (VIZ)	1.000 VIZ	Minimum fee to create a new account
create_account_delegation_ratio	uint32	10	Required delegation = ratio × fee
create_account_delegation_time	uint32 (s)	2592000 (30d)	How long creation delegation is locked
min_delegation	asset (VIZ)	1.000 VIZ	Minimum amount for any SHARES delegation

Block Size and Bandwidth

Property	Type	Default	Description
maximum_block_size	uint32 (bytes)	131072	Maximum block size; controls throughput
bandwidth_reserve_percent	uint16 (bp)	1000 (10%)	Extra bandwidth for small accounts
bandwidth_reserve_below	asset (SHARES)	500.000000	Threshold to qualify for bandwidth reserve
data_operations_cost_additional_bandwidth	uint32 (%)	0	Extra bandwidth multiplier for data operations (custom_operation)

Inflation and Economics

Property	Type	Default	Description
inflation_validator_percent	uint16 (bp)	2000 (20%)	Validator share of block inflation
inflation_ratio_committee_vs_reward_fund	uint16 (bp)	5000 (50%)	Split of remaining inflation: committee fund vs reward fund
inflation_recalc_period	uint32 (blocks)	806400 (~28d)	How often inflation is recalculated

Inflation flow: block_reward × inflation_validator_percent → validator. Remainder split: inflation_ratio_committee_vs_reward_fund → committee fund; the rest → award reward fund.

Reward System

Property	Type	Default	Description
min_curation_percent	uint16 (bp)	500 (5%)	Minimum curation reward share from content payouts
max_curation_percent	uint16 (bp)	500 (5%)	Maximum curation reward share
vote_accounting_min_rshares	uint32	5000000	Minimum rshares for an award to produce non-zero reward
flag_energy_additional_cost	uint16 (bp)	0	Extra energy cost for downvotes/flags

Validator Accountability

Property	Type	Default	Description
validator_miss_penalty_percent	uint16 (bp)	100 (1%)	Vote weight reduction on missed block
validator_miss_penalty_duration	uint32 (s)	86400 (1d)	How long the miss penalty lasts

Fees

All fees go to the committee fund (DAO treasury).

Property	Type	Default	Description
committee_create_request_fee	asset (VIZ)	100.000 VIZ	Fee to create a committee funding request
create_paid_subscription_fee	asset (VIZ)	100.000 VIZ	Fee to create a paid subscription
account_on_sale_fee	asset (VIZ)	10.000 VIZ	Fee to list an account for sale
subaccount_on_sale_fee	asset (VIZ)	100.000 VIZ	Fee to list subaccount creation rights for sale
validator_declaration_fee	asset (VIZ)	10.000 VIZ	One-time fee for validator registration
create_invite_min_balance	asset (VIZ)	10.000 VIZ	Minimum invite balance

Vesting Withdrawal

Property	Type	Default	Description
withdraw_intervals	uint16	28	Number of daily installments for SHARES unstaking

Committee Voting (HF14)

Anti-spam bounds on DAO committee-request ballots, enforced from HF14. These two fields live in the PM struct (chain_properties_pm, version 5) — not the base chain_properties_hf9 — so the already-live hf9 wire format is left untouched and pre-HF14 validator votes keep their original positional layout.

Property	Type	Default	Description
committee_votes_per_request	uint32	100 000	Maximum ballots one committee request can accumulate before further votes are rejected
committee_vote_min_vesting	asset (VIZ)	1000.000 VIZ	Minimum effective vesting (converted to SHARES at vote time) required to cast or revise a committee ballot

---

Property Versions

Properties were introduced in hardfork stages:

Version	Index	Hardfork	Fields added
chain_properties_init	0	Genesis	account_creation_fee, maximum_block_size, delegation params, curation, bandwidth, flag cost, vote min rshares, committee threshold
chain_properties_hf4	1	HF4	inflation_validator_percent, inflation_ratio_committee_vs_reward_fund, inflation_recalc_period
chain_properties_hf6	2	HF6	data_operations_cost_additional_bandwidth, validator_miss_penalty_percent, validator_miss_penalty_duration
chain_properties_hf9	3	HF9	create_invite_min_balance, committee_create_request_fee, create_paid_subscription_fee, account_on_sale_fee, subaccount_on_sale_fee, validator_declaration_fee, withdraw_intervals
chain_properties_hf13	4	HF13	distribution_epoch_length
chain_properties_pm	5	HF14	~30 prediction-market parameters + kill-switches pm_commit_reveal_enabled, pm_lazy_pool_enabled + vote caps committee_votes_per_request, committee_vote_min_vesting, pm_dispute_votes_per_market, pm_dispute_vote_min_vesting

Use version index 5 (chain_properties_pm) for all new validator property submissions. (Index 4 is chain_properties_hf13, which added distribution_epoch_length.)

Prediction-market parameters (v5, HF14)

All median-voted; see Prediction Market Operations.

All PM percentages are bp (10000 = 100.00%), like the other *_percent properties — no permille (‰) anywhere.

• Oracle: pm_min_oracle_insurance, pm_max_oracle_fee_percent (the only governed fee cap — on the oracle %), pm_oracle_registration_fee, pm_oracle_penalty_percent, pm_oracle_dispute_response_sec, pm_oracle_accept_window_sec (default 3600 = 1h — the named oracle must accept or reject a pending market within this window; on expiry the cron refunds the creator's seed liquidity, but not the creation fee, and voids the market → pm_market_expired).
• Risk / coverage (percent of a market's betting volume, 100 = 1.0×): pm_listing_min_coverage_percent (250 = 2.5×) — markets whose oracle insurance covers less than this share of their volume are hidden from the default list_markets catalog (revealed via show_risky); pm_betting_min_coverage_percent (150 = 1.5×) — advisory threshold, published for clients to require an explicit risk confirmation before betting (not enforced on-chain; must be ≤ pm_listing_min_coverage_percent).
• Market: pm_min_liquidity, pm_market_creation_fee, pm_max_outcomes, pm_max_market_duration. (There is no aggregate fee cap; creator/liquidity fees are uncapped and self-limiting, with a static sum ≤ 100% solvency bound.)
• Batch / commit-reveal: pm_batch_epoch_blocks, pm_reveal_window_blocks, pm_min_batch_bet, pm_commit_no_reveal_penalty_percent, pm_commit_reveal_enabled.
• Disputes: pm_dispute_fee, pm_dispute_grace_sec, pm_dispute_vote_period_sec, pm_dispute_auto_close_sec, pm_dispute_approve_min_percent, pm_no_contest_penalty_percent, pm_dispute_reward_multiplier (bp multiplier, 10000 = 1×), pm_dispute_votes_per_market (default 100 000), pm_dispute_vote_min_vesting (default 1000.000 VIZ).
• Time penalty: pm_default_time_penalty_percent, pm_max_time_penalty.
• Lazy pool: pm_lazy_pool_enabled, pm_lazy_alloc_percent, pm_lazy_max_total_alloc_percent, pm_lazy_recall_step_percent, pm_lazy_lock_sec, pm_lazy_emergency_penalty_percent, pm_lazy_min_liquidity_fee_percent (default 200 = 2% — the pool refuses to co-provide liquidity to a market whose liquidity_fee_percent is below this reward floor).
• Leverage (opt-in): pm_leverage_enabled, pm_leverage_fund_percent, pm_leverage_max_per_position_bp, pm_leverage_max_position_ratio_percent, pm_leverage_min_market_liquidity, pm_leverage_safety_margin_percent, pm_leverage_max_slippage_percent, pm_leverage_m_factor_percent, pm_leverage_pool_profit_percent, pm_leverage_expiration_buffer_sec, pm_conversion_profit_cost_percent.
• Fairness: pm_processing_cap_per_block.

The three *_enabled flags (pm_commit_reveal_enabled, pm_lazy_pool_enabled, pm_leverage_enabled) are live kill-switches: the validator median can disable commit-reveal, the lazy pool, or leverage without a new hardfork.

---

Governance Loop

SHARES holders → vote for validators
Validators → publish preferred property values
Blockchain → takes median of active set
Median → applied as live network rules

Changing a parameter requires a majority of active validators to publish the new value. The process:

1. Community discusses desired change (e.g., lower fees).
2. Validators update their published properties.
3. Users shift votes toward validators publishing the desired values.
4. Once a majority of active validators publish the new value, the median shifts.
5. New value takes effect automatically — no hardfork or governance vote needed.

---

Reading Current Properties

{ "method": "database_api.get_chain_properties", "params": [] }

Returns the current median properties in effect. See Database API.

---

See also: Validators, Database API, Staking and DAO.