Ds-Chiefsmart contract provides a method to elect a "chief" contract via an approval voting system. This may be combined with another contract, such as
DSAuthority, to elect a ruleset for a smart contract system.
**DSChiefApprovalsprovides the following public properties:**
slates: A mapping of
addressarrays. Represents sets of candidates. Weighted votes are given to slates.
votes: A mapping of voter addresses to the slate they have voted for.
approvals: A mapping of candidate addresses to their
deposits: A mapping of voter addresses to
uintnumber of tokens locked.
DSTokenused for voting.
DSTokenissued in exchange for locking
hat: Contains the address of the current "chief."
MAX_YAYS: Maximum number of candidates a slate can hold.
notemodifier from ds-note, meaning that they fire a standardized event when called. Additionally, one custom event is also provided:
Etch(bytes32 indexed slate): Fired when a slate is created.
DSChiefApprovals(DSToken GOV_, DSToken IOU_, uint MAX_YAYS_)
GOVtokens, issues an equal amount of
IOUtokens to the user, and adds
wadweight to the candidates on the user's selected slate. Fires a
IOUtokens, issues an equal amount of
GOVtokens to the user, and subtracts
wadweight from the candidates on the user's selected slate. Fires a
etch(address yays) returns (bytes32 slate)
slateand return a unique identifier for it.
vote(address yays) returns (bytes32 slate)
slate, moves the voter's weight from their current slate to the new slate, and returns the slate's identifier.
s/chief/hatif it has more weight than the current
DSChiefis a combination of
DSChiefApprovals. It can be used in conjunction with
ds-auth(as an authority object) to govern smart contract systems.
DSChief(DSToken GOV_, DSToken IOU_, uint MAX_YAYS_)
isUserRoot(address who) constant returns (bool)
trueif the given address is the chief.
setRootUser(address who, bool enabled)
ds-chiefcould be used as a token-weighted voting system governing another set of smart contracts that uses the
ds-roles. In a scenario such as this, "candidates" would consist of contracts changing the state of the smart contract set under governance. Such a contract being elected as ”hat" would be granted all of the permissions to execute whatever changes are necessary. The
ds-chiefcould also be used within such a contract set in conjunction with a proxy contract, such as
ds-proxyor a name resolution system like ENS for the purpose of voting in new versions of contracts.
DSChiefor other similar contracts use the same governance token by means of accepting the IOU token of the
DSChiefcontract before it is a governance token.
DSChiefcontracts (chiefA, chiefB, and chiefC) and a
chiefA.GOVthat is the MKR token. If we set
chiefB.IOU, this allows all three contracts to run using a common group of MKR.
ds-chief, n is equal to 1.
ds-chiefweighs votes according to the quantity of a voting token that has been chosen to lock up in the
DSChiefApprovalscontract. It's important to note that the voting token used in a
ds-chiefdeployment must be specified at the time of deployment and cannot be changed afterward.
votefunctions must be byte-ordered sets.
[0x0, 0x1, 0x2, ...]is valid but using
[0x1, 0x0, ...]and
[0x0, 0x0, 0x1, ...]is not. This ordering constraint allows the contract to cheaply ensure voters cannot multiply their weights by listing the same candidate on their slate multiple times.
liftis called on it. So, even if a spell gains much more MKR on it than the hat, if
liftis never called on it, the hat will remain on a spell that no longer has the most MKR. This could lower the bar for the amount of MKR needed to pass something, potentially making the system less safe.
hatto be safe against governance attacks while the voters enacting the change itself must have enough MKR in the old chief to pass the proposal.