Governance analytics

Referendum #90 asks whether Vara should have a network-owned pool of funds spent by referendum, by VARA holders. It is a consultation about that principle, not a proposal to approve a particular budget, tax, token allocation, beneficiary or operating team. The authenticated proposal says the runtime already has treasury software and spending tracks, and asks holders whether they want that capability put to work. The decoded call is system.remark: a short on-chain reference to the proposal text, not an instruction to create a treasury, move VARA or change the network's rules.

Referendum #89 proposes the same runtime code blob as #88, but through a different call: whitelist.dispatchWhitelistedCallWithPreimage contains utility.withWeight around system.setCode. The wrapper declares refTime 200,000,000 and proofSize 314,000. At the finalized verification block, #89 is Deciding with a decision deposit. Its distinct whitelisted-call hash matches Fellowship #74, which is still Preparing and has not whitelisted that hash.

Referendum #88 proposes a runtime upgrade: its whitelisted dispatch contains system.setCode with a 1,752,265-byte runtime code blob. The complete preimage was retrieved and its hash verified. At the finalized verification block, #88 is Preparing, has no decision deposit and has not entered decision. Fellowship #73 has separately approved and whitelisted this call; that does not approve or execute #88.

Vara token holders approved a Gear Foundation-funded $18,000 grant supporting twelve Ray0xNodes validators for twelve months.

This referendum successfully submitted the new VFT-manager registration message that failed in #85.

This referendum was approved but its dispatch failed before it could successfully submit the new manager registration message.

This proposal would have registered the new Vara VFT manager with Ethereum's ERC20Manager contract, but it timed out without execution.

This referendum passed the same unpause batch rejected in #82, reopening the Vara-side bridge pallet and submitting the new manager's unpause command.

This proposal would have unpaused both the new VFT manager and Vara's Ethereum bridge, but voters rejected it before execution.

This referendum staged the new bridge manager across Vara's five documented bridge token programs and sent the associated Ethereum governance message while returning the bridge pallet to a paused state.

This untitled referendum wrote a mainnet end-to-end test marker for the VaraGov application to the chain.

This referendum attempted to pause both the intermediate VFT manager and the Vara-side Ethereum bridge before the next migration stage.

This untitled referendum performed a large Fellowship restructuring: eleven rank increments for three retained accounts and removal of fifteen other accounts.

This Bridge Admin referendum submitted a governance message concerning the Ethereum MessageQueue contract and a new implementation address.

This referendum reopened the Vara-side Ethereum bridge pallet after the August 2026 pause sequence.

This referendum migrated Vara's existing bridged VFTs to a new VFTManager while preserving the existing token addresses, balances and supplies described by the proposer.

This referendum successfully sent the pause command that failed in referendum #73.

This referendum reached execution but failed while attempting to pause the bridge VFT manager.

This referendum paused both the Vara-side bridge pallet and the associated VFT administration program in one atomic batch.

This proposal would have paused the Vara-side Ethereum bridge pallet, but it was rejected without executing the call.

This proposal would have applied four rank increments across two Fellowship accounts, but it was rejected without execution.

This referendum resubmitted and dispatched the VFT-manager mapping that timed out in #68.

This proposal would have updated the old VFT manager's token mapping from the legacy tokenized-VARA program to its replacement, but it timed out without a vote or execution.

This referendum submitted an exit command telling the legacy tokenized-VARA program which replacement program should receive the migration.

This referendum began an early tokenized-VARA migration sequence by submitting a pause command to the legacy VFT program.

Although its public title described promoting GSOBOL and Alexander Volkov to rank 6, the decoded on-chain call scheduled a GRANDPA-signer request rather than directly calling fellowshipCollective.promoteMember.

This referendum asked Vara to dispatch the pre-approved call for runtime version 1.10.0.

This referendum reduced the Vara-side Ethereum bridge fee from the previously established 1,000 VARA to 500 VARA.

This referendum reopened the Vara-side Ethereum bridge pallet and set its bridge fee to 1,000 VARA.

This referendum upgraded Vara's on-chain runtime from spec version 1910 to 1920, corresponding to Gear v1.9.2.

This untitled second attempt carried the same runtime-1920 proposal as #59 and #61, but timed out without execution.

This was the first of three referenda carrying the same runtime-1920 proposal. Voters rejected it before execution.

This referendum burned the accumulated 22,526,355.840659541372 VARA inflation offset and returned total issuance to exactly 10 billion VARA.

This referendum upgraded Vara's on-chain runtime from spec version 1820 to 1910, corresponding to Gear v1.9.1.

This referendum reduced Vara's target staking inflation rate from 6% to 5.5%.

This referendum upgraded Vara's on-chain runtime from spec version 1810 to 1820, corresponding to Gear v1.8.2.

This referendum proposed moving a 45,000,000 VARA vesting schedule from kGhzR5…LgXuW7 to kGkJDV…dBC2tC. The atomic batch executed successfully.

This referendum upgraded the live Vara runtime from specification version 1710 to 1810.

This referendum increased Vara's configured validator count by 1, from 58 to 59.

This proposal would have added one active-validator slot, but it was rejected before the identical call passed as referendum #52.

This was the second rejected attempt to add one slot to Vara's configured validator count.

This was the first rejected attempt to add one slot to Vara's configured validator count.

This referendum increased Vara's configured active-validator count by two slots.

This referendum upgraded Vara's on-chain runtime from spec version 1700 to 1710, corresponding to Gear v1.7.1.

This referendum proposed moving a 45,000,000 VARA vesting schedule from kGjFXt…Ew47t3 to kGiDJB…QXxMeb. The atomic batch executed successfully.

This referendum proposed moving a 45,000,000 VARA vesting schedule from kGjFXt…Ew47t3 to kGiDJB…QXxMeb. The referendum timed out before the batch was executed.

This referendum proposed moving a 45,000,000 VARA vesting schedule from kGjFXt…Ew47t3 to kGiDJB…QXxMeb. The referendum reached execution, but the dispatched batch returned a module error and did not complete successfully.

This proposal asked token holders to signal support for giving nomination-pool stake voting power, but it timed out and recorded no approved signal.

This Root-track proposal was described as taking the ideal validator count to 64 by adding seven slots, but it timed out without execution.

This Root-track proposal would have set Vara's ideal active-validator count to 57, but it timed out without execution.

This referendum upgraded Vara's on-chain runtime from spec version 1620 to 1700, corresponding to Gear v1.7.0.

This referendum proposed moving a 107,000,000 VARA vesting schedule from kGj9Bp…jgEjEF to kGjcvb…9vYx1u. The atomic batch executed successfully.

This referendum proposed moving a 107,000,000 VARA vesting schedule from kGj9Bp…jgEjEF to kGjcvb…9vYx1u. The referendum reached execution, but the dispatched batch returned a module error and did not complete successfully.

This referendum proposed moving a 107,000,000 VARA vesting schedule from kGj9Bp…jgEjEF to kGjcvb…9vYx1u. The referendum timed out before the batch was executed.

This referendum upgraded the live Vara runtime from specification version 1501 to 1620.

This referendum upgraded Vara's on-chain runtime from spec version 1500 to 1501.

This referendum increased Vara's configured validator count by 1, from 55 to 56.

This referendum upgraded the live Vara runtime from specification version 1421 to 1500.

This referendum reused the exact proposal hash from the successful runtime-1500 upgrade, but its much later dispatch failed and made no runtime change.

This referendum upgraded the live Vara runtime from specification version 1420 to 1421.

This referendum upgraded the live Vara runtime from specification version 1410 to 1420.

This referendum upgraded Vara's on-chain runtime from spec version 1400 to 1410, corresponding to Gear v1.4.1.

This referendum upgraded the live Vara runtime from specification version 1310 to 1400.

This referendum upgraded the live Vara runtime from specification version 1300 to 1310.

This referendum upgraded the live Vara runtime from specification version 1210 to 1300.

This referendum upgraded the live Vara runtime from specification version 1200 to 1210.

This referendum upgraded the live Vara runtime from specification version 1110 to 1200.

This referendum reduced total issuance by 3,851.083448969781 VARA, returning the network to exactly 10 billion VARA.

This referendum upgraded the live Vara runtime from specification version 1050 to 1110.

This referendum upgraded the live Vara runtime from specification version 1040 to 1050.

This referendum upgraded the live Vara runtime from specification version 1030 to 1040.

This referendum cancelled two proposals identified as incorrect: the era-327 slash-index-1 proposal #15 and opaque weighted-call proposal #17.

This referendum upgraded the live Vara runtime from specification version 1020 to 1030.

This untitled referendum proposed a weighted utility call, but its nested action is missing from the archive and referendum #19 cancelled it before execution.

This referendum cancelled the first indexed deferred slash recorded for staking era 341.

This separate proposal would have cancelled slash index 1 from the same staking era, but it was itself cancelled and never executed.

This referendum successfully repeated the slash cancellation that #13 approved but could not dispatch with its original origin.

Voters approved cancelling one deferred slash from era 327, but the direct Staking Admin call failed with BadOrigin.

This referendum set the maximum commission a nomination pool may charge to 10%.

This referendum successfully executed the nomination-pool configuration that #9 had proposed on the wrong track.

This referendum cancelled nomination-pool proposal #9 because it had been submitted on the wrong governance track.

This untitled proposal would have raised the per-pool member ceiling to 50,000 while retaining the raw commission value of 10, but referendum #10 cancelled it for using the wrong track.

This referendum increased Vara's configured validator count by 2, from 53 to 55.

This referendum upgraded the live Vara runtime from specification version 1010 to 1020.

This referendum upgraded the live Vara runtime from specification version 1000 to 1010.

This referendum raised or established the minimum stake required for a direct nominator at 50 VARA.

This referendum configured two entry thresholds for nomination pools and wrote a very small raw commission-cap value.

This referendum upgraded Vara's on-chain runtime from spec version 340 to 350, corresponding to Gear v0.3.5.

This untitled referendum tried to dispatch the same unresolved whitelisted call hash referenced by #1, but the call failed.

This untitled referendum approved dispatching a very large whitelisted call, but the surviving archive does not contain its preimage or a later execution result.

This referendum asked Vara to set the network's validator count to 25.