Superdao is an all-in-one platform to start, manage and grow DAOs. A substantial part of our product is Superdao OS — a smart contract framework to build and run organizations on the blockchain.
- Article about Superdao OS "Superdao OS — Operating System for DAOs"
- Article about Superdao OS "How Superdao covers users’ gas fees"
- User interface of Superdao OS "Superdao Product Demo"
- Security Audit of Superdao OS "Superdao OS Security Analysis by Pessimistic"
We are posting a repository with no commit history, so here is a list of developers who contributed.
- Ivan Kalashnikov
- Aleksandr Davydov
- Artyom Zinovyev
- Elshan Dzhafarov
- Ivan Cheprasov
- Ivan Kalashnikov
- Max Averin
- Mikhail Sitnikov
- Vladimir Alefman
- Vladislav Semkin
contracts/:.solfiles of our contract logicdeployments/modules/deploy/modules/helpers/modules/scripts/: suppose to be a core folder for TS modules to be used either in tasks/ or in scripts/ itself. To run scripts itself it is supposed that you usets-nodeinstead ofnode(coz we write in typescript).modules/tasks/: hardhat tasks for manual run. Note, that in hradhat tasks can not use typechain-types of our contracts coz of hardhat environmental logic.packages/: now it consists of logic to copy artifacts & typechain-types of our contracts and deploy to NPMmodules/tests/(this logic used to triggered by .gitlab-ci.yml)
- Install project dependencies
pnpm i- Install husky
pnpm prepare- Compile contracts
pnpm i- Generate typechain-types
pnpm typechainThis repo is designed to use several networks. How to use each of network in the repo and what envs to supply to .env
is described below.
Note, that we distinguished mainnet and testnet and do not apply abstraction to those networks.
To use live network (e.g. polygon, mumbai) supply personal key and rpc to the related network (personal key is used by
todo: related to #97 MR) and in all tasks, scripts where hardhat engine is used apply
--network mainnet or --network testnet accordingly.
MAINNET_DEPLOYER_PK
MAINNET_RPC
TESTNET_DEPLOYER_PK
TESTNET_RPC
Hardhat network is designed to be used as it is and without providing any env. Such network is used for unittesting and
by default when no --network flag is provided.
Fork might be used for, e.g. test if contracts will be upgraded without errors and etc. Every script/tasks those
are run under hardhat engine could be running under fork via hardhat. To make hardhat run scripts and tasks under
fork of mainnet or testnet .env with next:
MAINNET_RPC
FORKING_MODE=MAINNET
FORKING_FROM_BLOCKor
```dotenv
TESTNET_RPC
FORKING_MODE=TESTNET
FORKING_FROM_BLOCKno additional flag of
--networkis required
Currently, only tasks/integration-tests/getters-upgradability.ts as a hardhat task supports possibility to be run on Tenderly fork. Use-case e.g. to prepare public network rpc with upgraded contracts to be tested.
To use tenderly fulfil following in .env:
TENDERLY_PROJECT_ID
TENDERLY_USERNAME
TENDERLY_ACCESS_KEYno additional flag of
--networkis required
On deploy we use hardhat-deploy plugin that do next:
- checks if contract should be deployed (if contract code is changed)
- write new abi, address, etc in deployments/ to the folder with name of network used.
Deploy to Polygon Mumbai (testnet):
pnpm deploy:testnetVerify deployment:
pnpm hardhat --network testnet etherscan-verify- Run local node
pnpm chain- In other console deploy on that network
pnpm deploy:localhost- Just add a new network and set
http://localhost:8545as RPC URL
Use-case e.g. we want to use feature of new code of contract checking of hardhat-deploy plugin and to sync hardhat-deploy tasks and custom tasks by deployment folder.
How to use fork network but work with deployment/ folder, - together with .env to make fork use
FORKING_MODE_USE_SOURCE_DEPLOYMENTS=truewith this setup hardhat-deploy plugin will work with deployments/<specified network name>
instead of deployments/hardhat.
Careful: you may rewrite
deployment/mainnetand push it to the git (but those deployed contracts will be only on you fork)
todo: @IvanKalashnikov: describe logic of 1,2,3 and mv scripts to a new folder...
- hardhat tasks could not use typechain types of our contracts (but general TS scripts could use it)
- when reading from file in some tasks there is filtration logic under the hood. Check scripts/core/read-from-file-filtered.ts
- Add newest impl to UpdateManager
pnpm hardhat manager-add-impl --appId {APP_ID} --kernel {KERNEL_ADDRESS} --impl {IMPL_ADDRESS}- Upgrade app to the last implementation
pnpm hardhat manager-upgrade-app --appId {APP_ID} --kernel {KERNEL_ADDRESS}This script is interactive. If you choose to search for the implementation,
make sure your kernel is on the newest impl that supports upgradeAppImpl() function.
To upgrade the kernel to the right version, run the script without looking for impls,
it will upgrade the kernel to the lastest version in the UpdateManager.
Make sure your kernel version supports upgradeAppImpl().
Update it with the method above.
- Upgrade app to the last implementation
pnpm hardhat upgrade-impl --appId {APP_ID} --kernel {KERNEL_ADDRESS} --impl {IMPL_ADDRESS}DAOs specified in the file should exist, so it is supposed you will use a fork. You may run upgrades on fork, mainnet or even on tenderly fork (to get public RPC url with upgraded contracts at the end).
- Upgrade apps in kernels from file (to do upgrade on Tenderly fork add
--on-tenderly-fork)
pnpm hardhat upgrade-from-file --file {PATH} --apps {APP_ID1},{APP_ID2}Json file format:
[
{
"contractAddress": "0x553C2c81596b32D86697D115eEdA1184bBD8E661"
}
]The tests and scripts in tasks/integration-tests are designed to be run on forked network via hardhat engine. Thus, to run such tasks manually firstly pay attention to the Fork section.
Test that application implementations behave the same way after upgrade on the hardhat network fork.
Features:
- currently, it supports getters tests for next apps: KERNEL, ERC721, ADMIN_CONTROLLER, OPEN_SALE
- no needs to test apps those are not even connected to kernel we check. Thus, it checks that an app connected
To run integration test on upgrade action, firstly, update env with params to fork todo: prepare json and then run task itself:
echo "[{\"contractAddress\" : \"0xAb9f24AcF3987412898e28b31CEc6a4Daee21D8E\"}]" > tasks/contractsToTest.json
pnpm hardhat getters-upgradability --file tasks/contractsToTest.json --apps ERC721,KERNELA complex integration task with a goal to proceed upgradability checks after commit to a protected branch. It
- deploys implementations via hardhat-deploy plugin,
- updates them in update managers for managers specified in a file,
- proceed upgradability tests Upgradability Getters Test for kernels specified in a file.
Thus, pay attention to the section Fork and note that supplied update manager should be synced with the kernels supplied. Otherwise, this pipeline has not meaning for kernels with different update managers.
ref to https://miro.com/app/board/uXjVOiYgA80=/
E.g. to prepare files & run:
echo "[{\"contractAddress\" : \"0xBC2B53801FE03D7A8f9992a36DdEf596Bb6dc3c6\"}]" > tasks/inputs/contractsToTest.json
echo "[{\"contractAddress\" : \"0xDeB6b06E22A5BdFB2d42000074B46F9C2c3861FE\"}]" > tasks/inputs/updateManagersToUpd.json
pnpm hardhat integration-test-deploy-update-upgrade --file tasks/inputs/contractsToTest.json \\
--apps-to-track KERNEL,ADMIN --update-managers-file tasks/inputs/updateManagersToUpd.json- I didn't modify anything though I get
VM Exception while processing transaction: revert Initializable: contract is already initialized(or similar) when attempting to deploy contracts
Restart ganache-cli. Most likely already deployed and initialized contracts are begin re-initialized.
- Where do I find contract addresses?
All deployment data stored to deploy/deployments/loalhost at your $cwd.
- Kernel
- Sudo
- Admin
- ERC721
- ERC721 Link Claim
- Sales Controller
- Open sale
- Private sale
- Kernel Implementation
- ERC721 Properties Implementation
- Admin Implementation
- Open Sale Implementation
- Private Sale Implementation
- Treasury (Gnosis Safe)