Crate dao_voting_token_staked
source ·Expand description
dao_voting_token_staked
Simple native or Token Factory based token voting / staking contract which assumes the native denom provided is not used for staking for securing the network e.g. IBC denoms or secondary tokens (ION). Staked balances may be queried at an arbitrary height. This contract implements the interface needed to be a DAO DAO voting module.
Token Factory support
dao_voting_token_staked
leverages the cw_tokenfactory_issuer
contract for tokenfactory functionality. When instantiated, dao_voting_token_staked
creates a new cw_tokenfactory_issuer
contract to manage the new Token, with the DAO as admin and owner (these can be renounced or updated by vote of the DAO).
The cw_tokenfactory_issuer
contract supports many features, see the cw_tokenfactory_issuer contract README for more information.
Instantiation
When instantiating a new dao_voting_token_staked
contract there are two required fields:
token_info
: you have the option to leverage anexisting
native token or creating anew
one using the Token Factory module.
There are a few optional fields:
unstaking_duration
: can be set toheight
ortime
(in seconds), this is the amount of time that must elapse before a user can claim fully unstaked tokens. If not set, they are instantly claimable.active_theshold
: the amount of tokens that must be staked for the DAO to be active. This may be either anabsolute_count
or apercentage
.
Create a New Token
token_issuer_code_id
: must be set to a valid Code ID for thecw_tokenfactory_issuer
contract.initial_balances
: the initial distribution of the new token, there must be at least 1 account with a balance so as the DAO is not locked.
Creating a token has a few additional optional fields:
metadata
: information about the token. See Cosmos SDK Coin metadata documentation for more info on coin metadata.initial_dao_balance
: the initial balance created for the DAO treasury.
Example insantiation mesggage:
{
"token_info": {
"new": {
"token_issuer_code_id": <cw_tokenfactory_issuer_code_id>,
"subdenom": "meow",
"metadata": {
"description": "Meow!",
"additional_denom_units": [
{
"denom": "roar",
"exponent": 6,
"aliases": []
}
],
"display": "meow",
"name": "Cat Token",
"symbol": "MEOW"
},
"initial_balances": [
{
"amount": "100000000",
"address": "<address>"
}
],
"initial_dao_balance": "100000000000"
}
},
"unstaking_duration": {
"time": 100000
},
"active_threshold": {
"percentage": {
"percent": "0.1"
}
}
}
Use Existing Native Token
dao-voting-token-staked
can also be used with existing native tokens. They could be in the form of a native denom like ion
, an IBC token, or a Token Factory token.
Example insantiation mesggage:
{
"token_info": {
"existing": {
"denom": "uion",
}
}
}
NOTE: if using an existing Token Factory token, double check the Token Factory admin and consider changing the Token Factory to be the DAO after the DAO is created.
Use a factory
Occassionally, more customization is needed. Maybe you want to have an Augmented Bonding Curve contract or LP pool that requires additional setup? It’s possible with factory contracts!
The factory
pattern takes a single WasmMsg::Execute
message that calls into a custom factory contract.
NOTE: when using the factory pattern, it is important to only use a trusted factory contract, as all validation happens in the factory contract.
Those implementing custom factory contracts MUST handle any validation that is to happen, and the custom WasmMsg::Execute
message MUST include TokenFactoryCallback
data respectively.
The dao-test-custom-factory contract provides an example of how this can be done and is used for tests. It is NOT production ready, but meant to serve as an example for building factory contracts.