Open Enterprise DAO creation problem

[macor161]

Describe the bug

A few users have recently reported having problems creating a new DAO with the open-enterprise template, resulting in a DAO with only the Tokens, Finance and Voting apps installed but more importantly, the app management permission set to 0xc54c5dB63aB0E79FBb9555373B969093dEb17859, which seems to be the template's smart contract. Therefore they cannot install any app to their DAO.

Is there any way for them to recover their permissions?

Mainnet or testnet?

Mainnet

Organization

• https://mainnet.aragon.org/#/marsxr
• https://mainnet.aragon.org/#/bittopia

To Reproduce

Steps to reproduce the behavior:

1. Go to 'mainnet.aragon.org'
2. Create a new DAO based on open-enterprise template
3. Users have reported not seeing any error in the process

Desktop (please complete the following information):

• macOS
• Chrome

[sohkai]

This is specifically due to their second organization creation transaction not working.

[macor161]

@Quazia Any way for them to re-run the second transaction? I see that you have a DAO recovery script here, could it be useful?

[stellarmagnet]

Yes @sohkai is correct, this happened in December when there were gas issues, but we haven’t seen any failures lately.

We did create a script you mentioned @macor161 and there are instructions for it here, but we have it more as an internal tool (aren’t expecting someone to download our repo to use it):

https://www.notion.so/autark/DAO-Recovery-9e64e29c56884a748cbfeb1b5eccba61

If you direct them to our Keybase we can help them, otherwise let me know if this information is useful.

[macor161]

@stellarmagnet Great, thanks for the doc Yalda! 🙂 I will try it out with a user and let you know how it went.

[macor161]

hmm.. it doesn't seem to work. Here is what I did to test the script:

1. Created a new Open Enterprise DAO
   • Executed the first transaction
   • Purposely rejected the second one
   • https://mainnet.aragon.org/#/test22
2. Cloned open-enterprise and installed dependencies
3. Executed npm run recoverTemplate and got the following info:
   • Contract: 0xc54c5dB63aB0E79FBb9555373B969093dEb17859
   • Transaction data:0xe160b2c5000000000000000000000000000000000000000000000000016345785d8a000000000000000000000000000000000000000000000000000006f05b59d3b20000000000000000000000000000000000000000000000000000000000000001518000000000000000000000000000000000000000000000000000000000000151800000000000000000000000000000000000000000000000000000000000000000
4. Tried to execute the transaction a few times but always failed
   • https://etherscan.io/tx/0x772b9cb4dd3e08b53d5cd1fff75bc3c6f49ce36cf5d5c9bb38fff9ee51e95f74
   • https://etherscan.io/tx/0xd8c043d30a016b6e93d28afd357d8b362e42c3189e5e4c3943095178a1cd6019

[evok3d]

Hey all. I have had the same issue with my registration. The package never installed and as mentioned "the app management permission set to 0xc54c5dB63aB0E79FBb9555373B969093dEb17859", as such it is causing a lot of issues. Would appreciate some assistance to this issue that has affected several people.

[marsrobertson]

The link in the first post is not correct (marsxr not marsx):

https://mainnet.aragon.org/?#/marsxr

I've actually created a new DAO but it will cool to recover the previous one so that I can do various DAO to DAO turtles all the way down operations...

[topocount]

hmm.. it doesn't seem to work. Here is what I did to test the script:

1. Created a new Open Enterprise DAO

   • Executed the first transaction
   • Purposely rejected the second one
   • https://mainnet.aragon.org/#/test22

2. Cloned open-enterprise and installed dependencies

3. Executed npm run recoverTemplate and got the following info:

   • Contract: 0xc54c5dB63aB0E79FBb9555373B969093dEb17859
   • Transaction data:0xe160b2c5000000000000000000000000000000000000000000000000016345785d8a000000000000000000000000000000000000000000000000000006f05b59d3b20000000000000000000000000000000000000000000000000000000000000001518000000000000000000000000000000000000000000000000000000000000151800000000000000000000000000000000000000000000000000000000000000000

4. Tried to execute the transaction a few times but always failed

   • https://etherscan.io/tx/0x772b9cb4dd3e08b53d5cd1fff75bc3c6f49ce36cf5d5c9bb38fff9ee51e95f74
   • https://etherscan.io/tx/0xd8c043d30a016b6e93d28afd357d8b362e42c3189e5e4c3943095178a1cd6019

Hi @macor161 there are two issues with this tx. the first is that the allocations period must be at least a day in length (minimum 86400 seconds). Second it seems the gas limit is low, given other successful transactions.

The prompt for the minimum allocations period length has been updated and merged so if you pull the latest changes, it shouldn't allow an invalid parameter for allocations period to be entered going forward. Thanks for finding this issue.

It's also worth noting that the template will accept a zero value for the allocations period parameter, and default it to 30 days, but this CLI tool will not, since that's just a convention for the template onboarding UI.

[topocount]

Hi @evok3d please provide answers to the following prompts and I'll get back to you with instructions for what to do next.

• enter the desired dot voting period length, in seconds >
• enter the dot voting minimum candidate support percentage >
• enter the dot voting quorum percentage >
• enter the allocations period duration, in days >

You are also welcome to reach out to us on keybase chat.

[topocount]

The link in the first post is not correct (marsxr not marsx):

https://mainnet.aragon.org/?#/marsxr

I've actually created a new DAO but it will cool to recover the previous one so that I can do various DAO to DAO turtles all the way down operations...

@marsrobertson if you created another dao after the dao that failed there is unfortunately no way to recover that partially deployed dao :(

[marsrobertson]

I've followed up on the Keybase chat:

If you created another dao after the dao that failed there is unfortunately no way to recover that partially deployed dao :(

It's a technical limitation. We only store data for the most recently deployed dao in the cache per user address, so once another dao is deployed from the same address the state from the partially deployed dao is lost

Not mission critical, I was testing, encountered some issues, moved on... :)

I can confirm that both DAOs were created from the same account:

• https://etherscan.io/tx/0xe8670e69910dd8c7f2e758f837257f892142435ab80d025d54129c91fddde455
• https://etherscan.io/tx/0xa8cab5fbb63a69ac374df1332edff5b6b669ff33e1ee053bab0cf8a70205f9f2

[evok3d]

Hi @evok3d please provide answers to the following prompts and I'll get back to you with instructions for what to do next.

* `enter the desired dot voting period length, in seconds > `

* `enter the dot voting minimum candidate support percentage > `

* `enter the dot voting quorum percentage > `

* `enter the allocations period duration, in days > `

You are also welcome to reach out to us on keybase chat.

My issue was resolved! thank you so much for all your help. I reached out to kevbot from autark on keybase and was guided through the process. Hopefully Aragon can solve the timing issue with the process, so it doesnt time out and leave the app in that state.

I also want to thank @macor161 for all the assistance, time, and patience in helping me resolve this. Great work everyone!