search

liquity / dev

Liquity monorepo containing the contracts, SDK and Dev UI frontend.
GNU General Public License v3.0
320 stars 312 forks source link

Determine multi-sig viability in LQTY architecture #78

Closed RickGriff closed 3 years ago

RickGriff commented 3 years ago

Our current LQTY architecture and launch sequence assumes Liquity AG has a regular EOA. The address of this EOA is baked into the LQTY ERC20 (GrowthToken.sol) upon deployment, immediately receives minted LQTY, then sends LQTY to the various lockup contracts.

Design doc: https://docs.google.com/document/d/18guurng8j7KLifV9_AoNdAkLX9JvqDy_VlHfPHaETCU/edit?ts=5f6b4ee0&pli=1

However it is more desirable for Liquity AG's funds to be controlled/distributed by a multi-sig contract.

We can use a proven multi-sig template, e.g. the Gnosis multi-sig, store its address in the GrowthToken ERC20 upon deployment, and mint LQTY to it.

cvalkan commented 3 years ago

Very high priority.

ricktobacco commented 3 years ago

Also who are signers in the multi-sig, what is the protocol for adding/removing a signer? Are there waiting periods / timeouts for getting the other signatures? We will want to write this out into a public announcement anyway, right?

RickGriff commented 3 years ago

It is viable. The multi-sig can move tokens and call functions, but not deploy contracts.

So we simply need to deploy LockupContractFactory, CommunityIssuance, StakingContract, Liquity multi-sig and GrowthToken from an EOA.

GrowthToken stores the multi-sig address, and issues LQTY to it upon deployment. We then use the multi-sig for transferring LQTY to LockupContracts.

Updated design doc here: https://docs.google.com/document/d/18guurng8j7KLifV9_AoNdAkLX9JvqDy_VlHfPHaETCU/edit?ts=5fa98542

We would use Gnosis Safe Multi-sig: https://github.com/gnosis/safe-contracts