Anchor v2 Borrow Model

The current Anchor protocol which receives users staking through Lido requires, in part because of its decentralized structure, lots of time and resources for back-end contract integration and lengthy audits for each new b- asset collateral that needs to be added.

Liquid staking derivatives are also starting to become fragmented with competing models. Also, as Anchor moves cross-chain, certain b-assets would compete for liquidity with other well-established native staking derivatives such as mSOL.

If the Anchor community could implement a new borrowing model that mirrors the deposit side with a two-sided market then the process of adding new collateral types would be greatly simplified and expedited.

In this model, in addition to changing b-asset contracts to redirect the staking rewards from Anchor back to the user, Anchor governance would vote to add rebalancing liquid staking derivates as new collateral, for example: LUNAx, mSOL etc. Using these compounding liquid staking derivatives as collateral for borrowing means that the user’s collateral is increasing in value.

Anchor protocol then charges an interest rate comprised of the base borrow rate plus the staking reward percentage added on. Users pay the accused interest debt in $UST when the loan is closed or liquidated. This essentially mimics the same b-asset model but is even more decentralized with a cleaner match of borrowers to depositors.

Think of the following example of a borrower with mSOL. User stakes mSOL as collateral with Phantom wallet on sol-anchorprotocol-com →receives solana UST → Interest is charged (average weighted staking reward% + base Interest rate) → mSOL interest fee paid in UST → interest payments sent to depositors.

Since Anchor is not directly receiving staking rewards this simplifies the onboarding of new collateral types. Using simple risk metric filters such as liquidity would make it easier for governance to quickly pass proposals for new assets in a fraction of the current time.

In Summary, this model would be a two-sided market where borrowers are matched to depositors:

  • Borrowers post liquid staking derivatives as collateral i.e., xLUNA, mSOL etc No staking rewards are delivered to Anchor protocol
  • Staking rewards compound to the user/borrower or under the b-asset model are redirected to the borrowers
  • An interest rate is charged in UST to the borrower with a weighted average staking return % added to the base borrow rate.
  • This single interest rate return from the borrower is used to pay depositor interest

Key Point:

  • b-assets in the current model required 2-3 months of protocol integrations and audits that constrict capacity to add more than a few assets at a time
  • Adding new collateral types would only require a governance vote and could be immediately implemented allowing unrestricted new assets in a fraction of the time
  • This model is consistent with and adds an even greater degree of decentralization, as it more directly pairs lenders with borrowers
  • In @ryanology045 words, this allows the protocol to adapt and evolve in a way that is aligned with the rapidly expanding vast staking derivatives and yield bearing defi assets.
17 Likes

I like it. It’s practical and efficient!

(I would still like borrow APRs to decrease to logical numbers…)

7 Likes

How does anchor guarantee a 20% or even a smaller Apr based on just this interest rate? It’s not like everyone will be borrowing. And this interest rate will likely be far less than 20%, right? Aren’t staking derivatives necessary? Or is overcollateralization going to be used in a different way?

Edit: nvm I’m dumb I understand. I wasn’t accounting for the fact that the basset or liquid staking collateral staking interest isn’t coming from anchor’s pocket. It makes sense now

Sounds cool. How long would it take to implement v2 if it passed governance?

1 Like

How and when is interest going to be paid? Right now Anchor is paid in two moments, the ongoing staking rewards and the APR when the user closes the borrow position. If I understood correctly, the yield on the bAsset accrues to the borrower and the APR will take into consideration the staking yield, but that means the borrower will only pay in the end? If this is so, won’t this make the yield reserve issue worse, assuming borrowers won’t be closing their positions on a regular basis?

I also don’t understand how this would connect borrowers to depositors, seems it’s the same one large pool model, it just makes it easier to onboard new collateral and to charge different APRs based on the collateral (I’m assuming) and when Anchor is paid. It’s great, not complaining about this, but I’d like to understand the claim of pairing depositors to borrowers.

2 Likes

No, because this would affect LTV and necessitate either lending more or borrowing less to manage LTV as the extra staking interest Apr comes in as far as I understand. Wouldn’t it just mirror how ust gets interest over time, the same would apply continuously to any incurred debt from borrows. I’m also assuming the claim comes from the fact that the Apr will be flexible to match the individual circumstances of a borrower/lender. It also means people are free to lend their collateral to Anchor, not borrow, let anchor play with the collateral and get staking yield directly in their Terra Station wallet, right?

This is something that we still have to decide as a community and weigh the options. There are a few options: 1, periodic payments are required like a standard loan. This adds some layers that could prohibit borrowing. 2. paid at the end of the loan or liquidation could. This would be better for borrowers but yes if people took out loans for very long periods of time could affect the reserve. Flipside data will help us as a community decide what is best.

This takes the protocol out of the middle have to collect staking returns and helps decentralized it. Now interest isn’t being paid in two different streams, 1 from borrows 2. from protocol staking returns. This is more like a traditional money market.

This doesn’t affect LTV at all.

No. This is really the same fundamentally as the current model. The only difference is the staking returns are directed to the borrower and they pay that staking return directly to the protocol instead of paying to Lido and Lido directing it to Anchor.

1 Like

If your earn staked interest outside of anchor with bassets and earn debt interest inside anchor, how would it not increase LTV?

I see, thanks for clarifying.

Ok so it’s still to be discussed, but it’s a big part of the viability of this whole change. Flipside data will truly help us make a decision here, but I fear recurring payments may make it an hassle on some borrowers.

I wonder if it would be feasible to have Anchor take it’s cut from the deposited collateral as an alternative, say if you pay until X you do it in UST, if you don’t we take the cut from the collateral plus a small fee for services provided (since it’s growing with yield, should not be an issue).

Making it a criteria for the collateral whitelisting to have a pool with sufficient liquidity in any DEX that Anchor chooses to support.

1 Like

I like this as well… altough it could become a little expensive for smaller borrowers in terms of tx fees. Right? :thinking:

Maybe it isn’t that bad to have that bASSET part somewhat centralized…

I though that the idea was to directly affect the LTV of the borrower. but yes it could become a liquidity problem with long term borrowers…

We could also have some kind of a forward looking interest/refund model:

When taking out a loan, part of the borrowed UST is not received by the user but instead kept by Anchor as an advance payment on the loan’s interest for a set period of time (a month? six? twelve?). During this period, the outstanding debt does not increase, as interests have already been paid. It only starts to grow after the end of the pre-paid period. If the user wants to close his position before the end of the pre-paid period, the excess interests are deducted from the amount to be repayed.

Pro: Anchor gets periodic revenue that can be fine tuned to the average loan rebalancing frequency to avoid excess reserve drawdown
Con: the opportunity cost and increased ltv makes it less desirable to borrow from anchor

1 Like

I think it’s unavoidable that you’ll need to charge people UST as they go. During periods of market stability, many loans won’t be repaid and we run the risk of the yield reserve dropping and (despite being owed a lot of money) not being able to make good on the Earn side.

I don’t think it has to be painful. I’m sure there’s a way we could schedule UST payments and have them happen automatically. Users would just need to remember to keep some UST in their wallets.

If payments aren’t made, we could simply send a small portion of their assets to the liquidation queue to cover the missed payment.

That way, users could just forget about holding UST in their wallets if they’re okay with just spending their collateral. Unless there are transaction costs Anchor would be incurring, making thousands of micro liquidations all the time.

2 Likes

I think the use of a borrowing fee compensates for the “what if everyone borrows but doesnt pay back” scenario, which, by the way, is one of the least likely scenarios.
The utilization curve wouldnt get to the point that you wouldnt be able to withdraw all of your funds, thats the purpose. a small borrowing fee for taking out a loan will ensure that enough cashflow is available for depositors looking to withdraw.

I am absolutely loving this borrowing model. So to clarify, would this mean we will be able to borrow other assets such as beth or bluna etc? Making it similar to aave, compound etc?

I’m all for everything in this change just trying to get an idea of the new features we’re looking at!

That would become very meta, but there may be opportunity there, someone deposits bLuna to borrow UST, Anchor lends the UST and puts the bLuna up for borrowing aswell, leading to some extra cashflow, and could enable option markets to work using our reserves. But that would probably lead to some risk as in a day like today, most people would be flocking to take bAssets out and more than likely those borrowing would be happy to keep them as they would be shorting.

Understanding there is a need to update the Anchor model, my opinion is this V2 option fundamentally changes Anchor as a protocol. The idea of leveraging the income from staked collateral remains the same but it shifts from a savings protocol that captures staking rewards and distributes it to depositors to a lending/borrowing protocol that deals in UST.

I agree with what was said above, there will need to be some requirement to pay UST periodically. This is definitely shifting something that was automated by the protocol to extra steps for the user. Either they find UST somewhere else or they withdraw some collateral to sell it to pay back a portion over time. Maybe it is a better trade off for the protocol health but it is a trade off.

Also, if depositor APR is based on borrower repayment then couldn’t any collateral be approved for use?

From protocol narrative perspective, there will be no differentiator between it and all other protocols offering high but unsustainable apr on stablecoins which maybe was always the case since all are dependent on borrowers.

My biggest concern is this shifts Anchor to a direct competitor with other lending/borrowing protocols like Mars that will be built from the ground up for it.

2 Likes

Yeah I agree. Initially I thought it was a great idea as (in my mind) it was simplifying a lot the part of adding collateral.

But now I just think it is migrating that complexity towards borrowers (users/clients). But the intention here is to create solutions to users, not add complexity.

So I would not consider implementing said proposal nor any of the variants proposed in the comments above…

I think that some level of centralization is necessary and isn’t bad at all as long as it doesn’t create additional problems and provides solutions!

I actually think that this is a very interesting proposition.

This would open us up to basically every chain and it could potentially solve borrowing side while decentralizing Anchor as a whole.

Few questions though:

  1. Since Anchor would take more liquid staking derivatives as collateral, what would happen if the 3rd party platform fails? By using a verified and audited liquid staking derivative tokens Anchor might mitigate some risks.
  2. What if the loan would be paid every month or so, deductible from their collateral if the borrower does not pay the interest in UST? This would guarantee loan payments from borrowers while keeping the deposit side safe.
  3. Would a floating earn side work as well? If there could be a weighted average of all the staking rewards+borrowing fee, everything could be in equilibrium.

Thanks!

1 Like

The way I see it, the need to make bAssets easier to add is also paramount, 3-6 months per asset limits growth, if we don’t do it someone else will, but there could be a middle ground. As far as I am aware, there are two types of staking derivatives:

  1. Those that accrue value to the asset via price oracles, LunaX, wMEMO, …
  2. Those that accrue rewards to be claimed later, like bLuna

We could have two kinds of collateral, the two above, one easier to add (1) because it accrues via price appreciation, we could have a configured yield or an oracle to provide live yield % and use that to deduct from the deposited asset directly, those would be easier to add suposedly. The second kind (2) would maybe be harder, or perhaps there’s a way to wrap the asset into a common contract, to be used by all, not sure how viable this would be.

Kind of… deducting adds a LOT of transactions which means a lot of spending in gas fees. With smaller borrowers that would make it not cost effective to deploy a tx and thus could potentially leave a lot of dust undeducted…

If the borrower pays the tx fees he has to manually pay for that and it’s an extra step which adds friction to the end user.

As i see it it could be added as a “patch” to facilitate borrowing to larger borrowers while in the meantime a bASSETS are developed…

I probably didn’t explain myself properly, every asset of that kind is deposited into one contract, that contract can figure out how much fees it should collect from the deposited assets based on the reported yield, and in one transaction take the appropriate cut (just need to make sure someone/something calls that function). Everyone gets their cut taken proportionally, but a solution like this could hurt lower LTVs more, as they’d be paying more than higher LTVs. But would be akin to what we have today because as soon as you deposit, you forfeit your yield.

So one transaction takes the cut from everyone.