Hatch Parameters
TEC Hatch DAO Implementation Specification
Introduction
The Token Engineering Commons hopes to advance the field of token engineering by creating a purpose driven economy that will curate and fund TE projects with an aligned focus.
The intention is to launch first as the TEC Hatch DAO and potentially upgrade to a Commons which will include an Augmented Bonding Curve and Conviction Voting. However, this is up to the will of the TEC Hatch DAO and the Commons upgrade is not in the scope of this document. This specification is solely for the initial deployment of the TEC Hatch DAO.
The TEC Hatch DAO will have two main phases. First the Hatch where funds will be sent into the TEC Hatch DAO and TECH tokens will be minted. After the Hatch, the TEC Hatch DAO will be live and have the ability to vote on how to use these funds to best execute on their mission. This document is somewhat technical in nature, but it is the single source of truth for what is being deployed and is intended to be referenced whenever describing how the TEC Hatch DAO works.
Implementation
Governance structure
Token holders
Holders of Token Engineering Commons Hatch DAO Tokens control the funds sent to the Hatch collectively and individually and can take part in key governance decisions of the project.
Rights and privileges
The initial privileges:
Using Dandelion Voting to control the funds in both the Redeemable and the Non-redeemable Agent applications.
Using Dandelion Voting to upgrade the smart contract system that underlies the DAO.
As long as TECH token holders have not voted yes on a proposal yet to be executed, TECH token holders can redeem their tokens and withdraw their proportional share of funds held by the Redeemable Agent application.
Application Configurations
Token and Token Manager
Token symbol: TECH
Token name: Token Engineering Commons Hatch Token
Decimals: 18
How divisible the base unit of the token can be. If the Decimals is 18, then you can divide 1 token by 10^18
Transferable: No
Dandelion Voting
Percentage of tokens need to vote yes (of the tokens that were used to vote) for a proposal to Pass
The percent of the total supply of the token that needs to vote yes in a vote in order for it to be able to be passed.
This is the period of time it takes for a vote to pass or fail
The amount of time that must pass between the start of subsequent votes.
The period of time after a vote passes before the vote can be executed. This gives hatchers that don’t approve of the vote an opportunity to leave the hatch before vote execution.
Tollgate
Requires a user to deposit this amount before creating a vote, this fee goes to the funding pool vault.
Hatch
The minimum amount that needs to be collected during the Hatch to create the TEC HatchDAO, if less than this is collected, the funds will be sent back to the addresses that sent it.
The maximum amount of wxDai that can be sent to the Hatch
Total amount of funds raised or expected amount of funds raised. Theoretical number for the purpose of running the simulation.
How long the Hatch is open to collect funds
The amount of TECH that are obtained for 1 wxDai (wrapped xDAI).
Specifies what percentage of the funds raised by the Hatch go to the Non-redeemable Pool
Hatch Oracle
Score token address:
0xc4fbe68522ba81a28879763c3ee33e08b13c499e
(CSTK)Score token decimals: 0
How divisible the base unit of the Score token can be. If the Decimals is 0, then the token is not divisible.
The amount of wxDai (wrapped xDAI) each CSTK Token holder is able to send to the Hatch per CSTK they have. If the ratio is .005 wxDai/CSTK then the user has to have 200 CSTK to send 1 wxDai
Impact Hours
Impact Hours Token: 0xf1665f141c0C4403525D7DF4757012d832FD3C1b (IH-S)
The token that controls the Impact Hours distribution, scaled for proper parameterization.
The theoretical maximum rate that Impact Hour token holders would be able to receive
The parameter that effects the curvature of the Impact Hour graph, also the rate Impact Hour holders will receive if the target goal is reached.
Agent 1: Non-redeemable Pool
Agent 2: Redeemable Pool
Redemptions
Permissions
App
Permission
Grantee
Manager
Kernel
APP_MANAGER
DV (TECH)
DV (TECH)
ACL
CREATE_PERMISSIONS
DV (TECH)
DV (TECH)
EVMScriptRegistry
REGISTRY_MANAGER
DV (TECH)
DV (TECH)
EVMScriptRegistry
REGISTRY_ADD_EXECUTOR
DV (TECH)
DV (TECH)
Agent 1
TRANSFER
Redemptions
DV (TECH)
Agent 1
TRANSFER
Migration Tools
DV (TECH)
Agent 1
EXECUTE
DV (TECH)
DV (TECH)
Agent 1
RUN_SCRIPT
DV (TECH)
DV (TECH)
Agent 2
TRANSFER
Migration Tools
DV (TECH)
Agent 2
EXECUTE
DV (TECH)
DV (TECH)
Agent 2
RUN_SCRIPT
DV (TECH)
DV (TECH)
Hatch
OPEN
ANY ACCOUNT
DV (TECH)
Hatch
CLOSE
Impact Hours
DV (TECH)
Hatch
CONTRIBUTE (1)
ANY ACCOUNT
DV (TECH)
Impact Hours
CLOSE_HATCH
ANY ACCOUNT
DV (TECH)
Migration Tools
MIGRATE
DV (TECH)
DV (TECH)
Redemptions
REDEEM (2)
ANY ACCOUNT
DV (TECH)
Redemptions
ADD_TOKEN
DV (TECH)
DV (TECH)
Redemptions
REMOVE_TOKEN
DV (TECH)
DV (TECH)
Tokens
MINT
Impact Hours
DV (TECH)
Tokens
BURN
Hatch
DV (TECH)
Tokens
BURN
Redemptions
DV (TECH)
Tokens
ISSUE
Hatch
DV (TECH)
Tokens
ASSIGN
Hatch
DV (TECH)
Tokens
REVOKE_VESTINGS
Hatch
DV (TECH)
Tollgate
CHANGE_DESTINATION
DV (TECH)
DV (TECH)
Tollgate
CHANGE_AMOUNT
DV (TECH)
DV (TECH)
DV (TECH)
CREATE_VOTES (3)
Tollgate
DV (TECH)
DV (TECH)
MODIFY_SUPPORT
DV (TECH)
DV (TECH)
DV (TECH)
MODIFY_QUORUM
DV (TECH)
DV (TECH)
DV (TECH)
MODIFY_BUFFER_BLOCKS
DV (TECH)
DV (TECH)
DV (TECH)
MODIFY_EXECUTION_DELAY
DV (TECH)
DV (TECH)
(1) CONTRIBUTE role is behind the Hatch Oracle ACL Oracle. This prevents anyone from contributing more funds that what they are allowed based on their membership score.
(2) REDEEM role is behind the Dandelion Voting (DV) ACL Oracle. This prevents redeeming tokens that are blocked in a vote.
(3) CREATE_VOTES role is behind the Hatch ACL Oracle. This prevents creating new votes before the hatch token vesting complete period has passed, so anyone can redeem during the first vote.
Last updated
Was this helpful?