Alex North@Alex North, 1 February 2022
Background
Filecoin storage providers need to pledge collateral in FIL when onboarding sectors. This pledge is held to require providers hold a stake in the network’s value, as well as as a buffer from which to pay penalties if other fund sources are consumed. Tokens locked as pledge collateral account for a substantial portion of the money supply. When providers earn block rewards, 75% of those rewards are also held as a kind of collateral, and vest to the provider over a period of 180 days.
Sourcing pledge collateral is an impediment to providers’ growth, both because buying it entails price risk in a volatile token, and it is a large amount relative to expected earnings and other costs. It takes nearly a year for one sector to earn enough to pledge another (plus vesting time).
Some providers would like to borrow FIL from long-term investors in order to fund the pledge for onboarding new sectors, and investors would like to earn a return on their holdings. Some ad-hoc off-chain arrangements exist, but they could be far better supported. An on-chain lending market could significantly ease the borrowing process and make far more capital available to providers. Such loans would not be collateralised by other funds, but by the provider’s vesting and future earnings.
The Filecoin VM is expected to enable user-programmable contracts by about mid-2022. At this point we hope that many financial building blocks and applications may be developed, including lending markets. This is one possible design for a loan broker that has minimal other dependencies and could be practical quickly. It could also be implemented as a built-in prior to the FVM.
Goals
- An on-chain system for token holders to fund pledge collateral for storage providers
- Non-custodial, funds are controlled by private keys and contracts
- Under-collateralised loans, providers don’t need to stake equivalent value to the loan drawn
- Over-collateralised loans are already available on Ethereum via renFIL/Aave.
- Minimal dependencies on other applications (e.g. DEXs, oracles), which will take time to mature
- No special access, can be implemented in FVM once user-programmable contracts are possible
- The simplest thing that could reasonably work well over the next year or so
Some non-goals
- Be enshrined as the lending market, locking out innovative future competition
Design ideas
Requirements and constraints
The implementation of loans must align with the reality of providers’ cash flows in the Filecoin mining system.
Some observations which lead to design constraints:
- Under-collateralised loans carry a risk of default, which means that they are not fungible
- Storage providers have distinct operations, risks, and reputations
- ∴ Lenders should therefore be able choose which provider/s they lend to
- Providers are investing capital in a business, with long-term returns
- Providers need certainty about interest rates in order to judge ability to repay
- Borrowed funds are not at-call, they are tied up in pledge
- ∴ Providers cannot tolerate variable rates because they cannot undo their investment to repay when the rates rise too high
- Before and in the early period of FVM programmability, building blocks like DEXs and oracles will be immature
- Lenders cannot rely on a liquid exchange on which to sell loan shares if they desire liquidity
- ∴ Loans must have defined terms so that the lender has a definite point at which they can withdraw their funds
In light of these constraints, a lending market modelled after Aave/Compound would be a poor fit. The domain is much closer to that of a business or investment property loan.
Lending against future earnings
An investment property mortgage or business loan is made not against the property or business assets being funded, so much as against the future income stream of the borrower. In the same way, a loan to a Filecoin storage provider should be evaluated against the provider’s future income. This includes:
- rewards already earned but vesting (0-6 months)
- projected future earnings, after they vest (6+ months)
The vesting amount is knowable on-chain, with confidence up to any penalties the provider might incur that would reduce it. The future earnings may be projected more roughly from (a) the provider’s committed storage and (b) storage expected to be committed through the investment. This latter is subject to the network’s storage growth rate, baseline function, etc.
For an initial simple system, we can avoid on-chain underwriting and merely expose all of this information in a UI to the parties involved.
Rights over a provider’s vesting and future earnings may be secured by setting a beneficiary address for the provider. This idea already exists as a draft FIP and implementation in Go contributed by IPFSForce to aid off-chain lending contracts. See the details there.
A loan broker contract can thus secure loans and repay them with a provider’s earnings.
Term loans
These constraints and other considerations suggest the following basic structure.
- A provider delegates their future earnings to a loan broker contract, which will orchestrate loans and repayments.
- The provider specifies to the broker loan request: minimum and maximum principal, fixed loan duration, and fixed interest rate.
- Many more complicated terms are possible in the future to increase capital efficiency
- Lenders deposit funds to the broker for a specific loan request. Multiple lenders may contribute to one loan on the same terms.
- If lenders deposit at least the minimum amount, the provider can draw the loan, which transfers funds from the broker to the provider’s miner actor where they can be used for pledge. This commits all parties, the loan duration begins, and interest is accrued.
- The provider cannot withdraw funds from their actor, only the beneficiary address can
- During the loan term, either the provider or a lender can trigger withdrawal from the miner actor of the appropriate principal + interest amount due to the lenders according to time elapsed since the loan was drawn.
- Borrowers can then withdraw these funds, or deposit to a new loan request
- After all loans are fully repaid, a provider can request the beneficiary address be released back to the miner actor’s owner.
Repayment schedule
A provider’s expected income is roughly flat over time, with some notable caveats:
- It may be decreasing if the network is growing faster than the provider, or increasing if the provider is growing fast
- It may be decreasing if the provider’s storage commitments are expiring faster than it’s making new ones
- It may be very uneven if the provider is small and infrequently wins the consensus lottery
The expected cash flow from a marginal sector committed with borrowed funds is similarly flat (but delayed by vesting).
The loan repayment schedule should match this flat-ish income schedule, while providing flexibility for both defaults and early repayment. Thus, we take the fixed repayment amortized principal + interest scheme common to residential mortgages. Interest is calculated continuously on the principal outstanding, but the regular repayment is calculated up front so as to repay the full principal plus accumulated interest by the end of the loan term. The miner’s outgoing cash flow to service the loan is constant.
There is no due date for a repayment. Rather, any party can trigger repayment up to the elapsed part of the loan term at any time.
Early repayment
A provider may make additional repayments to the loan principal, which will shorten the term of the loan given continued fixed repayments, and reduce the total interest accrued.
Default
A provider defaults on their loan if the miner actor’s vested and unlocked funds are insufficient to make a repayment on time.
When in default, a loan will accrue an overdue balance, being the sum of repayments due but not yet made. This overdue balance will accumulate penalty interest, compounding internally. As additional repayment amounts become due, they are added to the overdue balance. Repayments from a provider will first go to pay down the overdue balance+interest. When the overdue balance reaches zero, a provider has caught up with their repayment schedule.
If the loan term expires while in default, the overdue balance will continue to attract penalty interest. There is no fixed term for repayment.
[TODO: explore other policy options here?]
Multiple loans
A provider can request multiple loans, with different terms (amount, interest rate, duration).
One reason to do this is to aid discovery of the market-clearing interest rate a provider must offer to get their loans filled.
Another reason is to improve capital efficiency. Onboarding sectors takes time, so it would be inefficient and expensive for a provider to be required to draw and pay interest on their maximum loan amount up front. A provider can instead tranche their borrowing into sequential loans.
A third reason is to keep up with the prevailing interest rates. If rates are to drop over time (e.g. due to growing lender base and the provider’s good repayment history), a provider can enjoy a lower blended rate by spreading borrowing out over time.
When a provider has multiple loans, they will rank in seniority by their commencement date. That means that the miner’s income will first go to make repayments on the first loan, and then on the second, etc. If a miner defaults, they default first on the youngest loan.
The loan broker UI should clearly show a provider’s other requests or active loans when lenders are contributing. A single provider is unlikely to have loans with another broker because only one broker can hold the miner’s beneficiary address at a time.
Surplus earnings
A provider may earn income in excess of that necessary to service its loans, but has no direct means to withdraw it. This income may be necessary to fund the provider’s other operational costs.
The provider may request the loan broker to perform a withdrawal and transfer any amount surplus to repayment requirements to the miner actor’s owner address.
We may consider adding an additional term to loan agreements, being the amount of funds a provider must accumulate before they can withdraw excess beyond that. This accumulation would provide security to the lenders against network penalties that would take priority over vesting funds.
Transfer (optional)
A lender has rights to a loan’s present and future repayments in proportion to the amount they contributed to the loan. This right may be freely subdivided or transferred to another party. I.e., it’s an ERC-20-like fungible token (but not fungible with other loans or other providers). Standard token interfaces have yet to be defined for FVM: see this draft FIP.
A provider’s obligation to service a loan may be transferred to another provider given (a) that the broker is already the beneficiary for the trasferee, and (b) consent of the lenders (see Renegotiation, below). The obligation may not be subdivided; refinancing (see below) can achieve similar outcomes.
Refinancing (optional)
Prevailing interest rates may drop while a provider is servicing a loan, such that there are other lenders who would be willing to take over the outstanding loan at a lower rate. A provider could manually refinance their loan by issuing a new request, and then paying off the first loan with those new funds. However, this is risky for the new lenders as (a) they must rely on the provider’s intentions to use funds in this way, and (b) it would entail a period of the provider being in twice as much debt. Refinancing would be safer if funds were committed to that cause, and the commencement of the new loan was synchronous with full repayment of the old one.
We could add an additional parameter to a provider’s loan request, being the identifier of a loan to be refinanced. Drawing on that loan would repay the target loan rather than transfer funds to the miner actor for additional pledge.
Renegotiation (optional)
A provider may wish to renegotiate the terms of a loan, such as when prevailing interest rates drop or the provider experiences financial hardship. Exploration of a concrete mechanism here is deferred, but note that it’s slightly complicated by there being multiple parties to each loan. Probably we’d do something like an xx% share of lenders can drag along the rest in agreeing to a provider’s new terms.
Automation
This design omits any attempt at automating the claiming of repaid funds or reinvesting them. Such applications can be built on top of this basic loan market (as other contracts can be lenders).
Governance (optional)
If built as a user contract on the FVM, the question of governance arises.
The simplest possibility is no governance and no ability to change without a network consensus upgrade.
Slightly better would be governance by multisig, with the Filecoin foundation installing a set of governors with ability to update the code (such as to perform emergency halts or recoveries).
Better still in the long run would be to follow the decentralised governance models that have been demonstrated by various DeFi applications, and distribute governance power to the users of the broker: the lenders and borrowers. Details deferred.
Alternatives considered
- Coupon bonds: a fixed term loan that pays only interest during the term, and the full principal at the end. This repayment scheme doesn’t fit storage providers’ income flows very well, and would lead to inefficiencies where the provider needed to accumulate the principal for repayment without putting it to work. Could work better with a robust refinancing market.
- Open-ended loan: an overdraft-style facility where there is no due date for the principal to be repaid. This could leave lenders with no ability to exit unless there were a liquid market for loan credits, which would take some time to develop.
- Individual loans (vs party loans): each loan is between just one provider and lender. TODO