Provide quotes/budget for Smart Treasury development

[Cippo]

Ciao @8bitporkchop, let me answer you:

1. I would do 60/40 IDLE/ETH. As you can see in the graph provided by @Teo, a pool structured as you suggested has a significant slippage. In a liquidity pool of 200$k, a trade of 1$k (0,5% of the liquidity provided, so a small trade) would have a slippage of 4%. I wouldn’t trade in this pool. Don’t you agree?
2. I would never use ecosystem fund. I do believe is really important to control circulating supply and, if possible, to reduce it. If we’d use the ecosystem fund we wouldn’t start a buy back mechanism but we would incentivize inflation, diluting our returns in the long term when fees will be much higher ;

@unicorn I agree with you that 10$k is not that much but Unipool pool has only ca. 20$k right now, so we can start in this way using only our fees. Our liquidity pool will quickly organically grow depending thanks too: trading fees and daily fees.

Last thing: trading fees. Trading fees depends on volumes and trading fees %. As of today Uniswap trading fees are 0.3%. If we set 2%, nobody would trade with our pool (transaction costs would be ca. 10x higher). I do believe we could benchmark Uniswap and set trading fees to 0.3%, incentivizing in these way volumes and therefore maximizing trading fees.

I understand my answer is really negative and I’m sorry about that But I do believe in buyback mechanism when a project is solid. Let me know what you think!!

[unicorn]

Agree with @8bitporkchop on the 1 to 10% (in 3 months) approach.

In my mind I was thinking about a shorter time period to bring the treasury to “balance” (2-4 weeks) so if the rest of the community agrees with a longer period like @8bitporkchop mentions then (2??) 3 months in my opinion that’s even better.

[unicorn]

@Cippo i share the same view regarding trading fees.

Also agree on your rational for a 60/40 balancer but that particular split is too susceptible to IL, so if slippage is a big deal I would suggest something in the middle: 80/20 instead of 90/10.

Regarding @Cippo 2: I also favor having the treasury as a buy back machine but we need a “smart” treasury. That means having a smart treasury that adjust it’s parameters (and balancer smart pools have 6) accordingly to the circumstances. It is my opinion that the purpose of the treasury for the next 3 (?) months should be to facilitate deep liquidity and minimize speculation (aka small degens getting rekt) and AFTER that period adjust the pool parameters to reflect more of a automated buy back machine. That’s actually one of the reasons why instead of @8bitporkchop proposed 3 months (which I support), I would also support a shorter period (5-8 weeks).

Inflation does not play a role here because later we can decide on new parameters. Also keep in mind that there is 250k of unclaimed IDLE.

[8bitporkchop]

I’ve made an edit to the approach around step 2 and added it to the original post.

Basically, we won’t need to sell 1300 $IDLE if we can match 1% of the withdrawn amount (step 1) by buying ETH from the FeeTreasury.

[8bitporkchop]

Hi Cippo,

Re 1.
The logic is sound for a 60/40 IDLE/ETH in reference to slippage. However, I see the smart treasury as more of a primary market, as compared to the uniswap pool, and other exchanges, which is more of a secondary market. The secondary market is more optimised for slippage and has lower trading fees etc.

The Smart Treasury is more of a liquidity provider of last resort in this respect and should be therefore charging a higher fee to interact with (As time goes on; fees can start low and go up over time). The token-economics which occurs within the treasury will have a spillover effect into the secondary markets.
Example.
As fees from the idle protocol flow into the smart treasury there becomes an increasing price difference in the treasury price to the market price. An arbitrator can come along (when the opportunity cost is > $0) and interact with the treasury restoring the price to market price.

The good thing about a smart treasury is that if people don’t agree with this idea, the parameters of the pool can be changed over time by governance votes, such that the weights and trading fees are more optimised as a primary market for earning trading fees.

Re 2.
We are not diluting or inflating supply since no new tokens are created. And we are not releasing new supply into the market for frees (ie through a liquidity mining program), an investor must pay for the $IDLE we are investing into the treasury with ETH. Also, remember that governance could always reduce liquidity in the pool if they needed to fund community grants. As @Teo mentioned, however, there is still future discussions on how that mechanism should be implemented

[Fernando]

Hi everyone! Fernando from Balancer here

Very interesting discussions, glad you are looking into Balancer’s flexibility for your smart treasury.

We are about to launch a gnosis safe app for smart pools that could be just what you are looking for.
Regarding all trade offs I think you guys did an amazing research job and no decision will be bad IMO.

The cool thing about smart pools is that you can always change things like weights, trading fee etc, so you don’t have to be too worried about getting it perfectly right the first time around. I think you should start sooner rather than latter because many insights come from actual experience/observations on mainnet =) ofc you should start with little money and ramp up as you get more confident.

Please join our discord (https://discord.gg/qjFcczk) if you want to ask questions or just say hi =) The best channel for this would be #smart-pools.

Cheers!
Fernando

[unicorn]

@Fernando you guys already working on whitelisting IDLE so that we can get BAL rewards?

[8bitporkchop]

I’ve created a snapshot vote regarding the initial trading fee. Please show your support.

Snapshot

[simoneconti]

Hello Simone from Dialectic here.

It’s awesome to see this excitement and this level of research on the smart treasury concept and I would like to integrate the discussion with my analysis too.

To support what I’m going to say I share here our analysis regarding Idle fees of the last days.

1. First of all I support the concept of a 90/10 pool because it reduces drastically the IL and it implies a relevant slippage that discourages sellers. Idle is moving big but it’s not yet a mature protocol and although the utility of the token is clear it’s still not attractive to those who are unfamiliar therefore the main issue to face is the potential sellers that receive tokens for free and want to cash them out. A 90/10 pool could be effective in this sense.

2. Based on the fees analysis we can see that 58.4% of the fees are made in COMP, 32.7% in USDC, and 5.9% in USDT. If we decide for a threshold of 1.000$ (see point no.3) to make the transfer to the smart pool sustainable, we would take 9 days to transfer USDC, 49 days to transfer USDT and so on. For this reason I would consider to create a 90/10 pool composed by 90 $IDLE / 10 $USDC. By observing all the other lending or yield maximization protocols, it is proven that the main pools are the stablecoins ones because the high borrowing request so even if Idle will add new assets it’s likely that the main pool will remain the ones we have already up and running today. If the other pools (USDT, DAI, sUSD, …) will increase their volume and consequently their fees we can modify the pool changing for example in 90 $IDLE / 5 $USDC / 5 $USDT or 80 $IDLE / 10 $USDC / 10$DAI. This will avoid an impact of 0.3% trading fees (hp) on the USDC fees and any other assets we decide to add to the pool.

3. Regarding the threshold to transfer fees from the fee collector to the smart treasury as I anticipated above I would suggest 1.000$ because otherwise the impact will be too negative. In fact if we consider a trading fee of 0.3% + a tx fee of 3$ we would have an impact of 3.3% on 100$ and of 0.33% on 1.000$ much more sustainable.

4. In any case as we can see in the table “Smart Treasury” if we allocate 80% of the fees to the Smart Treasury excluding a MARKET Sell of IDLE it would take approx 8 weeks to have $20K of liquidity in Non $IDLE Token ($ETH, $USDC or the token we are going to choose) and this is a really low amount for a “liquidity provider” function we expect from the Smart Treasury (even of last resort). What I suggest here is to combine the concept of the Smart Treasury with a traditional liquidity mining program inspired by Sushiswap where the LP of the Smart Treasury will be rewarded (1/3 immediately available, 2/3 after 6 months). Rewards will decrease over time while the portion of the treasury composed by the fees increases. More importantly, we decide what the rewards will be per week in order to limit the expansion of the pool beyond certain amounts (500K/1M) as it would become inconvenient and given that the pool is 90/10 and given the vesting period of the rewards I expect that the LPs will mostly be IDLE holders who they strongly believe in the project.

[8bitporkchop]

Hi Simone,

I like this analysis a lot, and I have some of my own input on this.

1. Agree with the reasoning, 90/10 is effective in the early phases of the project. I see this changing over time as the project matures.

2. I don’t really agree that USDC is the best choice. In the analysis you can see that COMP is the largest income for $IDLE at this time. If you try to swap COMP -> USDC at this current time, your order on uniswap will be routed to COMP -> WETH -> USDC, charging an ~$6 fee, and having a 0.07% price impact. Because WETH (or just ETH) is the most commonly paired currency for tokens on uniswap, it is therefore the most efficient pair to trade against. I think that this is true for balancer too, and am therefore still personally favoured to a IDLE/ETH pool.

3. Agree.

4. I like this idea, it would really promote the use of the smart treasury, but I wonder if we’re taking this idea in the right direction. Should the smart treasury be the main gateway into IDLE? In my mind, I think that the smart treasury completes the cycle for protocol fee’s, and $IDLE’s value proposition, and plays a role in $IDLE’s long term growth, but I don’t think that is suitable to everyone, especially people who want market trade $IDLE, as was mentioned by @Cippo, @unicorn , and @Teo , such a pool is susceptible to slippage given its 90/10 weightings. I have an alternative idea, why not create the liquidity mining for the uniswap pool which I consider the secondary market (in the same method you described), this way slippage is optimised, and trading fee’s are optimised. In addition to this, uniswap has deeper liquidity of other currencies so it is easy for example to go USDC -> WETH -> IDLE with minimal slippage.

I am very interested to hear what you think.

[Cippo]

Ciao Simone, thanks for your support. Let me go through your points:

1- Slippage certainly discourage sellers but at the same time buyers. To be honest If someone is going to spend his time implementing the smat treasury it would be useful if the balancer pool is used. I agree with you that IL is a relevant downside but I do believe that (as @unicorn suggested) the weights that maximes trading fees (reducing slipplage and therefore increasing volumes) and reduce the IL is 80/20;
2- To be honest I have not a clear view on this topic. Anyway I don’t think is really relevant. In 1 month AUM will be def higher, as trading fees. So we wouldn’t worried a lot about the gas costs;
3- I totally agree with you;
4- I would definitively exclude an market sell. But I didn’t totally get what your saying here. Could you be more precise please?

Thanks a lot

[unicorn]

1. agree with both 90/10 and 80/20 options. There’s no wrong way to go. Market conditions will shift over time and temporary favour one or the other and the treasury can always readjust the pool parameters.

2. agree with both @simoneconti & @8bitporkchop. There’s no wrong way to go. Market conditions will shift over time and temporary favour one or the other.

3. agree

4. agree with @simoneconti.

[8bitporkchop]

I think that the liquidity mining program described by @simoneconti can be further discussed in another post. It is not a dependency on the smart treasury, and can be further explored once the smart treasury is created.

Once the smart treasury is live, it will give us more evidence where this LP mining is best suited.

[mikojava]

I like how Pickle are doing smart treasury

Into the Brine Vol. 4 — Yearn Collab and Smart Treasury

We should definitely consider getting some inspiration from this project that has some similar goals.

[8bitporkchop]

I would love to hear the rationale for whitelisting liquidity providers. Is it just so the protocol has full ownership of the treasury?

[8bitporkchop]

I’d like to summarise where this discussion has gone so far, by writing down concretely what the spec is that we want from this smart treasury.

Smart Treasury Candidate v0.1
The smart treasury will be built using a balancer smart pool which allows flexible parameter changes of the pool, as the needs of the protocol change over time.

• Tokens: IDLE, ETH,
• Weights (Initial): 99/1 (IDLE/ETH) [Gradually adjusted after bootstrapping]
• WeightsAfter3Months: 90/10 (IDLE/ETH)
• SwapFee: 0.5% (pending snapshot vote completion)
• UseWhiteList: False
• CanChangeSwapFee: True
• CanChangeWeights: True
• MinimumGradualUpdateDurationForSwapFee: 3 days
• CanChangeTokens: True
• AddTokenLockTime: 3 days
• CanLimitBPTSupply: False

Bootstrapping Mechanism Candidate v0.1
The mechanism for initially funding the smart treasury using the ecosystem fund, and fee treasury.

1. Withdraw 130,000 IDLE from ecosystem fund (representing 1% of supply)
2. Convert all assets in FeeTreasury to ETH
3. If ETH value != 1,300 IDLE (1% of 130,000), sell UP TO 1300 IDLE on the open market until ETH value is equivalent to 1% of IDLE deposit
4. Deposit IDLE & ETH into the pool, bootstrapping the smart treasury.

This will probably need to be written as a smart contract too.
There will need to be an IDLE and ETH oracle in order to do this calculation. I suggest a 7-day average of uniswap price.

Fee Collection Candidate v0.1
All idletokens (ie IdleUSDCYield, IdleDAIRisk …) have the fee address pointing to FeeCollectionContract.

This is the minimum interface which the contract needs to implement.

interface FeeCollectionContract {
   function deposit () {}
   function setSplitRatio(uint ratio) {} // ratio of fees sent SmartTreasury vs FeeTreasury
   function setFeeTreasuryAddress(address newFeeTreasuryAddress) {}
   function setSmartTreasuryAddress(address newSmartTreasuryAddress) {}

   function addAddressToWhiteList(address addressToAdd) {}
   function removeAddressFromWhiteList(address addressToRemove) {}

   function addTokenToDepositList(address tokenAddress){}
   function removeTokenFromDepositList(address tokenAddress) {}

   function setAdmin(address newAdmin) {}
}

This contract will keep track of tokens which IDLE can collect fees in, such as DAI, USDC, COMP, WBTC.

• deposit() should only be called by a whitelisted address, according to the split ratio, a portion will be directly sent to the Fee Treasury, the other portion will be converted to ETH, and added to the balancer SmartTreasury.
• SetSplitRatio() Set what portion of fees as sent to SmartTreasury vs the regular FeeTreasury.

I think initially the admin should be set to a dev multisig account, in case there is anything that they need to do to get this contract ready, and after that it’s ownership can be transferred to governance.

I think the initial split ratio should be 80%, this, of course, can be adjusted over time by future governance.

Where to go from here
As a community, we should debate these parameters, and specs until we are happy with the requirements, then we can move onto the next phase.

[FedeCrypto]

I like the idea, just some questions:

1. What would be the best percentage for the pool in order to minimize IL and Slippage? 90/10 - 80/20 - 66/33 or what else? Maybe @Teo and @william can be more specific.

2. How about to insert into a pool a small percentage of $BAL? So we will increase the rewards from the Balancer pool, and we need to ask to put $IDLE into a whitelist too… The $BAL can be converted into ETH and accumulated into the Fee Treasury for later uses.

3. The idle protocol fees are a little low, near $1000 a weeks (as shown by @simoneconti’s analysis), maybe it would be better to wait at least 2 or 3 weeks to be able to put the fees in the Smart Treasury, isn’t?

4. How to create a staking smart contract for the tokenholders? They can put in stake their $IDLE with a cooldown of 7 days, they receive rewards and the $IDLE in staking will be put into the Smart Treasury? Maybe we can use the idle protocol fees for incentivize the staking.

5. How much is the Ecosystem Fund? How much 130.000 $IDLE will affect the fund for future uses?

[8bitporkchop]

1. The optimal percentage in regards to slippage is 50/50.
2. Perhaps this can be done in a future vote, we need to get $IDLE whitelisted to be eligible for rewards.
3. I’m not sure if you’re referring to the bootstrapping, or for the fee collection contract, but I’ll answer both.
   • Bootstrapping: If there are not enough fee’s collected to match the deposit, then we would need to do a 1 time market sell in order to raise the funds.
   • FeeCollection: A whitelisted address should only call the deposit() function, when there are enough fee’s accrued, and to minimising the % of gas costs, as @simoneconti suggested, using some threshold, ~$1000, however this is for a single asset deposit, this approach deposits all tokens from the contracts internal whitelisted token list at once, so maybe this threshold needs to be a bit higher. In anycase this is just an optimisation, and can be determined once this is developed further.
4. I assume that we could reuse the multitude of staking contracts which have been developed recently, and adjust it as we need, if we were to implement a staking program.
5. The ecosystem fund has 1,950,000 $IDLE in it, representing 15% of total supply.

[FedeCrypto]

Thanks you @8bitporkchop

@8bitporkchop

The optimal percentage in regards to slippage is 50/50.

So, maybe a middle way can be 70/30 or at most 80/20

@8bitporkchop

Perhaps this can be done in a future vote, we need to get $IDLE whitelisted to be eligible for rewards.

yes, true, mine was meant to be a suggestion, mybe for the future of the pool.

@8bitporkchop

The ecosystem fund has 1,950,000 $IDLE in it, representing 15% of total supply.

ok, so the $130K for the bootstrap of the pool it’s just a little part of the ecosystem fund, near the 6%.

@8bitporkchop

I’m not sure if you’re referring to the bootstrapping, or for the fee collection contract, but I’ll answer both.

yes, i’m referring to the fee collection of the platform, the 10% of the interest earned. Ok, it’s right, we can think about the threshold further.

[8bitporkchop]

The initial weights will be 99/1 in order to bootstrap the treasury. This will be gradually changed to 90/10 over 3 months starting from when the pool is created. If there is community consensus this could be adjusted to 80/20 over 3 months.

The discussion so far has been for a 90/10 initial weighting, with the possibility to change this in the near future, based on how the smart treasury performs.