# Voting power

Source: https://docs.settlemint.com/docs/operators/token-features/voting-power
How the voting-power token feature exposes delegated voting and governance snapshots for equity, fund, and real-estate assets on DALP.



The voting-power token feature exposes delegation and snapshot-based voting weights for governance flows. The feature pairs with historical-balances so an off-chain governance process can read voting weights at a specific block (the snapshot block) and rely on those weights staying fixed across the voting window.

For the architecture reference, see [Voting power](/docs/architects/components/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:

* **Take a snapshot block** when the corporate-action process opens a vote. The voting-power feature uses historical-balances to expose holder voting weights as of that block.
* **Run the off-chain voting process** against the snapshot weights. The platform supplies the eligibility list and weights; the voting tool collects ballots.
* **Holders can delegate** their voting power to another OnchainID through the platform's delegation flow. Delegations apply forward; an existing snapshot's weights remain frozen at the snapshot block regardless of later delegation changes.
* **Record the vote outcome** outside DALP. The platform does not record vote results, only voting weights.

## Operating considerations [#operating-considerations]

* The voting-power feature requires historical-balances. The composition rules attach historical-balances automatically when voting-power is selected.
* 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 snapshot block is after the asset deployment and that historical-balances attached (the wizard attaches it automatically with voting-power). |
| Delegation does not change weights | Confirm the on-chain delegation has confirmed and the snapshot block is after the delegation block.                                                      |
| 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) — required companion feature.
* [System templates catalog](/docs/operators/asset-creation/system-templates)