Global Governance Proposals
This page provides an overview of Webb global governance specific proposals, the proposal structure and the intended use.
Collectively, there are 4 distinct global governance proposals as you can see from the table below. A proposal simply is a message that is voted on which suggests a change in the merkle roots or system. Proposals can be unsigned and unsigned. Below are all global governance proposals that the DKG protocol handles.
| Proposals | Description |
|---|---|
| Refresh (Governance) | Proposal to refresh a contract's governor |
| AnchorUpdate (Governance) | Proposal to update merkle roots |
| ResourceIdUpdate (Governance) | Proposal to add/update a resource ID |
| ProposalSetUpdate (Governance) | Proposal to update the latest proposer set state |
Definitions
Typed Chain ID
A unique Webb-specific chain identifier that is composed of a chain / virtual machine type and the respective identifier.
Size: 6 bytes
Target System
Relevant for identifying the actual resource / system / contract that is being targeted in the proposal lifecycle.
Size: 26 bytes
Resource ID
Relevant for identifying the system the proposal is being executed on and interacting with. The resource ID contains the target system and the target chain ID to be communicated with.
Size: 32 bytes
Structure: (TargetSystem, TypedChainId)
FunctionSig
Relevant for EVM networks where call data is generic and not directly executable at a specific function.
Size: 4 bytes
Nonce
Relevant for tracking updates to contracts.
Size: 4 bytes
Proposal Header
Size: 40 bytes
Structure: (**Resource ID, FunctionSig, Nonce)
Proposals
AnchorUpdateProposal
| Protocol | Doc | Byte Size | Arguments |
|---|---|---|---|
| EVM | Proposal Docs (opens in a new tab) | Total Size: 104 bytes | 1. ProposalHeader (40 bytes) 2. Merkle root (32 bytes) 3. Source ResourceID (32 bytes) |
| Substrate | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call (opens in a new tab) 1. ProposalHeader (40 bytes) 2. Merkle root (32 bytes) 3. Source ResourceID (32 bytes) |
| Cosmwasm | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call (opens in a new tab) 1. ProposalHeader (40 bytes) 2. Merkle root (32 bytes) 3. Source ResourceID (32 bytes) |
| ink! | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call (opens in a new tab) 1. ProposalHeader (40 bytes) 2. Merkle root (32 bytes) 3. Source ResourceID (32 bytes) |
ResourceIdUpdateProposal
| Protocol | Doc | Byte Size | Arguments |
|---|---|---|---|
| EVM | Proposal Docs (opens in a new tab) | Total Size: 92 bytes | 1. ProposalHeader (40 bytes) 2. New resource ID (32 bytes) 3. Handler address (20 bytes) |
| Substrate | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call for a specific handler pallet 1. VAnchor handler pallet call (opens in a new tab) |
| Cosmwasm | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call (opens in a new tab) 1. ProposalHeader (40 bytes) 2. New resource ID (32 bytes) 3. Handler address (20 bytes) |
| ink! | Proposal Docs (opens in a new tab) | Total Size: ≥ 40 bytes | Encoded call (opens in a new tab) 1. ProposalHeader (40 bytes) 2. New resource ID (32 bytes) 3. Handler address (20 bytes) |
Refresh
| Protocol | Doc | Byte Size | Arguments |
|---|---|---|---|
| DKG | Proposal Docs (opens in a new tab) | Total Size: 68 bytes | 1. Public key (64 bytes) 2. Nonce (4 bytes) |
ProposerSetUpdate
| Protocol | Doc | Byte Size | Arguments |
|---|---|---|---|
| DKG | Proposal Docs (opens in a new tab) | Total Size: 48 bytes | 1. Merkle root (32 bytes) 2. Average session length (8 bytes) 3. Number of proposers (4 bytes) 4. Nonce (4 bytes) |
How proposals are signed
The below sequence diagram illustrates the steps required to successfully submit an Anchor Update Proposal for signature.
- Proposers propose an anchor update
- Proposers vote to either reject or acknowledge the proposal
- If the majority vote to reject, the execution is canceled and the proposal rejection event is emitted
- If the majority vote in favour of the proposal, the execution to have that proposal signed begins
- The proposal is inserted into an Unsigned Proposal Queue
- The DKG-gadget an offchain service worker, fetches the unsigned proposal from the queue
- The DKG-gadget sends messages to all connected peers to be signed in the given or next round
- Upon the completion of the round, the now signed proposals are processed and stored in offchain storage
- The Proposal-Handlers offchain worker then fetches signed proposals
- The proposals signatures are validated and inserted into pallet storage
- A ProposalSigned event is emitted indicating a successfully submitted proposal
Supported Proposals
The current DKG implementation manages the following proposals, each specify a unique change to the system that must be signed in order for any of these requested updates to be considered valid.
| Proposals | Description |
|---|---|
| Refresh | Proposal to refresh a contract’s governor |
| AnchorUpdate | Proposal to update merkle roots |
| SetVerifierProposal | Proposal to set a verifier address |
| TokenAdd | Proposal to add token to a set |
| TokenRemove | Proposal to remove token from a set |
| WrappingFeeUpdate | Proposal to update fee parameter |
| RescueToken | Proposal to move tokens from a Treasury |
| MaxDepositLimitUpdate | Proposal to update a maximum deposit limit parameter |
| MinWithdrawalLimitUpdate | Proposal to update a minimum withdrawal limit parameter |
| FeeRecipientUpdateProposal | Proposal to update a fee recipient account |
| SetTreasuryHandlerProposal | Proposal to set a treasury handler address |
| ResourceIdUpdate | Proposal to add/update a resource ID |
| ProposalSetUpdate | Proposal to update the latest proposer set state |