We would run into the same problem of volatility, both market cap and TVL are unpredictable.
There is merit in having a “petty cash” or “quick cash” fund for acid test-type expenses that come right away. The idea being that not having cash for immediate liabilities is worse than not getting a good APY on treasury reserves. Maybe this can be a “current account” in Aave/Compound.
An alternative would be adding stablecoins to the Balancer treasury mix. For example, 80
PICKLE - 15
ETH - 5
DAI pool. This will reduce impermanent loss while keeping the automatic capitalization mechanism of the Smart Pool working properly and transparently, including most protocol reserves.
@Mah_Dills mentioned a cap to the treasury. Of course, it also makes sense for the protocol not to hoard cash that could be invested or spent elsewhere. A way to do this within the Smart Treasury model is through the programmability of adjusting the weights of pool assets. Meaning, if we are at 80PICKLE-20ETH capital-to-currency, we call the Smart Pool contract to make the ratio 85PICKLE-15ETH. This is the equivalent of moving cash to
PICKLE stakers & LP farmers and boosting APY, done transparently within the Smart Treasury framework.
My concern is that since this pool also reflects treasury holdings, which reflects the value of PICKLE (since it determines our ability of the community to pay for development, audits, marketing…), then we risk a death spiral if there is a major shock to PICKLE price:
PICKLE price shock -> lower treasury -> community loses power to act -> PICKLE loses value -> repeat.
Or think of it this way: the community will use the treasury to support and develop PICKLE to ultimately boost the value of PICKLE. Therefore it’s especially important that when PICKLE is weak, the treasury stays strong.
Therefore I would have assumed it wiser to keep the larger portion of the treasury in stable assets or reserve assets such as ETH or WBTC/tBTC/renBTC. Remember, particularly in the early stages of the project, the idea is that the pool acts as a buyer of last resort, and volumes will intentionally be lower than on the main UNI pool, which is where price discovery happens. Therefore we needn’t worry too much about having large PICKLE reserves to reduce price slippage. In fact, price slippage might even be a feature (? not sure about this…), since we want the pool to rebalance quickly.
Anyway, please correct me if I’ve misunderstood the mechanics of this.
Just wanted to say that I echo @brinosaurus_rex’s comments and concerns here. I feel like I might be missing something. I am curious to learn more.
@brinosaurus_rex think you are right on many of your assumptions. One correction is that the idea of the Treasury being in a pool is not as a buyer of last resort, but as a liquidity provider of last resort. The buyback happens would happen near-constantly as protocol fees are introduced. What the protocol would need in case of a bearish time is an injection of liquidity, hence the heavy distribution of assets towards $PICKLE. This feature can be manipulated via the controls for index-weights, and trading fees (slippage as a feature, as you say). So, for example, if times are good, you can keep a higher proportion of currency in reserves.
Another reason, in my understanding, for an increased amount of
PICKLE, is for the intention of the automatic buyback machine. That is, as liquidity is added by the protocol in currency, it is rebalanced into a
PICKLE at the rate of PICKLE in the pool. e.g. if the pool is
90PICKLE-10ETH whenever 100
ETH are added, 90 will end up as
PICKLE as the Balancer arbitrageurs do their thing. When we change these numbers to say,
10PICKLE–90ETH, the automated buyback is still working, but the effect of adding 100
ETH is that just 10% of that value will end up being rebalanced into
I think the issue you are getting at has to do with initialising the pool, which is where I propose we use a huge chunk of cash to market-buy the reserve. I understand this could be too bold a move if it causes a cash crunch down the road – which would be a very undesirable approach. There are two ways to go about this:
- Instead of a market-buy, “issue” the reserves. These reserves won’t be circulating at the moment of issuance – again, this is not inflation, which is a monetary concept. Personally, I favour this approach, might even be better than a market-buy. In time, proposals about putting some of these
PICKLEreserves can help achieve higher rates of growth during boom cycles through the mechanism of issuance. This also leaves us with more value in the Smart Pool at the time of launch.
- I would also not mind a gradual approach to building the
PICKLEreserves i.e. the capital side of the Treasury, starting with a different weightage, even reserve weightage to the one suggested (lopsided in favour of currency) and taking it from there. The economic rationale and mechanics would still be maintained, and the treasury can still be used as an automated buyback machine and, but the liquidity depth and the ability to provide liquidity of last resort would be affected. Adding BTC as reserves is also possible, on the currency side of the treasury (where
DAIhave also been proposed). This would help the price of $PICKLE itself in times of BTC booms.
I have been studying this in light of the observations by @brinosaurus_rex: https://medium.com/balancer-protocol/building-liquidity-into-token-distribution-a49d4286e0d4. This is another template by Balancer which some projects have used. In it, a project starts with a pool lopsided in favour of their project token, in order to provide meaningful liquidity at launch. As the launch progresses, the weights of the pool are adjusted to build currency reserves. The main issue is each adjustment step (moving say, from
90TKN-10ETH) puts downward price pressure on the project’s token. The Balancer authors considered this a good feature to counteract the initial speculative run in the price of newly-launched projects. The goal is to accumulate reserves and get the ratios to flip, eventually ending in say,
10TKN-90ETH or even
2TKN-98ETH. This is more in line with what a corporation does. Some corporations like Apple try to keep treasury stock at less than 1%. After a buyback, Apple may have >3% of its treasury in its own stock, but it rapidly re-issues those shares to push its growth.
I’m not totally convinced that PICKLE needs a smart treasury at this point in time. There’s a fair bit of complexity and I don’t fully understand the need for the auto-adjustment mechanism, in particular since it can backfire in the kind death spiral mode I mentioned.
How about the idea I floated a while back, of making PICKLE into a treasury-backed token? This can be achieved by allowing anyone to “redeem” PICKLE in exchange for a portion of the treasury. Then we just pump all pJar profits into the treasury.
Implementation ought to be fairly simple (right??). You just need to allow access to the treasury either using the multi-sig, or “redeem” a portion of the holdings in exchange for PICKLE.
- pickle value has a floor based on the size of the treasury (plus future earnings)
- pickle value does not rely on staking, benefits accrue to all token holders
- treasury is not liquid, so can be invested elsewhere (lending, whatever) to compound gains for all pickle holders, or used in other ways, for example participating in governance of other protocols (think CRV).
- pickle itself has real value backing it, so can potentially be used as collateral for other pools.
I wrote a bit more in the buyback-and-[something] thread. I don’t know if this has been done elsewhere but it seems sufficient for our needs and much simpler and easier to understand than smart pools. (Maybe we can call it a “dumb” pool…)
@brinosaurus_rex I agree with your advantages, particularly:
benefits accrue to all token holders
This was one of my main motivations for proposing a Smart Treasury.
The biggest issue I see with explicit treasury-backing is that it can easily be construed as an asset-backed security (ABS). This would put Pickle Finance in a not-so-small pickle should the SEC come “knocking”. Do remember that Smart Treasury (and even our current Treasury) are implicitly backing the value of Pickle. We are working to improve the value-capture aspect of the project, while still maintaining the nature of the governance token.
From a legal opinion of one of the advisors in my IRL blockchain startup, even revenue-sharing (i.e. dynamic staking) could cause the SEC to give us a knock. Buybacks (with burns) at scale have been done most exemplary by Binance’s
BNB without issues as the overall consensus is that it will not change the nature of the token, just a tweak in the tokenomics.
Question: if we were to go Smart Treasury with a
10PICKLE–90ETH or something along those lines, would you consider the risk of price shocks to be sufficiently minimized?
Regarding the SEC, you make a good point, one that I hadn’t considered. I thought one of the main criteria to be considered a security was centralised control, which in the case of pickle (if/when it transitions to a DAO), is not really the case. And since we already confer a level of ownership on the treasury through governance rights, and allow people to stake to gain a portion of the income, I don’t see a huge difference between this and just removing the staking requirement, and accruing value directly to PICKLE via the asset-backing mechanism.
And anyway is not basically what a pJar does? Ie. you contribute capital to the pJar to gain shares in the form of pUNIDAI tokens (or whatever) and with time your pUNIDAI become more valuable until you decide to redeem them for your initial capital plus gains. With asset-backed PICKLE, it conceptually quite similar. PICKLE would be like a kind of meta-pJar where by buying PICKLE you are buying in to the cash flows from all the pJars, and when you want to cash in your gains, you sell PICKLE again at a higher price.
Anyhow I’m not sure what the SEC could or would do. In the case of your startup, you have personal liability, they can shut your business down, etc. With a DAO it’s much less clear.
*[Disclaimer: I’m not a lawyer! Thankfully not a US citizen either.]
If we do decide to go the smart treasury route, I would indeed be much more comfortable with a larger allocation to reserve assets. Having read the article, I think having a large allocation to the token is intended as a strategy to provide early liquidity and as a mechanism for dynamic token distribution. Since PICKLE is already past the early distribution stage, and since the smart treasury is not intended as the main source of liquidity but as sort of war chest for future improvements, we’re better off aiming for stability by having a large allocation to reserve assets. (20/80 or 10/90)
The question remains of where to get the PICKLE from. Either we buy from the market (this can be front-run, not sure it’s a good idea). Or we can mint the required PICKLE (is that possible?). Relative to all PICKLE in existence, its a small amount, plus it doesn’t dilute anyone since it’s not free-floating. I have no strong opinion either way on this.
Re: Split and Size
It’s better to start conservative and try a 10% PICKLE and 90% CURRENCY split IMO. We can adjust the split as time goes on so that’s not something I am worried about.
I’m more concerned about the question of how much should we “trial”. If it’s going to be 90% CURRENCY, I think we can try it with a bigger chunk. Maybe like $250k worth? Let’s start discussing some more specifics.
Re: Buying a large amount of PICKLE without getting front-run
We could possibly do a direct trade w/ the PICKLE in the dev fund. I think most of the core team would not mind selling some since we have such a fat stack of PICKLE anyway. Of course the price must be something that is fair and agreed upon by everyone.
I think it may be fair to allow an OTC trading mechanism as well, instead of just from the dev fund in order to avoid the appearance of dev dumping. Definitely think you guys deserve to get a good price though.
I think the point @leekuanjew is making regarding the exodus of funds from our ecosystem while giving out “naked-staking” rewards is a very important one and want to advocate for rethinking this model and replacing/supplementing it with increased rewards for providing liquidity in the Pickle Power Pool.
If we were to implement the Smart Treasury Approach we would be able to boost rewards of the Pickle Power Pool with funds that enter the smart treasury in it’s usual reward currency $Pickle.
This would shift the approach from paying out rewards from earnings generated by the protocol to naked-stakers to paying out said rewards to LP providers.
Since the LP providers are doing an important job for the health of the protocol I feel like this would be a more sustainable approach and would at the same time provide a way to “utilize” the funds that are used to earn “fees generated by the protocol”.
Whether we still implement a “naked Pickle” staking option is debatable, but probably still a good idea. But with this approach we would make sure “the switcheroo” is never able to happen since we can manually adjust the balance between fees to LP providers and fees to naked stakers. What that balance shall be, I have no idea, but at first glance it would make sense to have a 2:1 ratio per pickle staked in favor of LP providers since they also bear double the risk.
This is a cross post from the discussion around cap and rewards, thought it would add value here as well.
I think if we go this Smart Treasury route (still not convinced we should) then this is a great idea. I don’t know whether the Dev team have been selling any pickle as yet or plan to, but there’s no point sitting on a mega jar full of green dildos while you work your asses off. And I’d much rather the treasury bought them for an agree purpose than you needing to sell them on the market. Plus if we are looking at 10% of $250k then it’s not a massive amount anyway.
This is a good observation by @0xBoxer. Certainly, implementing “Switcheroo resistance” is desirable. If we are to keep the redistribution of Treasury currency, it would be better for a ratio of 2:1 to be maintained between
PICKLE farmers v stakers. For example, if stakers are to be paid 4.5% of profits, then farmers should get 9% of profits. Although this doesn’t solve the issue of dishing out cash from the system, at least we can make the “cash-dividends” system fairer and more equitable while also incentivizing farming over naked staking. This could also (long-term) supplement the decreasing
PICKLE rewards to farmers without altering the emissions.
I am thinking, however, that the mechanism for enhancing the
PICKLE–ETH farm contract and making it also harvest another ERC-20 like
WETH from the Treasury, is not a straightforward engineering task. We’d also be able to achieve “Switcheroo resistance” by implementing Smart Treasury and repealing naked-staking.
@BigBrainBriner I like this approach.
Let’s change the nature of the split to favour currency then. The weight of
PICKLE is basically the percentage of revenues we want to go to a buyback (or the percentage of revenues past the cap, if a stablecoins cap exists). I’d propose we pump it to 30% as in a
How much to “trial”?. Of course, we wouldn’t want Treasury erosion. If I imply correctly from your suggestion of $250k if it is
10PICKLE–90ETH (also assuming “currency” to be
ETH since that’s what we will be paying stakers in anyways) then you wouldn’t want to put more than $25k on
PICKLE to start? That leaves a
30PICKLE–70ETH proposal with a starting volume of $83.3k-odd. Seems lowish, maybe we can go $150k.
DevFund swap and price. I am satisfied with this idea. We can use the implied Uniswap price. Think that’s fair. But as @pipickle mentioned for appearances’ sake I think complementary to this swap we could take an opportunity to bring some guidelines to the use of the
DevFund. Especially now the multisig has non-Dev members. Is this fund for the development of the protocol (i.e. operations, in-house design/engineering/r&d, salaries)? Or, is it compensation for the developer-founders? Are withdrawals then possible at any moment and for any amount – or should there be some allocation/vesting – or subject to DAO approval? These answers would all be appreciated by the community.
Finally got around to reading this thread…I wanted to be completely focused to understand the complex machinations being proposed.
Personally, I lean towards the conservative side when it comes to Treasury funds because while a rising tide may lift all boats, the converse is equally true and I would hate to find ourselves in a pickle just because we tried to maximise Treasury yields.
Since @BigBrainBriner just announced a $500K Treasury cap, we could possibly allocate $100K to initialize a Smart Treasury and see how it goes. If successful, we could then propose to increase the total cap to say, $750K, adding another $250K to the Smart Treasury, and so on…
We retain $400K in stablecoins at all times…
See what you did there, ser.
@yyctrader I like the idea of including the Smart Treasury inside the Cap.
capped_treasury = strategic_stablecoin_fund + smart_treasury
I also like your babySteps™ approach to Treasury expansion.
At least that way we get all our bellies full before we give out the excess as bonus rewards.
yes, I think this makes sense. how about we start off with:
- 400k stablecoin stack
- 100k smart treasury trial (20% PICKLE, 80% CURRENCY)
And of course, we can adjust accordingly as time goes on. I decided on 20/80 instead of 10/90 because 10% seems too small to actually have any kind of significant effect.
yes, I think this makes sense. how about we start off with:
- 400k stablecoin stack
- 100k smart treasury trial (20% PICKLE, 80% CURRENCY)
@BigBrainBriner I second you on that.
Modifying my suggestion above:
- No issues with economic rationale.
- Smart Treasury composition 20%
PICKLEfor Smart Treasury will come from a swap with the DevFund using $20k of the $100k allocated to the Smart Treasury from the $500k Treasury cap.
- Trading against Smart Treasury will incur a fee of 10%. As common with AMMs, fees will just sit in the pool (Smart Treasury).
- Controller retains rights to change Smart Treasury params. The Controller being the DAO/multisig. Params being token composition, trading fee, and token weights.
Let’s go for it - I still don’t think I have gotten my head around the true benefits of a Smart Treasury (no need to try and explain, I have read plenty ). But enough smart people do think it’s a good idea so I am all for it.