Connections Overview

[corkus]

Hey everyone,

I´ve prepared a list of all the connections the DXdao needs to have in the coming weeks. It is meant to give everyone an overview and the current state of adding and removing connections.

Add Connections

Pending Proposal

TODO

Upgrade Proxy Contract
Lets the DXdao upgrade any upgradable contract it owns

Bonding-Curve Proxy Contract
Lets the DXdao interact with the Bonding-Curve. For example: buy DXD,burn DXD,close the Bonding-curve, pay DXD and more.

Omen Arbitrator Contract
Let the DXdao be an arbitrator on Omen.eth. For more information please check out the Omen Overview

Dxswap Contract
Let the DXdao remove/set the protocol fee and the swap fee.

Lock Token for Reputation Contract
Lets the DXdao add a Token for Reputation distribution configured by total REP amount and duration. If a Token Holder locks a token, the token holder will receive reputation protional to the total locked amount and duration. This will be important to distributibe REP for a variety of ways like rewarding Liquidity Provider on Omen or DXswap.

Add Generic Connection which could call any smart contract on Ethereum
This Connection allows the DXdao to call any function on ethereum.

Remove Connections

Pending Proposal

[Remove Lock Ether for REP Contract] (DxLockEth4Rep | 0x4564bfe303900178578769b2d76b1a13533e5fd5)
This Contract was used in the bootstrapping phase and has no use anymore.

TODO

Old Public Resolver Contract
Once we added the newest version of the public resolver contract we should remove the old one.

DONE

[Add Token Registry Contract Contract] (DXTokenRegistry | 0x93db90445b76329e9ed96ecd74e76d8fbf2590d8)
Lets the DXdao create Token lists, add and remove Tokens from a list.

[Add New Public Resolver Contract] (ENS: Public Resolver 2 | 0x4976fb03C32e5B8cfe2b6cCB31c09Ba78EBaBa41)
Lets the DXdao interact with its ENS domains with the newest version of the public resolver contract.

[Remove Lock DutchX registered Token for REP] (DutchXPriceOracle | 0x764c0020706575ebbdea3c425ebf894c4f855b07)
This Contract was used in the bootstrapping phase and has no use anymore.

[Remove Auction Contract for bidding on REP for GEN] (DxGenAuction4Rep | 0x4D8DB062dEFa0254d00a44aA1602C30594e47B12)
This Contract was used in the bootstrapping phase and has no use anymore.

[Remove Lock MGN(Magnolia) for REP Contract] (TokenFRTProxy | 0x80f222a749a2e18Eb7f676D371F19ad7EFEEe3b7)
This Contract was used in the bootstrapping phase and has no use anymore.

[koeppelmann]

I’d say creating a dedicated scheme for actions that are rarely done is not a good design.
I think the dxDAO (or DAOStack DAOs in general) should always have the ability to do any transaction on Ethereum they like to. It is understandable for security reasons that this should not be possible with the Avatar as message sender.

However - there is no risk in making the Avatar the only owner of a blank/clean Gnosis Safe and let the avatar do transactions from this Safe. Optionally this Safe can get assets like tokens or e.g. the ownership of a ENS domain.

All the Safe Schema would need to do is to call the “approve and execute” tx function of the Gnosis Safe.
cc @adam @oren @stefan

[AugustoL]

Love the idea! we definitely should be working on an schema with this flexibility!

It would be important to provide the tools to debug what the transactions are going to execute, internal transfers, calls, events. The voter should be able to simulate the transaction flow and see whats going to happen

[corkus]

Having such a flexible scheme means it should have voting parameters which are very secure and as a result very slow. For example the plugin connection we have right now. It has a two weeks period of voting after the proposal got boosted. Should the safe have similar slow/secure voting parameters?

[koeppelmann]

Having such a flexible scheme means it should have voting parameters which are very secure and as a result very slow.

No - it does not need to be secure at all. Please note: a regular scheme can do a transaction FROM THE AVATAR. This can be dangerous as the avatar has many rights (like minting REP, owner of other contracts)/ holds all the funds.
In my proposal, it would just allow doing a transaction FROM A EMPTY SAFE. This safe holds in the beginning 0 assets and has 0 special rights/privileges. If the DAO would e.g. want to convert 100 ETH to DAI it could a) send the 100 ETH to (trough a funding proposal) to the Safe. and b) then do a trade on any exchange they want from the safe.

Similar with ENS domains, currently they are held by the avatar - OPTIONALLY they can be given to the safe. For each of the items you listed (upgrade, vesting, omen, dxswap) it would always be a “opt-in” by setting the owner to the safe (instead of the avatar) and/or transferring assets to the safe, to e.g. then use them to fund a market on Omen.