Mint Contract
Lending, collateralizations, and borrowing take place through the Mint contract. Users can deposit assets and collateralize them in the same transaction.
Request
1
{
2
userPublicKey: string,
3
timestamp: number,
4
type: ProtocolEventTypes,
5
targetPool: string,
6
collateralizations: BalanceLine[]
7
deposit?: BalanceLine,
8
borrow?: BalanceLine,
9
}
Copied!
Fields:
  • targetPool: Id of the pool associated with the assets being repaid.
  • collateralizations: Array of BalanceLine's representing the pool tokens and the amount of the pool tokens the user would like to collateralize. If the user does not wish to add additional collateral they can submit an empty array.
  • Deposit (Optional): BalanceLine representing the asset and amount of the asset the user would like to deposit into the lending pool. Expects an underlying assetId.
  • Borrow (Optional): BalanceLine representing the asset and the amount of the asset the user would like to borrow. Expects an underlying assetId.
    • Note: If the user attempts to borrow an amount that would put their health factor below 1.1, their request is rejected.

High-Level Contract Process Flow (MAY BE OUT OF DATE)

  1. 1.
    User enters the contract through an event handler which transforms their request.
  2. 2.
    Contract prerequisite data from horizon.
    1. 1.
      Pool Account Data
    2. 2.
      User Account Data
    3. 3.
      User Position Data
  3. 3.
    Contract builds a transaction builder object.
    1. 1.
      This is the object operations will be added to throughout the rest of the contract process flow.
  4. 4.
    If the user is depositing the contract handles deposits.
    1. 1.
      The contract adds a payment operation to the transaction builder where the user pays the pool their deposit and a payment operation where the pool pays the user pool tokens.
      1. 1.
        If the user is missing a poolToken trustline the contract first adds a changeTrust operation where the user creates one.
  5. 5.
    If the user is collateralizing the contract handles collateralizations
    1. 1.
      Contract checks if the user currently has collateral balances of the assets they are attempting to collateralize. If they do the contract adds claimClaimableBalance operations where the pool claims the balances so they can be consolidated with the new collateralizations.
      1. 1.
        The contract will also calculate any unclaimed YBX the user has accrued to these positions.
    2. 2.
      Contract adds createClaimableBalance operations where the user creates collateral deposit claimable balances.
  6. 6.
    If the user is borrowing the contract handles the borrow.
    1. 1.
      Contract adds a payment operation where the pool pays the user the borrowed asset.
    2. 2.
      If the user already has a liability balance associated with the asset the user is borrowing the contract adds a claimClaimableBalance operation where the pool claims the liability balance so it can be consolidated with the additional borrowed assets.
      1. 1.
        The contract will also record all interest accrued by this liability balance and add it to the user's total liability for the asset.
      2. 2.
        The contract will also calculate any unclaimed YBX the user has accrued to this position.
    3. 3.
      Contract adds a createClaimableBalance operation where the pool creates liability claimable balance to record the users total liabilty for the borrowed asset.
      1. 1.
        The user sponsors this claimable balance.
  7. 7.
    Contract checks the users new health factor. If it is below 1.1 the contract throws a rejection.
  8. 8.
    If the user has any unclaimed YBX associated with the refreshed balances the contract adds a payment operation where the distribution account sends the total unclaimed YBX to the user.
  9. 9.
    The contract performs all necessary utilization delta payments and corrections. See Average Utilization Ratios section.
  10. 10.
    Turret builds transaction builder into an XDR and returns it along with a signature.

Diagram

Diagram may be out of date
Lender A: Lends 50,000 XLM to the pool and receives 50,000 y00XLM in exchange. Lender A can burn these tokens later when the pool has accumulated fees and receive their proportion of the pool back.
Borrower B: Deposits 30,000 XLM to the pool and collateralizes the received pool tokens to take out a 10,800 USDC loan. Also, deposits pool tokens from a previous uncollateralized deposit as collateral for a 1,800 XLM loan.