Asset Holder Governance
Holders of a tokenised asset vote on decisions about that asset, and the result binds the asset’s multisig.
What it does
Decisions about an asset — selling it, refinancing it, changing its manager — go to the people who hold it. Proposals can come from the issuer, from the client platform, or from holders above a set share. Votes are counted at a snapshot taken when the vote is called, so buying tokens afterwards adds nothing, and each investor votes once across all their wallets. Ordinary resolutions need a majority and special resolutions need 75 per cent, and both need a minimum turnout. What makes it binding rather than advisory: for the matters an asset reserves, that asset’s multisig cannot act — even with every signature — unless holders approved that exact action, and even then it waits out a delay first. The multisig also cannot change its own signers or hand the token to someone else without a vote. In development.
How it works
Asset Holder Governance governs one asset, not the ecosystem — that is AI-Powered DAO Governance’s job. It reads holdings from the asset’s token and leans on Timelock & Execution for the delay an approved action waits out before it can run.
Select a step to replay it. Hover to pause.
Step 1 of 3: Propose. The issuer, the client platform or holders above a set share put a decision to the holders.
Key capabilities
Snapshot voting by verified holders
Voting power is fixed when the vote is called, so tokens bought afterwards carry none. Each investor votes once across every wallet they hold.
Ordinary and special resolutions, with quorum
Ordinary resolutions pass on a majority and special ones on 75 per cent, and neither passes without a minimum turnout.
Binding on the asset’s multisig
On a reserved matter the multisig cannot act without an approving vote for that exact action, however many signatures it gathers.
Reserved matters set per asset
Each asset lists the decisions its holders must approve, so what is reserved reflects that asset rather than a single house rule.
Execution delay and single-use approvals
An approved action waits out a delay before it can run, and the approval is spent once it is used.