Ending recursive borrowing

Ideas
1

Recursive borrowing introduction

Recursive borrowing is where, usually a DApp will supply ABC, borrow almost 100% of the available borrow limit, also with ABC. Then supply the borrowed ABC back into Compound. This can be repeated at least 2 times. What happens is all that is supplied to the protocol cannot be used by anyone else to borrow. A user could supply $10k and after recursive borrowing, end up receiving COMP rewards for $25k worth of supplies AND $18k worth of borrows with very little risk if setup and managed properly.

My idea is to end recursive borrowing once and for all, while distributing the excess COMP to DApps/users who are using Compound how it is meant to be used. Lots of the protocols interacting with Compound are designed to leverage exposure of a specific asset on Compound, some everyday users of the protocol are guilty of this as well. All of the protocols farming COMP, from what I have found, regularly harvest the COMP rewards and trade COMP into the asset that is being used to farm.

Keep it Simple!

I like simple. So, the most simple method for not allowing recursive borrowing of the same asset would be to not allow same-asset supply-borrow. Since this option is probably not feasible without a substantial overhaul to Compound’s currently active smart contracts, I have come up with the next possible solution.

Solution to end recursive borrowing, example:

If a user/DApp were to supply ABC, then a borrow of ABC will reduce their COMP rewards on the supply side by the borrow amount. If the entire borrowed amount is then used to add more supply then the address/contract will receive zero COMP rewards for their borrow side.

Basically, within each asset, COMP rewards will be based on the ‘net’ borrow and ‘net’ supply for users/contracts interacting with Compound.

Why end recursive borrowing?

Recursive borrowing is rewarding professional farmers 4 - 5 times more COMP than the protocols and users using Compound for how it is meant to function. Ending recursive borrowing in this manner will allow more COMP rewards to be distributed throughout the protocol, rewarding the users and DApps that deserve to be rewarded.

CONS

  • This will most-likely reduce the TVL within Compound by a significant amount.
  • Protocols/DApps/users who are using recursive borrowing will be upset.

PROS

  • Compound’s TVL will reflect the most accurate TVL value than any other DeFi protocol.
  • Interest rates should become more aligned with actual utilization.
  • COMP rewards (%) should increase across the board, especially on the borrow side, which may grab more attention from users and also drive up usage on other DApps/protocols that interact with Compound.

Please add to this idea. Feedback of any kind is more than welcome.
Thank you

2 Likes
2

Things to consider:

A lot of recursive borrowing that I’ve seen is putting in one asset, borrowing a stable coin, buying the initial asset again, and then looping. Blocking lends and borrows of the same asset would not stop this.

A user can also just use a separate ETH account for each borrow loop.

1 Like
3

Yes, there are workarounds to @CryptoCraig 's suggestion, but they do add friction to the process of milking the protocol for COMP.

  • Pro: In principle, adding friction to behaviors that the community wants to discourage could be a good thing
  • Cons:
    – This friction is paid mostly in ether (gas), which makes Compound-related activity take up more bandwidth on-chain than it needs to. Unnecessarily clogging mainnet feels like bad optics especially as many of Compound’s peers are actively spinning up L2 solutions and starting to build liquidity there.
    – Passes the baton to individual protocols/DAOs integrating with Compound about whether they want to accept lower returns or collectively modify their vaults/tools to work around the changes. Seems not ideal for morale or for Compound’s stature with integrating protocols.
    – The friction/cost of work-arounds to this solution scales sublinearly with the amount of capital involved. That makes this kind of friction regressive: large/institutional users and DAOs can (and presumably would) engage in workarounds at small cost relative to capital deployed, but it won’t be worth the cost/effort for smaller users to do so.
5 Likes
4

Are you sure that you can prevent recursive borrowing at all? It seems the borrower can just use multiple accounts and - if necessary - even delink those accounts by going through an exchange in the middle.

To me, the real reason we see recursive borrowing (which I agree hurts Compound) is a bad incentive scheme. So I would rather pay COMP rewards to either only borrowers or lenders but not both to fix the problem.

6 Likes
5

Maybe on the supply side we could implement that any borrowed asset reduces the COMP reward to the net supply. All borrows could stay with the same distribution.

Just a thought.

1 Like