# Voting Power

Source: https://docs.settlemint.com/docs/architects/architecture/components/token-features/voting-power
Voting Power adds delegated, checkpointed voting weight to DALPAsset tokens for governance contracts that read current or past votes.



Voting Power lets a DALPAsset token participate in on-chain governance without moving the asset. Balances provide voting units through token hooks, but those units count as active votes only after the holder delegates them to themselves or to another address.

Add this feature when you need Governor-compatible vote reads, historical proposal snapshots, or a delegation model where holders can vote directly or assign their weight. The governance contract or operating process decides how those recorded votes are used.

## When to use voting power [#when-to-use-voting-power]

Add Voting Power when a token needs one of these behaviours:

* proposals that read current or past voting weight
* delegation where holders vote directly or assign their weight to another address
* a checkpointed record of governance units over time

Do not use Voting Power as a transfer control, fee feature, or policy module. It does not approve transfers or rewrite amounts.

## How voting weight becomes active [#how-voting-weight-becomes-active]

<Mermaid
  chart="flowchart TD
    Holder[Token holder] --> Balance[Token balance becomes voting units]
    Balance --> Delegation{Holder delegates?}
    Delegation -->|No| NoVotes[No active voting power]
    Delegation -->|Self or another address| Votes[Delegate receives voting power]
    Votes --> Snapshot[Governance contract reads votes at a timestamp timepoint]
    Transfer[Mint, burn, redeem, or transfer] --> Checkpoint[Feature updates voting checkpoints]
    Checkpoint --> Snapshot"
/>

A holder can delegate to themselves if they want to vote directly. They can also delegate to another address. Until delegation happens, the token balance exists, but it does not carry active voting power.

The feature records checkpoint changes when token units move through mint, burn, redeem, or transfer hooks. Governance contracts can then query voting power at a past timestamp timepoint instead of relying only on the current balance.

## Capabilities [#capabilities]

| Capability                  | Who uses it                          | What it does                                                                         | Operational note                                                           |
| --------------------------- | ------------------------------------ | ------------------------------------------------------------------------------------ | -------------------------------------------------------------------------- |
| Delegate voting power       | Token holder                         | Assigns the holder's voting weight to themselves or another address                  | Delegation must happen before the governance snapshot that needs the votes |
| Delegate by signature       | Anyone with a valid holder signature | Applies delegation without the holder submitting the transaction directly            | Uses EIP-712 style signed delegation data                                  |
| Update checkpoints          | DALPAsset token hooks                | Adjusts voting units after mint, burn, redeem, or transfer activity                  | The feature does not block or rewrite the token movement                   |
| Read current and past votes | Governance contracts and operators   | Returns current votes, past votes, past total supply, and historical delegation data | Use timestamp timepoints for proposal snapshots and audit review           |

## What operators should plan for [#what-operators-should-plan-for]

* Prompt holders to delegate before the first governance snapshot. Undelegated balances do not count.
* Monitor delegation concentration. If many holders delegate to one address, that address can accumulate large voting weight.
* Use snapshot-aware governance contracts for proposals. A governance process that reads only current balances is easier to manipulate than one that reads historical voting power at a fixed timestamp timepoint.
* Place Voting Power after amount-changing fee features in the token feature order so voting checkpoints reflect the final post-fee balances.

## Limits and failure modes [#limits-and-failure-modes]

* Delegating after a proposal snapshot is too late for that proposal.
* A transfer before delegation does not create retroactive voting power.
* Enable Voting Power before holders receive balances. The feature does not seed voting units for balances that already exist, and later outgoing movements from those earlier balances can fail because the voting ledger starts at zero for those holders.
* High-frequency token movement creates more checkpoints. That is expected, but it increases on-chain storage over time.
* Disabling the feature stops future voting-power reads through the feature. Existing checkpoint data remains part of the chain history. Operators should not disable the feature while active governance depends on future reads.

## Audit signals [#audit-signals]

Voting Power emits and exposes signals that help operators and governance reviewers reconstruct who had voting weight and when.

| Signal                                                        | Meaning                                                                                  |
| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
| `DelegateChanged(delegator, fromDelegate, toDelegate)`        | A holder changed where their voting weight is assigned                                   |
| `DelegateVotesChanged(delegate, previousBalance, newBalance)` | A delegate's active voting power changed                                                 |
| `VotingUnitsTransferred(from, to, amount)`                    | Underlying voting units changed because token units moved                                |
| Past vote queries                                             | Governance can read voting power, total supply, and delegation state at a past timestamp |

## Compatibility [#compatibility]

Voting Power has no external provider dependency. The feature can be used with [Historical Balances](/docs/architects/architecture/components/token-features/historical-balances), but the two features track different questions: Historical Balances tracks token balances over time, while Voting Power tracks delegated governance weight.

Voting Power is compatible with other token features when ordered after features that change transfer amounts. The feature does not require a governance role configuration of its own.

## See also [#see-also]

* [Token Features Catalog](/docs/architects/architecture/components/token-features) for the full feature catalogue
* [Historical Balances](/docs/architects/architecture/components/token-features/historical-balances) for balance snapshots without delegation
* [Asset Contracts](/docs/architects/architecture/components/asset-contracts) for the DALPAsset role model and deployment architecture