How Quantova Improvement Proposals Work
QIPs are the formal record through which the Quantova protocol evolves. Each proposal carries a precise technical specification and serves as the authoritative reference for network upgrades and application standards.
Proposals move through on chain governance under forkless upgrade rules, with referenda and conviction weighted voting deciding what enters the runtime. The same process governs every change, from core protocol parameters to interface standards adopted across applications.
Page last updated October 2, 2025
| Property | Detail |
|---|---|
| Record type | Technical specification of record |
| Decision method | On chain referenda |
| Runtime upgrade approval | 80% |
| Conviction voting | Up to 2.5x weight |
| Upgrade mechanism | Forkless, on chain |
| Repository | github.com/Quantova/QIPs |
What are QIPs
Quantova Improvement Proposals are standards that specify new features or processes for the protocol. Each proposal contains the full technical specification for a proposed change and acts as the source of truth for the network. Upgrades to the runtime and application standards for Quantova are documented and decided through the QIP process.
A proposal is published in the open, reviewed against the published rules, then put to the network through governance. Because enforcement and decisions occur on chain, every participant can audit the path a proposal takes from draft to adoption.
Why QIPs matter
Beyond the technical specification of a change, a QIP is the unit around which governance operates. Anyone may propose one. Network participants then debate whether it should be adopted as a standard or included in a runtime upgrade.
Non core QIPs do not need to be adopted by every application. An asset issuer may choose not to implement a given token standard, for instance. Core QIPs are different. Every node must run the same runtime to remain part of the network, so a core QIP requires a higher threshold of approval, set at eighty percent for runtime upgrades, before it takes effect.
How proposals are classified
QIP editors review each submission for technical soundness, formatting and clarity before it advances. The classification of a proposal determines the consensus threshold it must reach and the participants who must adopt it.
Core
Changes to the runtime, consensus rules or protocol parameters. Every node must adopt them, so they require the highest approval threshold through referenda.
Application standards
Interface standards adopted across applications, such as token and asset formats. Adoption is selective rather than network wide.
Process
Changes to the procedures, tooling and editorial rules that govern how proposals themselves are submitted, reviewed and recorded.
From draft to runtime
A proposal advances through defined stages. Each stage is recorded, and a core proposal becomes authoritative only after it clears governance and the forkless upgrade is applied to the runtime.
| Stage | Detail |
|---|---|
| Draft | Author publishes the specification for open review |
| Editorial review | Editors check technical soundness and formatting |
| Referendum | Network votes with conviction up to 2.5x weight |
| Approval | Runtime upgrades require 80 percent approval |
| Enactment | Forkless on chain upgrade applied to the runtime |
| Final | Recorded as an adopted standard of record |
Propose a change to the protocol
Draft a specification, open it for review and put it to the network through on chain governance.
Owned by Quantova Inc. Released under the Business Source License 1.1.
