There has been much discussion on establishing a smart treasury for $IDLE. Establish a Smart Treasury, and there appears to be community support for this.
At this point, I believe there is enough community momentum to move the discussion towards requests for candidature for a grant to develop this proposal. As a high-level overview of what such a system could look like. Iâve sketched a reference diagram with the required code that needs development.
The current fee address which idle (interest-bearing) tokens are pointing to will need to be redirected to a new address, in order to implement this idea.
There also needs be some scope of work for the initial deployment of the smart treasury, with the correct weights, pool parameters, and initial bootstrapping from the ecosystem fund.
As part of this post, please your post candidature for the grant, specifying the economic request, the scope of the work, and the time required to deliver the code.
Ciao @8bitporkchop! Thanks for your proposal. I wanted to propose the same mechanism. I do believe smart treasury can generate value for token holders and, in particular:
1- The buyback mechanism reduce circulating supply, increasing future âdividendsâ per token;
2- Smart treasury offers a service to the market, increasing liquidity and therefore enhancing trading volumes;
3- It can be considered a new revenue stream: being a liquidity provider expose you to the impairment loss but if weights are chosen in a smart way this potential loss is limited and more than offset by trading profits.
Said that, I donât believe it is still feasible. Your mechanism requires to swap the fees in ETH. At the moment Idle receives fees in 6 different stable coins. Transaction costs (ca. 3$ per transaction, depending on gas price) heavily affects your proposal. So I would suggest:
1- Convert daily fees in ETH as soon as we reach a relevant amount to be swapped per pair (at least 100$ per pair);
2- Start ASAP but swap fees in ETH only when a certain treshold is reached (ex. the gas cost of the transaction is lower than 1%)
I completely agree. The fees can sit in the âfee collectionâ contract untill a certain threshold is reached. Then perhaps a method like âdeposit(currency)â can be called on a specific currency such as USDC, DAI⌠. There shouldnât be any extra gas costs to users, since this method can be called at a later date, after some threshold is reached as you said.
First thing first, thanks @8bitporkchop for your work on this proposal
I think the chart you made correctly encapsulate all the interactions needed, one thing to note is that probably you will also need to convert part of the ETH to IDLE by market buying them (so eg directly swap USDC for IDLE) or the âFee Collection Contractâ should already have some IDLE available in order to make the 90/10 deposit required of IDLE and ETH in the Balancer pool/smart treasury.
With this in mind I wondering if the Smart Treasury could simply be a normal pool at this point (or a basic smart pool) because all the âsmartâ logic is now moved to the âFee Collectionâ contract. What do you guys think?
To summarize, the âFee Collectionâ contract:
will be set as the fee receiver for all IdleToken contracts of the protocol (IdleDAI Best, idleUSDC Best âŚ)
will have one or more whitelisted addresses that should be able to call a method for sending 20% to the FeeTreasury (potentially not needed if done directly inside the contract)
will have a governance method for setting the fee split percentage
will have one or more whitelisted addresses that should be able to call a method to market sell fees for ETH (and/or eventually market buying IDLE)
will have a method to add liquidity (IDLE and ETH) to the Balance pool/smart treasury
Yes for sure selling fees should be made in batch or after specific thresholds and having a keeper bot to manage that itâs something that would made this reliable and scalable and needed in my opinion
Regarding the balancer smart pool, it was my understanding that you can add liquidity from a single token (No need to market buy IDLE using extra logic). So the âFee Collectionâ contract as weâre dubbing it, just needs to perform a swap to ETH, and deposit that into the pool. This means that the pool is now (90-X)%IDLE, and (10+X)%ETH. The market makers can either sell their IDLE at a premium to the smart treasury, or the price of IDLE has increased.
Yes but if you provide tokens only in a single currency you are actually skeweing the weights in favor of ETH, so you are actually selling âlowâ some IDLE to arb bots basically
Yes makes sense
Can be the Fee Collector contract itself in this way this can be managed easily (deposits in the smart treasury and eventual redeems should be managed by whitelisted addresses / multisig through the smart contract)
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.
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
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.
@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)!
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:
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).
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!
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).
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!
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
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.
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.
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).
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.
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
,
Still TBD:
Qs for you: