Quantus on-chain governance · TechCollective lane
The on-chain parliament
Every Quantus referendum, read live from the chain — its full lifecycle, who voted, what it proposed, and the exact two-track rules it had to clear. No token-weighted voting, no community lane: Quantus governance is a tech collective of at most 13 members voting with linear weight, and every constant below is read from the runtime source.
Referenda board
Every referendum the indexer has ever seen, with the exact event trail. Timelines are derived from on-chain events — hovering shows wall-clock durations between milestones.
Reading the on-chain record…
The two-track map
Quantus removed the community/token-weighted lane — the tech-collective lane is the sole governance path (runtime/src/governance/definitions.rs, TechCollectiveTracksInfo). Windows assume the chain's 12-second block time. Curves are constant: thresholds never decay during the decision period.
Threshold lab
Try any tally against the real track math. Approval = ayes ÷ (ayes + nays) must clear the approval curve; support = ayes ÷ total members must clear the support curve. Both curves are flat, so the verdict never depends on timing — only on votes.
How votes actually work
The ranked-collective tally
Quantus wires pallet_referenda (Instance1, TechReferenda) to pallet_ranked_collective: Votes = pallet_ranked_collective::Votes, Tally = pallet_ranked_collective::TallyOf. Members don't call TechReferenda.vote — they vote through TechCollective.vote with {"poll": <referendum_index>, "aye": true|false}, and the collective's tally feeds the referendum. Vote weight is Linear: one member, one vote. Ranks are flat (promote/demote/exchange origins are disabled), and conviction multipliers are gone — bare ayes equal weighted ayes.
Membership
- Genesis collective: 10 members (the fast_upgrade curve commentary is calibrated to it: 8-of-10 ayes).
- Floor: 5 members — the runtime refuses seeds and removals that would drop below it.
- Cap: 13 members (
MaxMemberCount). - Membership changes go through Root only — i.e. a passed TechReferenda vote. No member can add or remove others unilaterally.
Observed votes — referendum #0
All 8 votes were cast as TechCollective.vote extrinsics on 2026-09-23, each one aye:
| Time (UTC) | Voter | Vote |
|---|
The referendum lifecycle
Note the preimage
The proposer uploads the exact call bytes with Preimage.note_preimage (deposit: 0.01 QTC + 0.00001 QTC/byte — referendum #0's 34-byte proposal locked 0.01035 QTC). Max proposal size: 4 KiB.
Submit
TechReferenda.submit with the proposal origin (Root → track 0, FastUpgrade → track 1) and the preimage hash. Submission deposit: 0.1 QTC (refundable). Only Root or a collective member may submit.
Decision deposit
TechReferenda.place_decision_deposit moves the referendum into the track's deciding queue (deposit: another 0.1 QTC). Without it, the referendum sits until the 45-day undeciding timeout rejects it as timed-out.
Decide
After the prepare window (10 min fast lane, 2 h tech lane), the collective votes. Approval and support must both clear their flat curves for the whole confirm period.
Confirm & enact
Once the tally holds above both curves through the confirm window (10 min fast lane, 24 h tech lane), the referendum is confirmed and enacts after the min-enactment delay. Runtime upgrades authorize the wasm hash via System.authorize_upgrade — the wasm itself is then applied permissionlessly and version-checked.
Cancel / kill
Only Root (i.e. a previously passed referendum) can cancel or kill. Slashed deposits are burned, not redirected.
Caps: 128 referenda chain-wide, 8 per account, 100 queued per track. The scheduler agenda slots each referendum's timeout and enactment — which is why stale submissions cost storage until they time out.
Treasury
TreasuryPallet (runtime pallet index 15) is a minimal stub: its only dispatchable is set_treasury_account (Root) — there are no on-chain spend proposals. The configured treasury account is expected to be a multisig in real deployments; outflows move as ordinary signed transfers from that account.
Checking the on-chain record for treasury activity…
Sources & method
Upstream runtime source (Quantus-Network/chain, main)
- runtime/src/governance/definitions.rs — both track windows, 61/60 and 80/80 curves, decision deposit, preimage fee model, FastUpgrade origin restriction
- runtime/src/configs/mod.rs — submission deposit, 45-day timeout, member bounds, Votes/Tally wiring, slash-burn
- runtime/src/lib.rs — 12s block time, UNIT, fee scale 1/10
- runtime/src/genesis_config_presets/mod.rs — 5-member floor, genesis seed design
Chain data
- Referendum events, governance extrinsics, and runtime upgrades: public Subsquid indexer
sqm.quantus.com/v1/graphql, snapshotted byscripts/fetch-governance-data.mjsintodata/governance.json. - The indexer is allowlisted for official Quantus domains only, so this page reads the same-origin snapshot — the snapshot timestamp is shown in the header, and nothing is shown rather than invented when data is missing.
- Tally units are displayed exactly as the indexer reports them (8 ayes / 0 nays on referendum #0 — eight member votes, one per member).