EoI for Development of a Smart Treasury
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.
Snapshot - Should IDLE establish a smart treasury?
Snapshot - What should smart treasury weights be?
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%)
@8bitporkchop @Cippo many thanks!
agree on the momentum, the grant and the cost associated with swapping the 6 different stablecoins.
Besides 1 & 2 proposed by @Cippo its there any other option? @william can come up with some smart contract wizardry??
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
Am I missing something?
@Cippo welcome to the forum!
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
Thanks Will ,
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.
Balancer Docs - API docs for joining pool
Balancer Docs - Smart Pool [Section on Providing Liquidity]
The pool should be a balancer smart pool, so that future governance can change parameters such as weights, and tokens etc.
Re: Summarising the contract spec
Governance also needs an address which controls the balancer pool share token.
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.
Yes you are right I jumped to the wrong conclusion, so yes then specs are right no need to handle the IDLE buy side
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)!
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:
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!
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!
EDITs: fixing broken images + typos
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.
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.
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.
@unicorn How about we take this approach, which may be a compromise of the two opinions.
- Start pool weighting at 99/1 IDLE/ETH
- Withdraw 130000 $IDLE from ecosystem fund (This represents 1% of total supply)
- Sell 1% of that (1300) $IDLE of that to get ETH
- Deposit this into the balancer smart pool (Our smart treasury)
- 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
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