This section provides details on the solidity contracts that are part of DIRT.
- Green Contracts: Has user methods for registry reading/writing and voting
- Orange Contract: Has user methods for trading tokens
Creates instances of registries and stores a (key : address) pair. Calls
RegistryFactory to deploy new instances. It follows a similar contract to other registries but
address instances instead of
The RootRegistry contract is sufficient to discover the other contracts as it provides the public state variable
A simple (key : value) contract for storing global configuration data. Typically used to store the address of contracts during deployment. Other contracts depend on this to get the active location of:
VotingContracts (see below)
This is designed for ease of contract development, but also migration to updated versions of contracts when needed.
Many contracts reference
Parameters, but the reference arrows have been left out in the diagram above for clarity.
ERC20 Smart Contract for protocol tokens. Tokens are used for staking registry items on creation, challenging and voting.
A registry where items an be created with a stake (in DIRT tokens) and an owner. Only the owner can delete items they have created. Deletion of items refunds the stake.
Items can be challenged with votes, enabling token holders to vote on the outcomes. A Challenge is created from this contract, but all voting is handled at the
configured "vote style" contract, which is fetched from the
Parameters contract. The
voteStyle address is expected to return an instance of
An abstract interface that describes a mechanism for creating a vote challenge against a registry
item. Typically a vote controller will administer many votes for many registries via an assigned
Factory for deploying new instances of
ChallengeableRegistry with a configured
A library for calculating the amount to be claimed for each candidate and voter in a vote, once a winner has been determined.
A voting controller that is a public vote where all information is visible.
A voting controller where users first commit a hash of there vote, along with the voting stake; during the first period. Then reveal there vote during the reveal period. Reveal will validate the hash of the reveal against the previously commited hash.
CommitRevealVoteController, but requires an additional
commit stake for the commit calls for voters. The
commit stake is refunded when the
reveal is called by voters.