Native BRC20-based DeFi attempts

Yala Finance features essential components like Vaults, liquidation algorithm, automatic stabilizer, and insurance provision. The Vaults module, central to the system, manages contract-required operations, including user actions such as Collateralized Debt Positions (CDPs), insurance, stablecoin, and Yala governance token savings pools. Oracles supply real-time pricing for these components. Initially, the Yala Foundation, consisting of Yala holders, coordinates rate setting, price stabilization, lending code maintenance, and market monitoring for crises. The liquidation mechanism recovers assets from non-repaying borrowers to avoid defaults, while the automatic stabilizer, linked to the stablecoin reserve, ensures the $YU price remains anchored. Together, the stabilizer, Yala Foundation, and liquidation mechanism ensure $YU's and the lending system's stability.

Fig. 2. Native BRC20-based DeFi architecture

Primary tokens

$YU is a USD-anchored inscription created by users over-collateralizing assets on BTC or through un-collateralized minting in a stablecoin savings pool. Once generated, $YU operates like any standard inscription on the BTC chain. $Yala, governing Yala Finance, is issued by the Yala Foundation or utilized to stabilize $YU when it deviates from its anchor. Users earn interest and rewards from successful liquidations. In case of stability threats from bad debt, the Automatic Stabilizer incentivizes keepers to manage $YU and $Yala exchanges to maintain balance, depositing acquired $Yala into the Reserve Pool. This mechanism also allows for keeper incentivization during surplus or deficit scenarios of $YU, supporting the system's economic stability. $Yala token holders can arbitrage to help stabilize $YU and participate in governance.

Vaults module

The Yala loan protocol adopts a component-based BRC-20 framework, which encompasses functionalities such as deploy, mint, transfer, and withdraw. Contrary to the traditional deploy process in BRC-10, here users initiate a Vaults Component to mint $YU by transferring BTC or other assets. The borrowing process necessitates overcollateralization, with the value of pledged assets exceeding the borrowed $YU's value. Successful repayment triggers consensus conditions within the component, converting the Vaults Component into a White Component for asset withdrawal. In case of liquidation, assets are auctioned, and a keeper can unlock the component by transferring a lower-value $YU, also turning it into a White Component. The highest bidding keeper receives the pledged assets.

Fig. 3. Yala lending protocol flow

Module generation

The user initiates the module based on the BRC-20-module protocol's deploy script, which opens the lending process. The "source" points to the lending script code provided by the Yala Foundation, which is deployed in the MAST format. The "init" parameter sets numerical values for parameters such as the liquidation interval, lending interest rate, conversion rate, etc.

{ 
  "p": "BRC-20-module",
  "op": "deploy",
  "name": "$YU_loan",    
  "source": "at_code_address",         
  "init": {   // set initial parameters
  }
}

MAST nodes contain string content for executable code and can link to multiple child nodes for different execution branches, with new branches added via the "addBr" method. Concatenating string content from a MAST path yields the code for a specific execution route.

Using BEVM's MAST as an example, the tree's root symbolizes the entire program, with subsequent nodes indicating subprograms. Each path represents a unique program execution branch, with the structure being Merkleized---leaf nodes are code hashes, and non-leaf nodes are child edge hashes. This allows a program's execution flow to be compactly represented with a hash string, making it possible to compress a program of length n to O(log n) and enabling complex DeFi programs like Yala Protocol's to be integrated into a BRC-20 module efficiently.

For deployment, the "init" parameter must detail the user's pledged assets and their quantities. Upon initial execution, this data is sent to the $YU mint script managed by the Yala Foundation, initiating $YU minting based on asset valuations from the mint script. The script then communicates the lending outcomes and module address to all indexers for oversight and consensus.

Withdrawal of assets

Asset withdrawal happens under two conditions: loan repayment or asset liquidation. In the first scenario, upon timely loan and interest repayment by the user, the indexer swiftly reaches consensus. The user then uses a "withdraw" script to reclaim their pledged assets.

Liquidation occurs if the user defaults on the final repayment deadline or the asset value drops significantly below the liquidation threshold. Here, Keepers monitor for liquidation triggers. Once triggered, a Keeper buys the assets at the liquidation price, uses a "transfer" script for the module, unlocks it post-indexer consensus, and then employs a "withdraw" script to secure the assets. Keepers act as system arbitrageurs, facilitating asset liquidation.