The Agaave Token

[Monstrosity]

Updates can be found on the wiki weekly recap agaave section

Why does Agaave need a token in the first place?

Firstly, Aave designed their protocol to include governance for making decisions on listing tokens, adjusting liquidation threshold, setting collateral rates, etc. Although not required we would want a good reason to remove this feature from the protocol.

Secondly, there are situations where the protocol may fail, If there is a significant crash to one of the token prices, there is a possibility the loans will become undercollateralized.

Aave uses the AAVE token for both use-cases. AAVE is staked giving the staker the ability to participate in governance decisions as well as receiving staking reward (the fees generated by the protocol).

If there is a shortfall event, the stake is sold to cover the shortfall effectively slashing the stakes. This is the reason stakers should govern and decide on risk parameters. Stakers benefit from rewards but they also take on the risk of the parameter they set themselves. Aave publishes a very detailed outline of this risk assessment methodology

Why not just use HNY, what is the purpose of the second token?

We could simply replace AAVE with HNY. However, this would expose all HNY holders - even HNY holders who do not stake. While only staked HNY holders will be slashed, the protocol will dump as much HNY as needed to cover the shortfall. A second token compartmentalizes this risk.

Why not use another token like xDAI or WETH for shortfall insurance?

This is effectively the same thing. Our treasury only holds HNY, so we would have to sell HNY before a shortfall has even taken place. Another token planned in advance would allow us to sell HNY in planned increments but this would still put undesired sell pressure on the price of honey. The responsibility should be to those that actively govern the protocol, not all HNY holders.

Are there other benefits to using a second token?

As the 1hive community grows I expect 1hive to be more and more risk-averse. Shortfall events should be very rare and we don’t HAVE to insure against them. However, it will be harder to attract larger amounts of capital without a shortfall insurance mechanism but the protocol will work.

The real benefit of having a protocol-specific token comes from the flexibility it gives us in engineering incentives. Discussions of a radical or aggressively high cost marketing deployment strategy appears to be undesired by holders of HNY. However, with a second token we would have the flexibility of distributing the new protocol-specific token to the 1hive community and attract a bunch of other communities to xDAI/Agaave/HoneySwap ecosystem.

We can do this by including a very specific fair launch to users, investors, and partners. Badger DAO executed this well. A fair launch means we will get some fresh liquidity from outside our community. Also, 1hive does not have to pay for the entire Agaave project. Some of the compensation can come from the Agaave token itself. The community is much less likely to use a large portion of the HNY pool because again we would crash the HNY price, and even if we did, we would not have the flexibility of a protocol-specific token.

Is there any reason to believe the 2nd token doesn’t have a value that decays toward zero?

• Consider this project is simply a fork of Aave. If Aave is a successful token why wouldn’t Agaave have value? Agaave has all the same value propositions as Aave.
• We are not reinventing the wheel. If you look at a token like COMP, its only utility is governance of the protocol. The inflation goes to borrowers and lenders since they are the actual stakeholders of the system.
• The primary objective is to accrue value towards HNY holders with as little risk as possible. Of course, we want this new token to also be valuable (and if designed right it will). This can be discussed further but for example, 1hive’s support in funding the project and the great community it offers In return Agaave could mint ~20% of it’s total token supply over to 1hive common pool. It is worth noting that with delegated voting honey holders could vote on the Agaave governance through the holding of HNY.

What about protocol fees?

If we use a second token, this should be used for governance and the token can be used for shortfall insurance staking. This way those who have a vested interest in governance are those who take the risks. This is no different than Aave. However, if 1hive has 20% of the token supply they could stake the entire token supply and receive 1/5 of the total staking rewards. Just like with Honeyswap fees, all Agaave token rewards would be swapped for HNY tokens providing a constant buy pressure on the honey token.

What would this new token look like?

If we decided to use a second token, there are a lot of ways we can approach this so we would establish a team to work on the issuance policy.

Summing up

The main goal here is to grow our ecosystem and accrue value to HNY not necessarily utility. The utility is not the end, it’s a means. HNY value is the end.

References:
Announcing Agaave, Aave on xDAI

[solarmkd]

I was hoping that Honey will be used, but after i’ve read the explanation I’ve changed my mind, it makes sense to have separate token and i like the idea of the fair distribution. Aagave can bring new wave of liquidity and can offer competitive rates to attract investors from Mainnet and is needed as platform to keep HNY more stable .

[Stonky]

Thank you for the explanation. I did not have a position whether HNY or another token was a better call, but now I see the thinking behind and I believe that it truly makes sense.

Hopefully this will boost liquidity even more.

[troiano9]

I like the idea of the 2nd token and using Aave as the base is a solid project to start with. Anything that promotes adoption and acceptance on xdai is only a plus

[lkngtn]

@Monstrosity

We could simply replace AAVE with HNY. However, this would expose all HNY holders - even HNY holders who do not stake. While only staked HNY holders will be slashed, the protocol will dump as much HNY as needed to cover the shortfall. A second token compartmentalizes this risk.

I don’t think this is a particularly compelling reason not to use HNY. The possibility that a slashing event would occur and dump Honey should be outweighed by the added buy pressure to lock up HNY to stake in the mechanism in the first place.

@Monstrosity

As the 1hive community grows I expect 1hive to be more and more risk-averse.

A possible counter-point is that as more utility is added to the honey token itself, the added diversity of use cases makes it a more reliable and stable store of value. In other words, similar to insurance products the aggregation of diverse risks helps to make returns more predictable.

@Monstrosity

The real benefit of having a protocol-specific token comes from the flexibility it gives us in engineering incentives.

This is buried as an afterthought, but I think it is the strongest justification for this being an independent token. Heres my view, which for the most part aligns with the corresponding section in the original post.

If we just use Honey, we can think of a fair valuation of honey as a function honeyswap, celeste, and agaave. As a Honey holder (and a whale at that) adding to the value of Honey is pretty attractive. However, Agaave is a two-sided market where you have lenders (liquidity providers) and borrows, without lenders you cannot borrow, and without borrowers you have no incentive for people to take on the opportunity cost of capital to provide liquidity as lenders. This poses a supply-side bootstrapping challenge, and in order to overcome it we would probably want to subsidize the supply-side in order to attract enough liquidity that we can offer compelling borrow rates.

As we have seen with Honeyswap and the farming initiatives, subsidizing liquidity providers is expensive and may not provide lasting return on investment depending on the dynamics of the demand side. If we were using Honey, these expenses would need to be approved as outflows from the common pool, and generally would compete against other initiatives for budget. This is a much bigger risk than a slashing induced sell-off.

However, if we create a new token for Agave then we have the entire supply of tokens to work with to help design a distribution strategy that will help bootstrap the supply side, without having to spend any Honey on supply side incentives.

@Monstrosity

If we decided to use a second token, there are a lot of ways we can approach this so we would establish a team to work on the issuance policy.

I think this is key, I think that an independent token for Agaave could makes sense but it becomes really important when funding the project from common pool that we have a good understanding of how the token will be distributed, how it and the project as a whole adds value to 1hive, and how we expect the relationship between participants and token holders in the agave project to be integrated into 1hive and vice versa.

If we can get those things right, it feels like not just a home run for this project in particular, but also would provide inspiration for future projects that the community may pursue.

[Monstrosity]

Thank you Luke for the positive comments, if article was written in reverse (token issuance flexibility on top, slashing the staker risk on the bottom) it sounds like it would have been a homerun for you.

@lkngtn

A possible counter-point is that as more utility is added to the honey token itself, the added diversity of use cases makes it a more reliable and stable store of value. In other words, similar to insurance products the aggregation of diverse risks helps to make returns more predictable.

I agree but it could be a hard sell when including the other points of the post.

@lkngtn

This is buried as an afterthought,

yeah, I am now just noticing it was poorly worded. The title states it as an after thought but the very first sentence is “the real benefit…”

@lkngtn

we would probably want to subsidize the supply-side in order to attract enough liquidity

After farming I am not thrilled with the idea of subsidizing for higher APY BUT I am open to everything. If we did some type of depositor (maybe even lending) subsidy I would like to see some sort of dynamic subsidy. we talked about a dynamic fees model with Honeyswap but I don’t think this is going to happen so maybe this gives us an opportunity to try a dynamic model with Agaave. Granted they are not the same so we can’t really compare but we may learn.

As long as liquidity is below X and APY is below Y fund it with Z amount to bootstrap with a min APY target through rewards until it reaches a minimum target liquidity. Also we could do it without a time period so in theory the ‘rewards’ could stay there forever if they all get above the target quickly. Alos, if we plan a critical few token and token pair launch we shouldn’t have to worry about spreading out liquidity to thin. such as: wxdai, weth, honey, wbtc, ?, ? ,and maybe an LP token like wbtc-eth, hny-xdai. Some may mention listing Agaave but based on Aave the self token isn’t being borrowed so I wouldn’t list Agaave.