When I deploy the dao with the DaoFactory, my second plugin relies on the address of the first plugin... What do you recommend?

Should I deploy the second plugin separately after or is there a way to precompute the address of the first plugin and pass it for the setup of the second plugin in the DaoFactory createDAO plugin settings?

The token is itself an index that represent the vault, buy the DAO token-> buy proportially the dao vault tokens. The mint function in this case interacts directly with the DAO as it mints new tokens, buys the underlying DAO tokens and stores them in the DAO. The user can than redeem/burn the token and get back/sell the underlying tokens face value.

The DAO becomes itself an index, like an ETF or a decentralised fund.

The token is itself strictly related to the DAO and should be core part of its infrastructure and security.

I am not sure if it is a good idea to separate the logic, since the token itself is core part of the voting plugin to take decision on how to manage the DAO index composition.

The above all implies that the token itself stores the dao index asset composition and weights and it is also responsible to edit the latter(swap asset and update assets struts) when those kind of proposals are passed.

1 Answer 1


If a governance plugin is dependent on the balances of a Token, the most recommendable thing would be to treat them as part of the same plugin scope.

What defines a plugin is the fact of implementing the IPlugin interface, most likely the Upgradeable version... and also, having permissions that the DAO grants to it.

Something like a simple ERC20 token contract doesn't sound like a plugin. It sounds more like a helper of an actual governance plugin that is able to do something on the DAO, eventually.

I personally think of the DAO as the "vault", which holds external assets and is the "actor" that runs stuff.

All these DAO actions are commanded by plugins that you can install and remove. And the conditions for these plugins to do what you want may vary. Could be a majority on a multisig, could be a majority or ERC20 token holders, etc.

But DAO holding + executing is one thing... and DAO members owning something that allows them to vote/approve is a different one.

You could have a DAI token based governance plugin, an ANT based one, and also have 3 different multisig's being able to do other stuff.

IMO the mint() function should be something on the ERC20 token contract or on a predefined minter contract. Only the DAO should be able to call mint() on it (protected by auth(MINT_PERMISSION_ID) for example).

For the DAO to end up calling mint() there should be a proposal passed. You could have this proposal in any plugin with sufficient permission

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.