Provide quotes/budget for Smart Treasury development

💡 New Features & Improvements
#8

Say the balancer pool is weighted 90/10 IDLE/ETH, and the pool is balanced, (so that 90% of the pool is in IDLE, and 10% in ETH). If you add 1 ETH to the pool, without adding any IDLE, it means that that now there now slightly more ETH value in the pool than $IDLE, meaning for a moment, the value of $IDLE has increased slightly. The balancer pool naturally wants to return to the weights as defined.

If the market value of $IDLE is unchanged, then there is an opportunity for someone to sell $IDLE to the pool, restoring the 90/10 weights.

If no one sells, this means the market value of $IDLE has increased.

4 Likes
#9

Yes you are right I jumped to the wrong conclusion, so yes then specs are right no need to handle the IDLE buy side

2 Likes
#10

Ciao @8bitporkchop, are you sure about that? Honestly I’m not an expert of balancer pool but in Uniswap for example you have to provide both ETH and Idle in order to increase liquidity. Moreover wouldn’t it better to buy in the market IDLE? In this way you start the buyback mechanism. Ex. you have 100$ equivalent in fees, you swap 90$ equivalent of IDLE and 10$ equivalent of ETH and then add all the tokens to the balancer pool. In this way if the price of IDLE is “low” you can buy back tokens at a good price, decrease the overall circulating supply. Am I wrong? Thanks

1 Like
#11

Hey @Cippo, you are correct on the mechanism and it might not have been clear before, it is however a supported feature for balancer pools (linked FAQ post). Balancer essentially does this when you add liquidity from one token. This is the function to call joinSwapExternAmountIn() source code Link . I’ve posted the documentation link above link again. This uses the ETH that is deposited and buys 90% of that into $IDLE from the pool to mint a new pool share token.

1 Like
#12

@8bitporkchop mmm yes I thought they could offer that service, if it’s like this it works! Let’s decide depending on which solution is easier to implement (I’m not an expert)!

2 Likes
#13

Great insights here @8bitporkchop @Cippo

It seems like we all generally agree on the structure’ fundamentals of the smart pool, but I’d like to do a quick recap to summarize where we’re now and add some color.

  • Assets/Weights Composition. Looking at the related Snapshot and the sentiment here, @8bitporkchop’ 90/10 IDLE/ETH proposal is the way to go. I agree with the rationale, as it would dampen IL. As reported in this article, this is IL at different pool’s weights:

1100×600 77.8 KB

However, this wouldn’t optimize in terms of slippage, and in our scenario, it’d be ~3% at $200k pool’s net worth for a $1k trade. I would think this can disincentivize price discovery there, but depends on the purpose we want to give to the SmartTreasury (more buyback machine, or more liquidity provider).

1028×608 37.4 KB

  • Pool Inception. Seems like the discussion is here; @Cippo is suggesting that we should convert 90% of the Treasury funds (when it reaches a min threshold, say $5-10k? Treasury is growing ~$100/day now, and will be more with growth) into $IDLE with a market-buy. But if Balancer does that automatically, as @8bitporkchop reported, we might then go straight with sending fees to the SmartTreasury in ETH once it reaches the threshold (with a gas price check). @8bitporkchop I saw in Balancer Discord your convo about the function joinSwapExternAmountIn() (kudos for it) and for forwarding fees into an existing pool that function seems to be a nice solution, great!

:clipboard: Still TBD:

  • Trading Fees. @8bitporkchop suggested to start with 2%, I’d say it’s fine but we should be flexible on adjusting it as it depends on the nature we want to give to the pool. And the incentives we want to put in place for arbitrageurs to trade against us. Does anyone have more inputs about it?
  • Parameters Controller. With Smart Pools we can have fixed or flexible parameters, and get setup at inception (and then managed by a Controller). Parameters are, as discussed, token composition, swap fees, and weights. Would like to hear your opinion on how we can handle it. I generally think we should find a flexible solution here.

Next step would be to formalize this proposal with all steps/scope (both with pool’s setup and connection to treasury). We would like to suggest a grant framework for it next week (starting with something light for first proposals, but iterate on it to adapt with community needs – this is a good read for this topic).

:question:Qs for you:

  • What is the main purpose you guys want to give to this SmartTreasury? You would see it more as automatic buyback machine (fees buy $IDLE to rebalance weights), token issuance machine (source $IDLE that the protocol needs for incentives simply by withdrawing them from the Smart Treasury), or liquidity provider (guarantee liquidity to allow to trade against the protocol)?
  • In the first post for this thread, community grants were funded by the SmartTreasury. I think we would need to define some priorities on that, eg (but not limited to) improve protocol layer (new supported assets/downstream protocols), incentivize collaborations (partners programs), improve material (documentation, guides, tutorials), or do promo/marketing? Feel free to add whatever you can imagine that actually adds value, but I would love to hear your opinion about it!

EDITs: fixing broken images + typos

4 Likes
#14

Main purpose (initially) for the smart pool: liquidity provider. Trading fee should reflect that.

Purpose of grants: improve protocol/partner programs/documentation.
Personally I oppose marketing/promotion and would rather let the protocol, the TLV , the strategies (APY) , the IDLE DAO and the partnerships do the marketing.

One thing I would like to add to the list are grants to reward community activity and participation. For example hackathons, devcons, community management, IIPs that get approved etc

4 Likes
#15

The initial purpose of the pool should be as a liquidity provider. I like to think of it as a liquidity provider if last resort, as long as the liquidity is deep, price should come to equilibrium across all exchanges. I think the trading fees should start low, but gradually increase to reflect this, at this point the smart treasury will function more as a buy back machine.

I agree that a grant framework should be setup!

There is one more point that requires concensus by the community, and that is how much liquidity to provide from the ecosystem fund to bootstrap the smart treasury. I initially suggested 10,000 $IDLE. How does this figure sit with everyone? In future governance decisions more $IDLE can be transfered from the ecosystem fund to the smart treasury.

2 Likes
#16

If it’s decided that the objective of the pool (at least initially) is liquidity providing, in my opinion 10k IDLE will not be enough, far from it.

For deep liquidity and establish the pool as the main market I think 500k IDLE are necessary to bootstrap the treasury.

1 Like
#17

I agree that 10K is not enough for “deep liquidity”, but it would be enough to bootstrap the pool at the start. If we tried to do 500K you would need to sell 10% of that (50K IDLE) on the open market, where there currently isn’t liquidity to do so. If we start with a small amount for bootstrapping, and then add more liquidity to it over time to reach a goal such as 500K $IDLE in treasury.

1 Like
#18

I am aware of the consequences @8bitporkchop of bootstrapping with 500k.
If the goal is deep liquidity and flushing speculators to create a (sustainable) community owned governance token and treasury, then 500k is what should be done.
Results would been seen in the short term (2 weeks).

1 Like
#19

I don’t agree with this approach given the low liquidity a trade of this magnitude will be perceived as a ‘rug pull’ and could affect $IDLE’s reputation long term.

I think that starting small is a good approach, but maybe including a linear investment schedule for adding $IDLE liquidity over time up to a certain goal, or when a desired threshold is reached. This can be voted on after the bootstrapping is complete. This way we won’t have to sell on the open market, but rather through the balancer pool.

3 Likes
#20

@unicorn How about we take this approach, which may be a compromise of the two opinions.

  1. Start pool weighting at 99/1 IDLE/ETH
  2. Withdraw 130000 $IDLE from ecosystem fund (This represents 1% of total supply)
  3. Sell 1% of that (1300) $IDLE of that to get ETH
  4. Deposit this into the balancer smart pool (Our smart treasury)
  5. Over a period of 3 months adjust the weights such that they represent a 90/10 IDLE/ETH balancer pool.

Would like to hear some feedback from: @Teo @william @Davide @Cippo @FedeCrypto @noahniuwa @krzysu @mikojava , and anyone else in the forum. I will probably have to put this to a snapshot at some point to gauge consensus :white_check_mark:

EDIT: Regarding step 2, we could also raise the matching ETH funds to create the pool by selling some of the fees already accrued in the FeeTreasury address. That way no $IDLE needs to be sold on the market. The amount of ETH swapped should be the equivalent of. That can be derived by a 7-day rolling average of the $IDLE price.

(130,000 / 0.99 ) * 0.01 = 1,313 $IDLE

Any residual ETH that needs to be purchased can be done as described in step 2

6 Likes
#21

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 :slight_smile: ;

@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 :slight_smile: But I do believe in buyback mechanism when a project is solid. Let me know what you think!!

3 Likes
#22

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.

1 Like
#23

@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.

1 Like
#24

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.

1 Like
#25

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

#26

Hi everyone! Fernando from Balancer here :wave:

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

7 Likes
#27

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

1 Like