# Operate Voting Power

Source: https://docs.settlemint.com/docs/operators/token-features/voting-power
How operators use Voting Power delegation and timestamp-based governance snapshots for DALP assets.



Use this guide when you operate Voting Power after an asset is live. Before a vote, confirm the feature is attached and ask holders to delegate. Then choose the governance snapshot timepoint and read the resulting weights.

For the canonical product model, limits, and event signals, see [Voting Power architecture](/docs/architects/components/token-features/voting-power). For endpoint paths and request bodies, see [Voting Power API reference](/docs/api-reference/token-features/voting-power).

## When it attaches [#when-it-attaches]

Equity, employee-equity-award, real-estate, fund, and private-equity-fund templates attach voting-power. See the [system templates catalog](/docs/operators/asset-creation/system-templates).

## What you configure [#what-you-configure]

Nothing during asset creation. The feature has no operator-configurable parameters. The Asset Designer marks it as self-contained.

## What you operate [#what-you-operate]

After deployment:

1. Ask holders to delegate to themselves or another OnchainID before the governance snapshot. Undelegated balances do not carry active voting power.
2. Choose the snapshot timepoint when the governance process opens a vote. Voting Power uses the token feature clock, which is timestamp-based, so record a timestamp after the expected delegation events.
3. Run the off-chain voting process against the recorded weights. The platform supplies the eligibility list and weights; the voting tool collects ballots. A later delegation does not change an earlier snapshot.
4. Record the vote outcome outside DALP. The platform does not record vote results, only voting weights.

## Operating considerations [#operating-considerations]

* Voting Power tracks delegated governance weight. Use Historical Balances separately when the governance process also needs balance checkpoints for holder or supply review.
* Voting weights track holder balance, not holder count. A holder with 100 tokens has 100 voting units against a holder with 1 token.
* Delegation is asymmetric: a holder can delegate to one OnchainID at a time. Re-delegating overrides the previous delegation.
* Vote-result tabulation, proxy collection, and resolution drafting run outside DALP through your normal governance process.

## Troubleshooting [#troubleshooting]

| What you see                       | What to check                                                                                                                         |
| ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| Snapshot returns zero weights      | Confirm the timestamp timepoint is after the asset deployment and after the holder balances or delegation events you expect to count. |
| Delegation does not change weights | Confirm the on-chain delegation has confirmed and the snapshot timepoint is after the delegation timestamp.                           |
| Voting weight off by a factor      | Confirm the snapshot read uses the same precision (token base units) the governance process expects.                                  |

## Read next [#read-next]

* [Voting Power architecture](/docs/architects/components/token-features/voting-power)
* [Historical Balances](/docs/operators/token-features/historical-balances) for balance checkpoint workflows that may sit beside Voting Power.
* [System templates catalog](/docs/operators/asset-creation/system-templates)