Gauge voting

Gauge voting is a non-proposal governance capability for signaling how voting power should be distributed among a set of destinations. Its Gauge Voter plugin does not create IProposal proposals: during an epoch's voting window, eligible holders allocate their voting power across one or more active gauge addresses. The result is non-binding within the plugin by default, and Gauge Voter does not itself execute DAO actions. One use of Gauge vote outcomes is separately arranged reward distribution through Capital Distributor.

Availability and related capabilitiesCopy Anchor Link

Gauge voting uses an Aragon-deployed plugin. The app supports the installed instance; the team handles deployment because the Governance Designer has no self-service setup for it. Contact the Aragon team to arrange a Gauge Voter deployment.

veLocker is related because its adapter can supply time-varying voting power, but locking positions and allocating that power to gauges are separate capabilities. A configured Gauge-reward path calculates pro-rata allocations and exports campaign-preparation input for Capital Distributor. This demonstration is not a generic self-service integration: Gauge Voter does not automatically create or pay a campaign.

Allocating voting powerCopy Anchor Link

During the configured voting window, a voter selects active gauges and enters a relative weight for each. The contract normalizes every submitted weight against the total and allocates the voter's available power proportionally. For a nonzero allocation, the app displays the resulting percentages to two decimal places, using largest-remainder rounding so the displayed set totals 100%; that presentation rounding is not a second voting rule. Submitting another allocation replaces the voter's previous set in the current write epoch or persistent state.

Epoch behavior depends on the installed contract's update-hook setting:

• Persistent mode stores the allocation in the contract's epoch-zero state, so votes carry across epochs. With a compatible escrow hook, a persistent allocation can be recalculated downward after reported voting power falls; increased power is not added automatically and requires a manual vote during a voting window.
• Epoch-scoped mode stores votes against the current epoch and uses voting power snapshotted at the epoch start. The voter must allocate again in a later epoch.

Gauges pageCopy Anchor Link

The Gauges page shows the gauge list, per-gauge details in a dialog, epoch timing and totals, the connected holder's voting power and usage, and an update-vote flow. Holders select gauges and use the allocation control to submit or replace their votes during the voting window. Gauge details expose the destination's name, address, description, resources, and participation so a holder can inspect it before allocating power. The contract link opens the gauge address in its network's block explorer. Resource links display their labels and open their destinations without an app URL preview.

An installed Gauge Voter gets one Gauges page at /gauges and one navbar entry, not a route for each gauge. App CMS can hide that navigation entry; a direct visit then redirects to the account dashboard. The current page selects only the first installed Gauge Voter instance, so multiple instances on one account are not supported by this interface.

The page offers a Gauge-specific Lock form and the same Delegate form described by the Token panel. For a recognized Aragon voting escrow, its aside offers both forms. For a third-party escrow, the current app has no native escrow settings and omits both the Lock form and the connection-time Lock/Wrap prompt; locking happens outside this interface. This is a current UI boundary, not a claim about the external escrow's capabilities or support status.

Third-party voting-escrow integrations require Aragon to assess the specific contracts for compatibility.

Gauges and their administrationCopy Anchor Link

Each gauge is identified by an address and may carry a metadata URI. Its metadata holds a name, description, and resources, with an optional gauge avatar. In the current contract and app, the permission is literally GAUGE_ADMIN. Its Action Builder group exposes purpose-built create and detail views for four management actions:

• Create a gauge from its address and metadata URI.
• Deactivate an existing gauge so it cannot receive new votes.
• Reactivate a deactivated gauge.
• Update metadata for an existing gauge.

A created gauge remains in the enumerable list; deactivation retires it from receiving votes, and reactivation restores that eligibility. Metadata updates describe the same gauge address. These actions use the action builder; the gauge action catalogue summarizes when to choose each one. Holding GAUGE_ADMIN authorizes gauge management; Gauge Voter retains its role as a non-proposal governance plugin.

BENQI lending-market gauges use a separate, BENQI-specific registration integration alongside the shared Gauge Voter.

Management-form validationCopy Anchor Link

Create requires a valid gauge address, a name of up to 128 characters, and a description of up to 480 characters. Update metadata requires an existing gauge and the same name and description fields. Both forms use the shared resource and avatar inputs. Deactivate selects from active gauges; Reactivate selects from inactive gauges. Metadata updates can select either state.

Address-format validation does not check whether a gauge address is zero or already exists. Use a nonzero, unused address when creating a gauge. A selected gauge's state can also change before execution; the selection filter does not guarantee that the proposed lifecycle change will still be valid. Review the action against the target instance and use simulation when available.