CFDAO proposal: Migrate to a DAO with modern proxies

Following up with this discussion, we probably should migrate the AGP10 DAO to a new one with modern proxies that are not affected by the Istambul fork. AGP10 DAO is old, and since the hard fork it is unsafe to send funds directly to the vault/agent address. The recommended way to fix this problem is by migrating the DAO assets and token holders to a new one.

I set up a clone of the agp10.aragonid.eth into cfdao.aragonid.eth using an Agent app instead of a Vault, so in the near future we can migrate the existing SAIs and do other actions as a community.

If we agree on this path of migration, in the next ANV we probably want to change the recipient in the AGP10 (currently TBD since it was never set). We may also want to move the funds in the AGP10 DAO to the new DAO.

I used the following steps to set up the new DAO. Please review that everything is done properly:

ANT=0x960b236A07cf122663c4303350609A66A7B288C0
ROOT=<my-addr>

dao new --aragon-id cfdao --environment aragon:mainnet

dao install cfdao voting --app-init-args $ANT 666666666666666667 0 604800  --environment aragon:mainnet
VOTING=<voting-addr>
dao acl create cfdao $VOTING CREATE_VOTES_ROLE 0xffffffffffffffffffffffffffffffffffffffff $VOTING --environment aragon:mainnet

dao install cfdao agent --environment aragon:mainnet
AGENT=<agent-addr>
dao acl create cfdao $AGENT EXECUTE_ROLE $VOTING $VOTING --environment aragon:mainnet

dao install cfdao finance --app-init-args $AGENT 2592000 --environment aragon:mainnet
FINANCE=<finance-addr>
dao acl create cfdao $FINANCE CREATE_PAYMENTS_ROLE $VOTING $VOTING --environment aragon:mainnet
dao acl create cfdao $FINANCE EXECUTE_PAYMENTS_ROLE $VOTING $VOTING --environment aragon:mainnet
dao acl create cfdao $FINANCE MANAGE_PAYMENTS_ROLE $VOTING $VOTING --environment aragon:mainnet

dao apps cfdao --environment aragon:mainnet --all
KERNEL=<kernel-addr>
ACL=<acl-addr>

dao acl grant cfdao $KERNEL APP_MANAGER_ROLE $VOTING --environment aragon:mainnet
dao acl revoke cfdao $KERNEL APP_MANAGER_ROLE $ROOT --environment aragon:mainnet
dao acl set-manager cfdao $KERNEL APP_MANAGER_ROLE $VOTING --environment aragon:mainnet

dao acl grant cfdao $ACL CREATE_PERMISSIONS_ROLE $VOTING --environment aragon:mainnet
dao acl revoke cfdao $ACL CREATE_PERMISSIONS_ROLE $ROOT --environment aragon:mainnet
dao acl set-manager cfdao $ACL CREATE_PERMISSIONS_ROLE $VOTING --environment aragon:mainnet

Any suggestions to make the change official? Should we open a voting on the old AGP10 DAO? Should we wait until the next ANV?

5 Likes

Hey @sembrestels thank you for taking the initiative here! The CLI commands above lgtm. Checked out permissions in the DAO directly, those look good too.

cc @anteater for any feedback re: AGP modification

I think we should open a proposal to send all funds in the agp10.aragonid.eth or to the new cfdao.aragonid.eth org Agent address. We can continue the procedure from there.

One suggestion @sembrestels: perhaps you and I could create a 2-of-2 DAO with Agent installed that is granted permission in the new cfdao org to perform actions on the Agent app until we complete the migration? Otherwise, every step has to go through a vote which will take one week each to confirm, whereas you and I working together via multisig could complete the actions in real-time within a half hour or less.

Hi @light! Not really sure but I think we don’t need to set up the multisig. I don’t remember how much transactions are involved in migrating SAI to DAI (one to approve and another to transform? Not sure). BTW the fund are going to be already in the agent when they are transfered to the new DAO (it only has agent, no vault involved). Maybe we can do some trick to batch all the calls needed to migrate SAIs in just one evm script, and leave it documented so other DAOs can do the same with just one voting. BTW we have to transfer the funds too. Do we agree on creating two votings to transfer the SAIs and DAIs to the new DAO?

I agree!

True, this does reduce the number of txs involved down to two, one for the approve and one for the conversion as you say. Still two weeks to do it but it is the most “pure” DAO way :smile:

I created a script that bundles payments, so in one voting we vote both transfers (SAI and DAI). It was completely unnecessary, but wanted to test this aragon feature and share the code for those who may find it useful in another case.

I’m running it but it cost some time to fetch the old CFDAO (I imagine because of this, so I’ll be patent). BTW, these are the params that I used to configure the script:

{
  "daoAddress": "0x330b768f5A2f54F90fe5cCeE8806b6738560Ba1d",
  "votingAddress": "0xdbe4a3cc1eca108c1215d974b9bab8863f522b75",
  "financeAddress": "0xa9ce3bcd78c3eec38556e4595154d42d56cffaa1",
  "environment": "mainnet",
  "payments": [
    {
      "tokenAddress": "0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359",
      "receiverAddress": "0x577cbb041c645882d6c9e9b24deb786429d29cb5",
      "amount": "12501000000000000000000",
      "receipt": "Move SAI to new CFDAO (https://forum.aragon.org/t/cfdao-proposal-migrate-to-a-dao-with-modern-proxies/1793)"
    },
    {
      "tokenAddress": "0x6b175474e89094c44da98b954eedeac495271d0f",
      "receiverAddress": "0x577cbb041c645882d6c9e9b24deb786429d29cb5",
      "amount": "1470000000000000000000",
      "receipt": "Move DAI to new CFDAO"
    }
  ]
}
3 Likes

This is the vote with the bundled transfers. SAIs appear as DAIs, but it is because token names are hardcoded somewhere in Aragon and they are not updated, but it’s not going to be an issue.

1 Like

Another example of atomic payments done with this tool can be found here: https://mainnet.aragon.org/#/committees/0x790d73e8690042f37df0194c6e5835bf4d340638/vote/3/

This is the data used:

{
  "daoAddress": "0x592B213bf0176c1f3b2a6F5EfE632eAC4b5453EE",
  "votingAddress": "0x790d73e8690042f37df0194c6e5835bf4d340638",
  "financeAddress": "0x3ceec51601e17ac69f6acb10a214c9bb7a86ac24",
  "environment": "mainnet",
  "payments": [
    {
      "tokenAddress": "0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359",
      "receiverAddress": "0x7c343AbB2b180732583a3134E4A9f6e138D320D2",
      "amount": "500000000000000000000",
      "receipt": "Milestone 2 - @paulo"
    },
    {
      "tokenAddress": "0x89d24a6b4ccb1b6faa2625fe562bdd9a23260359",
      "receiverAddress": "0xDc2aDfA800a1ffA16078Ef8C1F251D50DcDa1065",
      "amount": "500000000000000000000",
      "receipt": "Milestone 2 - @sem"
    }
  ]
}
4 Likes

Wow, it’s amazing to already see use cases of @aragon/toolkit thanks a lot for doing this @sembrestels I’m adding you example to the toolkit repo if you allow me.

1 Like

Thanks @sembrestels! LGTM.

For sure, I can even do the pull request. Let’s discuss it in this issue: https://github.com/aragon/aragon-cli/issues/1308.

I’ve been working on the next step of the SAI-to-DAI migration and created a script to execute the two transactions required in just one vote (again, it was not really needed, we could have had two votes instead of one and it would have work, but I did it this way for fun and experimentation).

You can find the code and the documentation in the aragon-toolkit-examples repo.

So I created a new vote in the CFDAO.

It shows a non-very-explanatory text, so I’m going to analyze the EVM script and explain in simple words.

The vote has been generated by this transaction:

This is the input data if you “click to see more”:

Function: newVote(bytes _executionScript, string _metadata) ***

MethodID: 0xd5db2c80
[0]:  0000000000000000000000000000000000000000000000000000000000000040
[1]:  00000000000000000000000000000000000000000000000000000000000001c0
[2]:  000000000000000000000000000000000000000000000000000000000000015c
[3]:  00000001577cbb041c645882d6c9e9b24deb786429d29cb5000000a4d948d468
[4]:  0000000000000000000000000000000000000000000000000000000000000020
[5]:  0000000000000000000000000000000000000000000000000000000000000060
[6]:  0000000189d24a6b4ccb1b6faa2625fe562bdd9a2326035900000044095ea7b3
[7]:  000000000000000000000000c73e0383f3aff3215e6f04b0331d58cecf0ab849
[8]:  ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[9]:  577cbb041c645882d6c9e9b24deb786429d29cb500000084d948d46800000000
[10]: 0000000000000000000000000000000000000000000000000000002000000000
[11]: 0000000000000000000000000000000000000000000000000000004000000001
[12]: c73e0383f3aff3215e6f04b0331d58cecf0ab84900000024fbabdebd00000000
[13]: 00000000000000000000000000000000000002a5af9cf85563be000000000000
[14]: 0000000000000000000000000000000000000000000000000000000000000008
[15]: 5061796d656e7473000000000000000000000000000000000000000000000000

This input is composed by a bytes and a string parameters. The bytes represents an EVM script that executes the swap actions, and the string describes the voting (it’s a dummy text).

This is the EVM script (that is encoded in [3-13]):

0x00000001577cbb041c645882d6c9e9b24deb786429d29cb5000000a4d948d468000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000600000000189d24a6b4ccb1b6faa2625fe562bdd9a2326035900000044095ea7b3000000000000000000000000c73e0383f3aff3215e6f04b0331d58cecf0ab849ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff577cbb041c645882d6c9e9b24deb786429d29cb500000084d948d4680000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000004000000001c73e0383f3aff3215e6f04b0331d58cecf0ab84900000024fbabdebd0000000000000000000000000000000000000000000002a5af9cf85563be0000

And in [14-15] we find encoded the string “Payments” (it’s a harmless mistake, because no payment is executed, but it is the message that was used in the previous atomic payments code).

Let’s go deeper into the EVM script. It executes two forward functions inside the 577cbb041c645882d6c9e9b24deb786429d29cb5 CFDAO agent app:

[~3]:

0xd948d468000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000600000000189d24a6b4ccb1b6faa2625fe562bdd9a2326035900000044095ea7b3000000000000000000000000c73e0383f3aff3215e6f04b0331d58cecf0ab849ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

[~9]:

0xd948d4680000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000004000000001c73e0383f3aff3215e6f04b0331d58cecf0ab84900000024fbabdebd0000000000000000000000000000000000000000000002a5af9cf85563be0000

The d948d468 is the `forward’ signature.

The first forward() calls the function approve of the SAI token contract 0x89d2...0359 with the parameters 0xc73e0...b849 (migration contract address) and 0xffff...ffff (the max amount in uint256).

The second forward() calls the function swapSaiToDai of the migration contract 0xc73e0...b849 with the parameter amount (12501.100000000000000000 SAIs).

So at the end, by approving this vote, we approve the SAI->DAI migration contract to take our SAIs, and we execute the swap function to migrate them effectively.

It becomes clearer that we need better tools to decode EVM scripts, LOL!

1 Like

Also opening two more votes to set up Agent permissions (I had no time to bundle them this time):

  • Vote #2: Grant ‘Transfer Agent’s tokens’ on ‘Agent’ to ‘Finance’.
  • Vote #3: Grant ‘Run EVM Script’ on ‘Agent’ to ‘Voting’.

Thanks @lkngtn for pointing out that they were missing.

1 Like

+1 to that! There is an open issue here: https://github.com/aragon/aragon/issues/1095

Also, a neat project - if even possible - would be to have an EVMScript GUI constructor so that people could build EVMScripts even if they are not coders. This is very useful, powerful functionality to bundle many actions into one proposal. Organizations should be able to harness this even if they don’t have a coder on their team.

3 Likes

Don’t totally understand this, but something that enables people without coding skills to build EVM scripts sounds good! :smiley:

2 Likes

This blog post has some explanation about EVMScript can be used in Aragon:

So we can do cool things like start 15 votes with one transaction:

1 Like

Very cool indeed!

1 Like

Echoing the thanks for doing this @sembrestels. I do not follow Ethereum development closely, so missed that Istanbul “broke” the CFDAO.

Good point. Passing an AGP to formalize the new organization address is the most proper way to do it.

@light or anyone else who might know: is there a standard way to write an AGP so that it updates a previously approved AGP?

We don’t really have a standard way of doing this yet. In any case, I don’t think we need an AGP to do this since the address wasn’t specified in the original AGP anyways. I will let my colleagues at the AA know that the community has voted to adopt a new organization as the main CFDAO (as evidenced by the Finance transfer that was recently approved, along with all of the context here around the broken contracts) and we will just continue to make the transfers as usual to the new organization. If anyone has concerns with this approach let me know and we can discuss other ways to move forward.

@sembrestels magic: the SAI has been converted to DAI! Thanks again!

Screenshot_2020-02-10%20Aragon(1)

1 Like