First, create a DXdao closure safe multisig, referred to as the “Closure Multisig,” with every address that voted in favor of the restructuring proposal and has more than 1.0% REP, and requires 6 of N signing to execute transactions from the safe. Addresses who do not wish to be on the multisig may request to be removed and the rest should express their willingness to be on the multisig. Any addresses not associated with a consenting participant should be removed from multisig after 1 week. The “DXdao Closure” safe multisig will be allocated up to a $100K budget to pay for development, code review, and to compensate active multisig members $5K each in return for their participation. This $100K will be set aside first, before making a NAV calculation. Any unspent funds from this $100K will be distributed evenly amongst the product teams. A safe has already been initiated for this purpose.
Parameters for Restructuring
Leave 90% or more of product team allocation as stablecoins
Convert all remaining assets to ETH, excluding DXD, SWPR, ENS, ARB, and stablecoins for product teams
Liquid DXD redemptions to be done as CowSwap orders.
Accelerated vesting to be claimed via proposal to DXdao. Up to contributors to burn any DXD in vesting contracts via upgraded bonding curve.
REP Snapshot redemptions to be done via a claim contract.
Product Guilds should designate treasury addresses ASAP, including with confirmatory tweets from their public twitter accounts. They should require at least three parties to agree in order to execute proposals, for example a 3 of 4 or a 3 of 5 Gnosis Safe multisig.
DXdao MS signers shall transfer all funds to the Closure Multisig ASAP. Namely, the assets listed here:
Send all DXdao funds to Closure Multisig as they come available. Closure Multisig will proceed with following order of priority:
1/3rd of DXD redemption amounts. First ½ of product funding.
ENS tokens to Nimi treasury.
ARB and SWPR tokens to Swapr treasury.
1/3rd of DXD redemption amounts. Second half of product funding.
1/3rd of DXD redemption amounts. REP snapshot funds.
ENS domains to be dispersed as follows
swapr.eth and liquidity.eth to Swapr
carrot.eth to Carrot
nimi.eth to Nimi
dxgov.eth and guilds.eth to Davi/DXgov
All other ENS names may be claimed by the address that sent them to DXdao
Anyone interfering with the orderly dispersal of funds according to the passed signal proposal forfeits their claims on any funds for their unvested DXD or REP address.
Order of Operations
Initiate proposals to move funds to the multisig. This should include LP tokens in Swapr. First proposal can include the plan outlined here in this post and move remaining ETH and DAI (first taking into account in process redemptions).
Pick date to set ETH price of redemption orders (should be after liquidity withdrawal)
Community calculates DXD circulating supply, NAV, publishes eligible REP addresses and amounts, and publishes unvested DXD amounts and deployed vesting contracts
First, create a DXdao closure safe multisig, referred to as the “Closure Multisig,” with every address that voted in favor of the restructuring proposal and has more than 1.0% REP, and requires 6 of N signing to execute transactions from the safe.
Any reason why this all cannot be done via the main avatar?
The “DXdao Closure” safe multisig will be allocated up to a $100K budget to pay for development, code review, and to compensate active multisig members $5K each in return for their participation.
Why do you need to pay 5k to each multi-sig member to sign a few transactions? Paying for the development of new smart contracts and auditing I can understand.
Couple of questions (apologies if I misunderstood or missed something):
What exactly should we do about DXD that is in vesting contracts already?
About DXD vesting which is not yet in a contract, should we use existing DXD tracking spreadsheets and is a basic proposal specifying amounts enough for this?
Should the vested DXD proposals be requesting Eth or DXD?
Shouldn’t the closure multisig be more than a 6 of 14? something with over half of members sounds more secure (9 of 14?)
The closure multisig idea is good but I had something different in mind:
Instead of sending the funds to the multisig register the multisig as a scheme that can do anything on the dao.
Have a high request of signers for proposal execution, at least 3/4 of signers, and decide which days signers would need to be available to exec operations. Some test transactions can be done before the closure execution.
100k USD seems like a lot of money for this, even more paying 5k to each signer for this, have ETH to cover tx gas costs and that’s it.
Regarding execution steps:
1.- Get all NAV on mainnet avatar.
2.- Distribute the DXD for accelerated vesting @allyq can provide with a list of addresses and transactions to be executed.
3.- Distribute the 8000 DXD for the Gov 2.0 eligible addresses. I am working on a script to calculate that, I can have the PR with the script and instructions today.
4.- Upgrade the DXD token and add a claimed method so all DXD can be claimable for the 80% remaining nav in the DXD token. We can also have a claim timeout, so after 6 months if there are unclaimed funds we distribute them among the addresses already claimed or send them back to the multisig to be distributed among product guilds.
This whole process would take a SchemeRegistrar proposal (2 weeks) plus 1-2 days to execute everything, so the 2 weeks can be used to make sure everything is ready to be done when the multisig is registered as a scheme and has access to avatar.
Since the funds are converted into ETH anyway, why not also redeem ETH instead of DXD. And then you simply burn the outstanding vested DXD when the holder redeems. That seems to be more beneficial to everyone so you don’t need to do another swap, first from DXD and then to ETH (and save a lot of gas fees).
3AC already worked on upgrading the DAT implementation with appropriate assertions for upgrading and withdrawing ETH and USDC (and any ERC20) back to the avatar. A skim would be appreciated. GitHub - 3acvc/dxd-token
This is only possible once the bonding curve is upgraded - so you run the risk of double vesting in the meantime. It’s probably easier to have one way of redeeming (i.e. CowSwap) and that’s it.
Mainnet avatar just slows everything down significantly. I.e. you don’t know what you get when you unpool liquidity, so you have to wait 8 days to unpool the liquidity and only then can you i.e. submit CowSwap orders +16 days or move the funds +8 days. Plus only at after a lot of these steps happen would one be able to place a CowSwap order for redemption which would be another +16 days after the already mentioned 24 days, resulting in a minimum of 40 days (just off the top of my head probs even longer)
Setting up all the txs, proposals etc. and ensuring an efficient and correct liquidation definitely takes time. For me personally I don’t really care so much about the $5k, but I think it’s a fair amount. If we’ve learnt anything at DXdao it’s that without incentives no one is going to sign MS txs. Here it’s important for users to not only sign, but also take their time to verify what the txs do.
This will have to wait for the DXD token to be upgraded, then I believe you can simply burn the DXD in your vesting contracts and mint it to your address (all in one proposal).
That should work? Wonder if @allyq has a latest version of the DXD sheet?
IMO 6 of 14 is fine for the actual liquidation, the threshold could probably be increased after the initial amount of time sensitive proposals have been executed.
I think you can do most liquidations before this proposal passes, but it could nonetheless be done in parallel? Do we know that a Gnosis Safe will natively work as a Scheme?
Once a Safe is registered as a scheme no more proposals would need to be created, the hardest part would be to encode the genericCalls that need to be done from the safe, but we would have instant access to do anything on the avatar scheme, I think this is the easiest solution that guarantees instant access to liquidity pool, funds & ens names.
Submitting a proposal to register the safe with any paramHash (since this won’t be used, it can be anything 0x1000000000000000000000000000000000000000000000000000000000000000 for example) and the raw permissions 0x0000001F would register the safe and allow it to do anything.
Another good side of this is that it can be replicated gnosis chain and arbitrum too, we just need to register a safe there and we can have access to everything and bridge it to mainnet.
I took a look to the safe and it would be good to clarify who is owning each signer:
0x91AEF3c3b9BAb2c306548269Ff9b6771f2B107D8 0xKlom voted in favor and has +1% and is missing
I would like to be added, I can help with the genericCall encoding and controller calls, 0x08EEc580AD41e9994599BaD7d2a74A9874A2852c augustol.eth.
The proposals to register the safe as a scheme can be submitted as soon as we clarify the signers identity and their availability.
Another thing that can be done that will speed up the process is to deploy a claim contract where we send the ETH collected from all the liquidations (representing 80% NAV) to a contract where it can be redeemed using DXD. It can be owned by the SAFE multisig. Or we can wait 16 days for cowswap order to be created. I think no matter what this process would take some time and it is more important to make sure everything get what it has been approved by dxdao rather than rush it, and in this case, the 5k USD for signers cause it will take a months work + availability makes sense.
I’m not against this - but when you look at Native Safe Vs Safe as a Scheme the only tradeoff here is time vs number of proposals.
Why is reducing number of proposals required more important than quick execution? (It might be but I don’t see why)
With both a Safe as a Scheme or a Native Safe - there is no need to wait 16 days.
But its essentially the same thing, on the one hand you’re moving all funds to a Safe on the other hand you’re making the DAO a Safe. Not sure why the latter is strongly preferable?
Edit: let’s do a Safe as a Scheme and vote it though with 51%?
these addresses can be on the safe if community wishes without compensation. 0xklom.eth voted for after this post was published. did they vote to be on the safe or for the proposal?
augusto.eth voted against and would receive an exemption. what will others who voted against think?
Besides funds, we have ens domains and we would likely need to do more operations to drain the avatar completely, this is why I think having access to the avatar is better than just moving funds.
Im ok with not receiving compensation, now that this is done I just want to make sure that everyone will receive what they deserve and help coordinate everything.
Registering the Closure Safe as a scheme and passing the registration proposal by 50% vote can accelerate the process and should be attempted. In case it does not reach 50%, initial proposals can be made to start moving funds to keep the process moving as quickly as possible.
0xklom.eth meets the requirements of having voted for the restructuring proposal and having 1% of REP and therefore should be added to the Closure Safe.
augusto.eth does not meet the requirements for the Closure Safe, having voted against the restructuring proposal. However, Augusto’s services are valuable and the Closure Safe group could compensate Augusto for his services out of the $100K budget.
I generated a .xlsx file with the eligible REP holders that would have received 8000 DXD for gov 2.0, the column with the % of REP eligible per member over the total is highlighted. As I understand this should be used to distribute 8% of NAV among these addresses based on:
Distributing 8% of the treasury, excluding DXD, SWPR, ENS, and ARB, to REP holders that would have received the 8000 DXD under the Governance 2.0 Proposal
We’ll likely use our existing guild at 0x3f842726188FcD932d43bcA291be28138228e6D9 in future but for now will use the safe above until everything is sorted out.
Good job, thanks!
The ship is sinking, grab whatever you can. So on that note I remember there was something about 4% REP max. In the Excel file there are 8 addresses that go over 4%. Just leave it like that or distribute the extra REP (i.e. sweet sweet DXD) to all other addresses?
I am one of those addresses and I have no problem with that, I am going to add that as an option on the script so the closure multisig signers can decide which distribution use.