Instantiate DAO with existing staking contract

[Callum-A]

We now have an added enum in instantiate to create a DAO with an existing staking contract.

• Similar to how we handle CW20s.
• If we instantiate a new CW20 the contract will error if the user specifies to use an existing staking contract. As this action is invalid
• Existing CW20s can use both a new staking contract or an older one
• Test cases cover all possible combinations

Feedback appreciated.

[0xekez]

This is great, as always. :) Thanks for the tests.

One thought: right now we're doing a check to make sure we're not using an existing staking contract with a new cw20 in reply. We could avoid needing to do that by making that configuration an invalid instantiate message.

For example, we could combine the cw20 and staking information into an enum which enumerates the valid configurations. Invalid messages would then fail to deserialize and mean we wouldn't have to make those checks.

I'm happy with this current setup, but if you're feeling fancy that would be nice.

[Callum-A]

This is great, as always. :) Thanks for the tests.

One thought: right now we're doing a check to make sure we're not using an existing staking contract with a new cw20 in reply. We could avoid needing to do that by making that configuration an invalid instantiate message.

For example, we could combine the cw20 and staking information into an enum which enumerates the valid configurations. Invalid messages would then fail to deserialize and mean we wouldn't have to make those checks.

I'm happy with this current setup, but if you're feeling fancy that would be nice.

Just to clarify what you mean by this.

Would this mean replacing the two enums we currently have in the instantiate method with one with three valid possibilities which are:

• New Staking - New Token
• New Staking - Existing Token
• Existing Staking - Existing Token

[0xekez]

New Staking - New Token
New Staking - Existing Token
Existing Staking - Existing Token

This is what I was imagining. Happy to just merge this as is though. Having it written out seems like the size of that enum might make it a little cumbersome. I can think more about this with the new contracts. :)

[Callum-A]

This is what I was imagining. Happy to just merge this as is though. Having it written out seems like the size of that enum might make it a little cumbersome. I can think more about this with the new contracts. :)

I agree the enum names might become unwieldly. Happy for other inputs on this however.

[JakeHartnell]

LGTM