A holder vote that carries out what it decided
A governance vote asks a token's holders to approve a decision, weighted by holdings on a record date, and a passing vote can execute the change after a delay.
DALP 3.2 adds proposals, ballots, tallies, and timed execution to holder voting power. A successful resolution can apply an approved change to the token.
A vote that passes can change the token, and it does so after a delay every holder can see
Voting power attaches to an instrument as a feature, the same way a compliance rule or a yield program attaches. What is new is the machinery around it: a vote, the ballots cast on it, the tallies, and the execution that follows.
- Weight
- Read from the register at a record date
- Quorum
- Counts every ballot cast, abstentions included
- Approval
- Ignores abstentions and can only tighten a majority
- Execution
- Runs through a timelock you configure
What was missing was the vote itself
DALP 3.1 provided voting power and delegation. Holders could accumulate voting weight and delegate it, but the platform did not yet provide proposals, ballots, or execution of voting outcomes.
The platform adds a governor contract and timelock, records on-chain ballots and tallies, and exposes the lifecycle through the API and Console.
Resolution, multi-option resolution, and poll
A vote is created as one of three types, and the choice decides what the vote can do rather than how it looks.
A resolution asks holders to approve or reject one decision. Ballots are For, Against, or Abstain, each with an optional reason.
A multi-option resolution asks holders to choose between named options. It succeeds on quorum alone, and the winning option is read from the tallies rather than judged against a threshold.
A poll records signed ballots off the ledger. Each ballot is signed by the holder's wallet and verified, so a poll is still evidence of who said what, but it never reaches the queue and execute machinery. Use it to gauge opinion before committing to a vote that binds.
Resolutions and multi-option resolutions can include token changes. A poll records opinion without executing a change.
The register at a record date decides the weight
A ballot's weight is not the holder's balance today. It is their voting power as of the vote's record date, a future date set when the vote is created, so a holder cannot acquire weight after seeing how a vote is going.
Two conditions decide whether a holder can vote at all. Their voting power has to be activated, and it must not be delegated to somebody else on that date. A holder who delegated away can delegate back to themselves at any time, but the change only counts for a vote whose record date falls after they do. When a holder cannot vote, the Console names which of these is the reason rather than showing an inert button.
Integrators reading entitlement themselves have a matching endpoint: voting power per holder as it stood at a chosen past block, which is the same reading the vote uses.
Quorum and approval measure different things
Both are set in basis points, meaning hundredths of a percent, where ten thousand basis points is all of the token's voting power. Quorum and approval use different totals.
Quorum asks whether enough of the register turned up. It sums the weight of every ballot cast, including abstentions, and compares that to the configured floor. An abstention is participation, so it helps a vote reach quorum without supporting it.
The approval threshold asks whether the decision won. For must exceed Against outright. Where a threshold is configured, For must also reach that share of the For and Against weight combined, with abstentions excluded from the arithmetic. The threshold can only tighten the simple majority, never loosen it, so nobody can configure a vote that passes on a minority.
Creating a vote with a quorum higher than the voting power currently activated raises a warning at that moment, because such a vote cannot pass unless more holders activate before the record date.
A vote that carries its own change
This is the part that separates a governance vote from a survey. A resolution can carry one or more changes to the token, composed from a catalog of operations the platform knows how to encode: a new supply cap, a revised fee rate, a scheduled maturity date, and others.
The platform checks, while the vote is being created, that the timelock already holds the authority those changes need, and offers to grant it if it does not. That check is what stops a vote from passing and then failing at the moment it matters. Where the authority is still missing at execution, the failure names the timelock and the missing role rather than reporting a bare transaction revert.
A vote that succeeds is queued onto the timelock, which starts the execution delay set when the vote was created. After the delay, executing it applies everything the vote holds in one transaction. Execution is final. What it changes applies to the token from that moment: anything the ledger settled before it landed keeps the old terms, and anything settled afterwards reads the new ones.
Tallies that survive a chain reorganisation
The platform stores on-chain ballots and lifecycle events and derives tallies from them. A chain reorganization corrects the affected records and rebuilds the tallies.
The ballots behind any vote can be listed, and exported, so the tally on the screen can be checked against the ballots that produced it.
Compatibility and breaking changes
This release adds routes and Console surfaces. It changes no existing request or response shape, the frozen v1 surface is untouched, and an instrument issued before this line keeps the features it was issued with.
Voting power and delegation, both available in 3.1, are unchanged. The endpoints that read delegations and distribution work exactly as before. What changed around them is that delegation now has a consequence: delegating away is a named reason a holder cannot cast their own ballot.
This release deprecates nothing in governance. No route, field, or error is being retired, so no removal date applies.
Because the governor and timelock contracts are new in this line and not yet part of the frozen contract surface, their on-chain shapes can still change before the version is cut. Read the current definitions from the API rather than pinning to a shape captured during an evaluation.
What this does not do
A multi-option vote that ends in a tie has no on-chain resolution. The winning option is read from the tallies rather than decided by the contract, and a tie reports no winner. Deciding what happens next is your governance process, not the platform's.
A ballot is final once cast. Holders cannot change or withdraw it.
A queued vote has no expiry. Nothing pushes it out of the queue, so it waits, ready to execute, until somebody executes or cancels it.
Delegation counts from the record date forward, not retroactively, so a holder who reclaims their own weight after a record date has passed still cannot vote on that particular vote.
Availability
Governance runs on the versioned public API and on the Console, with no flag to enable. A token needs voting power attached before it can carry a vote, and voting power attaches at issue like any other feature. Creating a vote on a token that has no governance component deploys one first, then submits the vote.
Understand composable tokens → · Run a vote in the Console → · See how roles are granted →
Corporate actions
Thirteen corporate-action types such as cash dividends and stock splits are recorded objects: enter the terms, read the effect on every holder, then confirm.
Instrument catalog
The catalog of instrument shapes grew from twenty-four to thirty-three, adding two sukuk structures, a digital asset class, a spot commodity, and more.