Skip to content

ExtendedFDT

Lucas Manuel edited this page Apr 7, 2021 · 4 revisions

ExtendedFDT extends the functionality of FDT to include functionality to account for losses that must be distributed for liquidity providers and stakers.

In the context of a Pool, this happens when:

  1. A loan has defaulted
  2. All collateral has been liquidated
  3. Maximum amount of BPTs in the Pool's stakeLocker have been burned, and there is still a shortfall

In the context of a StakeLocker, this happens when:

  1. A loan has defaulted
  2. All collateral has been liquidated
  3. Any amount of BPTs have been burned

In both of these scenarios, losses must be passed on to FDT holders. This was done by creating an FDT contract that has two "fundsTokens".

In the context of a Pool:

  • Profits are captured by the interestSum storage variable.
  • Losses are captured by the poolLosses storage variable.

In the context of a StakeLocker:

  • Profits are captured by the standard fundsToken approach, using the balance of liquidityAsset in the contract
  • Losses are captured by the bptLosses storage variable.

The interestSum accounting works in the exact same way as the typical FDT outlined on this page, just using a storage variable instead of an ERC-20 balance. The reason for this is that the interest earned is not held in the Pool contract itself, but rather the LiquidityLocker. Pool accounting is covered in more detail on this page.

In order to account for losses, FDT functionality was mirrored.

  • A user's recognizable loss is defined by the following equation:

    loss = lossesPerShare * tokenBal + lossCorrection - recognizedLosses

  • Whenever a user increases their FDT balance (depositing, staking, minting etc.), the lossesCorrection of their account gets updated to:

    lossesCorrection = lossesCorrection - lossesPerShare * balanceChange

    This effectively removes their claim on all losses that was present before they entered the contract.

  • Whenever a loss occurs in the Pool, updateLossesReceived() gets called and the lossesPerShare increases according to this equation:

    lossesPerShare = lossesPerShare + newlyLostFunds / totalSupply

  • Whenever a user recognizes losses, recognizeLosses() gets called and their recognizedLosses gets updated according to this equation:

    recognizableLosses = lossesPerShare * tokenBal + lossesCorrection - recognizedLosses[msg.sender]
    recognizedLosses[msg.sender] = recognizedLosses[msg.sender] + recognizableLosses
    

The major difference between this and normal FDT functionality is that when a user is "claiming" losses, no funds are transferred, unlike in normal FDT claims. For this reason, the function recognizeLosses() (mirror of withdrawFunds()) is an internal function that can only be called on withdraw(). This function returns the amount that should be subtracted from the withdrawable balance of the user.