Voting Power
Delegated voting with historical tracking on DALPAsset. Enables on-chain governance participation compatible with Governor contracts. Requires holder delegation to activate voting weight.
Purpose: Voting Power adds delegated voting with historical tracking to DALPAsset tokens. Token holders must explicitly delegate their voting weight (to themselves or another address) to participate in governance.
- Doc type: Reference
- What you'll find here: Business impact, risks, controls, failure modes, auditability, dependencies, and ordering notes
- Related:
Interface (capabilities)
This feature exposes the following capabilities. Holders must explicitly delegate their voting weight before it becomes active — undelegated tokens carry no governance power.
| Capability | Who can call | Inputs | On-chain effect | Emits | Notes |
|---|---|---|---|---|---|
| Delegate voting power | Token holder | Delegatee address (self or another) | Assigns holder's voting weight to delegatee | DelegateChanged, DelegateVotesChanged | Must delegate before governance snapshot |
| Delegate by signature | Anyone (with valid signature) | Signed delegation parameters | Assigns voting weight without holder gas | DelegateChanged, DelegateVotesChanged | Gasless via EIP-712 |
| Record checkpoints on transfer | Automatic (hook) | Triggered on mint, burn, transfer | Updates voting power checkpoints for affected delegates | DelegateVotesChanged | Only affects delegated balances |
Current and historical voting power, past total supply, and delegation status are available as read-only queries.
Business impact
- Holders: Voting power equals token balance at the time of a governance snapshot, but only if the holder has delegated (to themselves or another address). Undelegated tokens have no voting weight.
- Issuer / governance: Enables on-chain governance contracts (e.g., OpenZeppelin Governor) to query voting power at any historical block. Governance proposals can require quorum relative to total delegated power.
- Economics: No token movement. Purely governance-additive.
Risks & abuse cases
- Low participation from non-delegation: If holders do not call
delegate(), their tokens have no voting power. Governance quorum may be difficult to reach. Onboarding flows should prompt delegation. - Delegation to a single address: If many holders delegate to one address, that address gains outsized governance power. Monitor delegation concentration.
- Flash loan governance attacks: Without a snapshot-based quorum mechanism in the governance contract, a flash loan could temporarily inflate delegated power at proposal creation. Ensure governance contract uses snapshot blocks.
Controls & guardrails
| Role | Actions | Recommended guardrail |
|---|---|---|
| Holders | delegate(address) — delegate voting power to self or another | Prompt at onboarding; remind undelegated holders |
| No on-chain governance role for the feature itself | Feature has no GOVERNANCE_ROLE or CUSTODIAN_ROLE actions | — |
Failure modes & edge cases
- Transfer before delegation: A holder who transfers tokens before delegating has never had active voting power — no retroactive delegation occurs.
- Delegation after snapshot: Delegating after a governance snapshot block is too late for that proposal. Delegation must be in place at the snapshot block.
- Checkpoint bloat: High-frequency transfer tokens accumulate many checkpoints per holder. This is expected behavior but increases on-chain storage over time.
Auditability & operational signals
DelegateChanged(delegator, fromDelegate, toDelegate)— emitted on delegation change.DelegateVotesChanged(delegate, previousBalance, newBalance)— emitted on vote balance change (transfer, mint, burn with delegation active).- Historical checkpoints queryable at any block — governance contracts use these for proposal snapshot queries.
Dependencies
- No external dependencies.
- Compatible with Historical Balances — both use checkpoints independently.
- Requires governance contract integration (e.g., OpenZeppelin Governor or equivalent) to have utility.
Compatibility & ordering notes
supportsRewriting = false— no amount modification.- Order last in the feature array (after fee features). This ensures delegation snapshots reflect post-fee balances.
- Compatible with all other features. No ordering conflicts beyond the general "analytics last" convention.
Change impact
- Enable after launch: Historical delegation state starts from activation. Pre-activation transfer history does not generate checkpoint entries.
- Disable: Voting power queries stop working. Any active governance proposals that referenced this token's voting power at a past block will still resolve (checkpoints remain on-chain), but future governance is blocked.
- No configuration to change — feature has no GOVERNANCE_ROLE parameters.
See also
- Token Features Catalog — return to the full feature catalog
- Historical Balances — companion snapshot feature
- Asset Contracts — role model and deployment architecture
External Transaction Fee
Fixed fee in a separate ERC-20 token (e.g., USDC) charged on every mint, burn, or transfer. Fee is collected from the payer's allowance separately from the transferred amount.
Historical Balances
Point-in-time balance and total supply queries via on-chain checkpoints. Passive feature — no configuration, no roles, no economic impact. Required by Fixed Treasury Yield.