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.
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:
- 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
- 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
| 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
- Voting power architecture
- Historical balances — required companion feature.
- System templates catalog
Historical balances
How the historical-balances token feature snapshots holder balances at every block, and how operators use those snapshots for reporting, voting, and audit reads.
Permit
How the permit token feature enables EIP-2612 signature-based ERC-20 approvals on DALP assets, removing the need for a separate approval transaction.