Operate Voting Power
Attach Voting Power so token holders can delegate weight and vote in native DALP governance, with each holder's weight fixed at the vote's record date.
Voting Power gives a token the delegated weight that governance votes count. Attach it, ask holders to delegate, and the token becomes eligible for native votes that the platform runs and records end to end: on-chain resolutions, executable proposals behind a timelock, and off-chain polls.
Attach the feature, then have each holder delegate before a vote opens. To run votes, see the Governance votes runbook. For the product model and event signals, see Voting Power architecture. For endpoint paths and request bodies, see Voting Power API reference.
When it attaches
Equity, employee-equity-award, real-estate, fund, and private-equity-fund templates attach voting-power. See the system templates catalog.
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
After deployment, prepare holders, then run the vote from the Governance section:
- Ask holders to delegate to themselves or another OnchainID before the vote's record date. Undelegated balances carry no active voting power and count as zero.
- Create the vote from the Governance section in the Console sidebar. The platform deploys a dedicated governor and timelock for the token on the first vote, fixes each holder's weight at the record date, and opens the voting period. The Governance votes runbook walks through the create-vote wizard and execution.
- Let eligible holders cast ballots. They vote from the token's Governance tab, the vote detail page, or the Actions work queue. Weight is the holder's delegated voting power at the record date; balances acquired after that date do not count.
- Read the recorded outcome. The platform tallies ballots, marks the vote Succeeded or Defeated against the configured quorum, and offers a CSV export of voter address, choice, and record-date weight.
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 participant count. An account 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.
- A holder who delegated to another address has zero weight for the vote; the delegate casts the combined weight. The vote detail page explains this.
Troubleshooting
| What you see | What to check |
|---|---|
| A holder cannot vote | Confirm the holder delegated before the record date, did not delegate to another wallet, the vote is still open, and they have not already voted. |
| Weights look lower than expected | Verify the holders delegated before the record date. Activation after the record date does not count for that vote. |
| Voting weight off by a factor | Verify the weight read uses the same precision (token base units) the governance process expects. |
Read next
- Governance votes runbook to create votes, set quorum, collect ballots, and execute approved proposals.
- Voting Power architecture
- Historical Balances for balance checkpoint workflows that may sit beside Voting Power.
- System templates catalog
Operate the historical-balances token feature
How the historical-balances token feature records timestamped holder and supply checkpoints, and how operators read holders as of a past date for reporting, voting, and audit.
Operate the permit token feature
Operate the permit token feature in the Console. Create custodial EIP-2612 approvals for a spender, set a deadline, and relay stored permits on-chain.