[Update] - Smart Treasury - Progress Update

[william]

Thanks for this extensive update @8bitporkchop .

Regarding Smart Contract Updates:
For the FeeCollector changes seems ok to me.
For the Bootstrap contract

@8bitporkchop

• Initial weights no longer 99/1. Instead weights will be determined as ratio of initial IDLE deposit, and FeeTreasury deposit. Weights will still gradually update to 90/10 for the initial bootstrap. (This is over a 3 month period, perhaps this can be reduced?)
• Price oracle for IDLE/WETH value will be set by multisig rather than on-chain. Direct on-chain oracles are unreliable, and vulnerable to manipulation, this change reduces the surface area of attack. The only use for the oracle would be to configure the initial weights of the pool in anycase.

that’s ok for me and should simplify the contract a bit

@8bitporkchop

The owner of the bootstrap contract will be deligated to the idle multisig before governance vote.

• After which the multisig will call swap() , initialise() , bootstrap() , renounce() in that order.

That’s fine too or better we can directly use the multisig you created here

@8bitporkchop

I have created a gnosis safe multisig address here Contract Address 0xe8eA8bAE250028a8709A3841E0Ae1a44820d677b | Etherscan

The fees for deployment should be refunded to whoever makes the actual txs, probably direcly from the Treasury (or later through something like the commitee proposed).

@8bitporkchop

The initial prototype is ready, but that doesn’t mean its ready for proposal yet, I will be continuing to test the smart contract and writing unit tests and integration tests, and adding better documentation. In addition to this (with some help from @william) I will be testing the proposal to submit on-chain.

A lot of progress have been made so far, great job @8bitporkchop! Once the code is ready we can leverage even more Kovan testnet to test also the submission of the proposal there and I’m glad to help on that side (the same approach can then be used to test everything also in mainnet fork).

@8bitporkchop

Before this happens perhaps a new grant should be created to audit the code

Security should be for sure something to focus on but we should also consider the scope of the proposal and weight the potential downsides in terms of costs and time.
In terms of changes we are not making any change to the main idleToken contract or other contracts already deployed, we will only change the feeAddress for all pools (through a method call), so no user funds will be directly at risk after the update. The other action that we are doing is the withdraw of 130000 IDLE from the ecosystem fund and the fees from the Treasury, so the worst case scenario would be to potentially have those funds stuck in some way, but we can code an emergency withdraw method that only the governance can call to be safe, so just in case we can withdraw funds from the old treasury fix it if needed and redeploy it.
All of this is just to say that we may also consider to not perform a full audit, but rather a security review with an auditing firm or a public peer review of the contracts. In either cases I’m happy to provide further support and reviews.

@Teo

Additionally, as just discussed here, we are planning to have a Treasury Committee and we might already think to route part of the protocol proceeds to the Smart Treasury, and part to the Committee. We might initially reserve 15% to Smart Treasury Bootstrap, 35% to the first automatic buyback operations, and 50% to this initial Treasury Committee? We can then have 50% of fees going to the FeeCollector and 50% going to Treasury Committee (@william @Davide @ETM612 @simoneconti would love to hear your feedback about this as well)

I think that this is a good idea, but maybe it would be better to start a more formal discussion about this and implement it after the Smart treasury is out, what do you think?

@8bitporkchop

The fee treasury can remain as is. The idea for the feeCollector was that a ratio can be set for how much of the fees goto the fee treasury, and how much goto the smart treasury. However as you mentioned in your discussion for the treasury committee, perhaps the ownership of the fee treasury can be migrated from governance to the treasury committee for this purpose (@william can confirm if this is possible).

Btw once you set the FeeCollector as the fee receiver for each idleToken then you can redirect funds where you want from the FeeCollector, so I would say that it would be better to send part of the funds to a multi-sig (treasury committee), part to the FeeTreasury (which would still be owned by the governance) and part to the SmartTreasury (to avoid having the Treasury committee controlling all earned fees with unlimited powers) with allocations TBD. This would require a slightly change in the spec / code for the proposal so @8bitporkchop let us know if you think it can be added directly

@8bitporkchop

On average the fee treasury has been making about $1000 / day (from governance launch). Which at current prices is around [$2.14/IDLE] is 467 IDLE / day. Which if fully redirected will be bought back by the smart treasury. Perhaps some further analysis can determine an optimal period.

I think some further analisys is needed to find the optimal solution, maybe it’s also worth considering the decrease of AUM and the increase of avg APY of each pool

@8bitporkchop

@Teo

we are planning to use 1% of the Ecosystem Fund (130’000 IDLE)

We are planning on using 10% of the ecosystem fund, which is 1% of total supply.

The ecosystem fund has 1.950.000 IDLE so should be 6.66% of the ecosystem fund or 1% of the total supply, but in any case we all agree that are 130.000 IDLE

@8bitporkchop

Therefore it would be best to call this at a given threshold. $5k equivalent in fees sounds good to me. Though this will have to be done through a whitelisted account.

This needs to be setup somewhere and a keeper is needed (with funding to call the deposit() method). We already have a keeper bot which performs rebalances for all pools so it can be hooked up there but some funding for gas cost needs to be accounted (and in the long run also for rebalances but that’s another story )