A proof of concept that models a semi-liquid mint-lock-stake DAO designed to collect Lovelace from users wishing to use the DAO's threshold-based actions. The semi-liquid nature allows the purchasing power of Lovelace to be maintained by the user as the mirror token represents a one-to-one Lovelace connection but the staking power is given to the DAO.
The DAO data contract assumes the starter token information will be provided at compile time. The uniqueness of this starter token must be guarenteed but it may come from a smart contract or native script minting policy. The policy id and token name information is contained in the start_info.json file. This file also contains the pool id for the stake contract as well as a random hex string for contract initialization.
{
"__comment1__": "This is the starter token for the data reference contract.",
"starterPid": "d71d15d49f1cb409d0f3863188909af20da621b8e2baa7caae722d0e",
"starterTkn": "9877cd0707f500970050fb0216090b080862ad16c421a3212d6f6350602beda6",
"__comment2__": "The stake will delegate to this pool id.",
"poolId": "8ffb4c8e648c0662f2a91157c92feaa95f1a3d2728eaea8257b3d8d9",
"__comment3__": "A random string to use for contract generation.",
"random": "acab"
}The contracts require Rust and Aiken to be installed and on path.
The contracts make heavy use of the Aiken Assist Library. The happy path will require Python, jq, and sponge.
Be sure to update Rust and Aiken, remove the old build folder, then run the complete build script. This makes sure the contracts are using the most up-to-date versions at compile time and all contracts are compiled in the correct order.
rustup update
aikup
rm -fr build/ || true
./complete_build.shThe compiled Plutus scripts will be in the contracts folder and their respective script hashes are in the hashes folder. The certifications for the staking contract are in the certs folder.
The scripts folder provides a happy path to follow as well as all the wallet and datum / redeemer information. The test scripts will allow the DAO to update the multisig and data, the stake to be delegated and rewarded, and the ability to mint and burn mirror tokens. The mirror tokens can be used to initate threshold-based actions.
There can only be one DAO data UTxO by design but there can be many stake and lock UTxOs, allowing for sharding for greater efficiency.
The happy path assumes there are specific wallets that exist and are funded with enough Lovelace to pay for the transaction fees. The create_wallet.sh script will auto create the required wallet files given a specific wallet path.
./create_wallet.sh wallets/collat-wallet
./create_wallet.sh wallets/delegator-wallet
./create_wallet.sh wallets/keeper1-wallet
./create_wallet.sh wallets/keeper2-wallet
./create_wallet.sh wallets/keeper3-wallet
./create_wallet.sh wallets/reference-wallet
./create_wallet.sh wallets/reward-wallet
./create_wallet.sh wallets/starter-walletThe balances can be viewed with all_balances.sh.
After the wallets are funded, the reference wallet will need to pay the minimum required Lovelace and the transaction fee to create the script references for the happy path.
./00_createScriptReferences.shThis script will auto tx chain all the script references together.
The balances of the smart contracts and wallets can be viewed with all_balances.sh. The get_pkh.sh script can be used to find the pkh of an addressed passed as a variable. The trade_token.sh script can be used to send tokens around if the wallets need to be cleaned up.
This proof-of-concept DAO using a two-teir system where the upper tier is controlled by a multisig and the lower tier is controlled by contributors delegating their Lovelace to the DAO.
Inside the dao folder are all the scripts for updating the mutlisig and data. The update scripts use data from the data/dao/update-dao-datum.json file so any changes will need to be applied to that file for DAO data updates. This is also the file that the complete_build.sh script updates at compile time.
Use the starter wallet and create the DAO UTxO.
./01_createDAOUTxO.shThe multisig is updated with 02_updateManagement.sh and the data is updated with 03_updateData.json. A user with enough mirror tokens may use 04_petitionDAO.sh to update the data.
Inside the stake folder are all the scripts for registering, delegating, and withdrawing from the stake contract. The stake contract can only be delegated to the pool id and be rewarded to the vault contract. The stake contract takes in a random hex string so many different stake contracts can be compiled if required.
Use the starter wallet and register the stake contract.
./01_registerStake.shThe stake can be delegated with 02_delegateStake.sh and rewards can be withdrawn with 03_withdrawStakeRewards.json both of which use the DAO multisig.
Inside the vault folder are all the scripts for creating, adding, and subtracting from the vault contract. The vault is design to accumulate rewards from staking and any profit for the DAO. The vault is designed to have many vault UTxOs as their only purpose is to accumulate Lovelace.
Use the starter wallet and create the vault UTxO.
./01_createVaultUTxO.shAnyone can add Lovelace to the vault with 02_addToVault.sh but subtracting from the vault with 03_subFromVault.json requries using the DAO multsig.
Inside the mint folder are all the scripts for creating the lock UTxO, minting and burning mirror tokens. There can be any number of lock UTxOs but only one is needed for the happy path.
Use the starter wallet and create the lock UtxO.
./01_createLockUTxO.shThe delegator wallet is used to mint and burn mirror tokens. The tokens are one-to-one with Lovelace.
For example, the delegator can mint 123,456,789 "Lovelace" into their wallet and will lock 123,456,789 Lovelace into the lock contract.
./02_mintTokens.sh 123456789The delegator may also burn their tokens and get their Lovelace back.
./03_burnTokens.sh 123456789This will burn 123,456,789 "Lovelace" from their wallet and will unlock 123,456,789 Lovelace from the lock contract.
Now with many lock contracts, many delegators may place their ada into the lock contract in exchange for the mirror token. The DAO will now control the staking power of the locked Lovelace but the delegators control their buying power with their "Lovelace" token. At any time, delegators may return to retrieve their Lovelace from the contract and regain control of their staking power.
Now that users have the "Lovelace", they may act on the behalf of the DAO with the available threshold-based actions. Each action requires a certain amount of the "Lovelace" to be inside the transaction, proving that the user(s) has/have enough contribution to the DAO to be able to perform the action. This system allows for many different actions to be built and added to the ecosystem without any required hardforks to the original data or mint/lock contract as these action contracts depend solely on policy id of the mirror token, "Lovelace". But each new action will require an update to the DAO data as each action has its own mirror token threshold requirement.
An NFT is allowed to be minted or burned if and only if the transaction contains inputs that hold a minimum amount of "Lovelace". The user(s) that create this transaction may do as they please with the resultant NFT. In this example, each NFT is prefixed with "~DAO".
This will mint an NFT into the delegator wallet if and only if the delegator has enough "Lovelace".
./01_mintNFT.shThis will burn an NFT from the delegator wallet if and only if the delegator has enough "Lovelace".
./02_burnNFT.shThis NFT generator is great for starter and pointing tokens but the prefix is fixed so it may not serve well with cip 68 / 721 compliant tokens as this minting script is just an example of a threshold-based action.
Petitioning the DAO implies that a user wants to update the DAO data on behalf of the multisig members. To prevent a rich bad actor attack, each petition must be witnessed by the threshold amount of multisig members. For a user to petition they must hold at least the petition threshold amount of the mirror token. The petition is then reviewed and considered for submission, if successful then it will be signed by members of the DAO multisig. This threshold action and witness pairing allows large contributors to control the DAO data but still requiring some form of data verification by trusted members of the DAO.
The delegator may petition the DAO for a data change if and only if they have enough "Lovelace".
./04_petitionDAO.shThe data update is verified by a member of the multsig and is submitted.