Healthy lending protocols are a critical component of DeFi. Today, many of the parameters that keep these protocols safe are static and reactive. Ritual let’s us create proactive systems that use AI to automatically adjust these protocol parameters based on market conditions, making on-chain lending safer and more efficient without the need for as much human intervention. In this tutorial, we will:
  1. Automate the setting of lending protocol parameters via powerful ML models
  2. Remove the need for external keepers through scheduled transactions
  3. Build a more secure lending protocol through dynamic parameterization
Assume that you have a lending protocol that contains a pool that allows for borrowers to take out loan positions of USDC against UNI. The pool defines several parameters, one of which is the threshold at which a loan position gets liquidated: we will refer to this as the liquidation threshold value. Concretely, a user account becomes unhealthy, and can be liquidated, when its Loan-To-Value (LTV), the amount they’ve borrowed against their collateral, exceeds the pool’s liquidation threshold value. Normally, the liquidation threshold value for a pool is fairly static, changing based on governance proposals that may last weeks, if not months. Now consider a machine learning model that could use CEX data for a UNI-USDC market to predict future volatility and generate an output value that can be used to modulate the liquidation threshold value for this market at any time.
1

Prepare your ML model

For this exercise, we will use a Classical ML model. One of the more common model types supported by Ritual is the versatile ONNX format, which we can export and prepare for use in our lending protocol.In the future, via Ritual’s model marketplace, we will be able to tap on models created by other on-chain users, tracking their verifiable performance and provenance.
2

Upload ML model

Mext, we can upload our model to a supported storage layer (today, Hugging Face or Arweave).Refer to our set of infernet-ml libraries for detailed upload instructions.
3

Setup a function to use our model to update LTV

We want to make it easy to call our ONNX volatility prediction model at some pre-determined frequency, with some provided input, and use the output from this model to update the market’s liquidation threshold value.For the sake of simplifying this tutorial, we will assume our smart contract already has the input we will pass to this model as state. In practice, there are many ways to provide input when calling these models, and you will often want to source it from off-chain data as well.Let’s first set up our solidity function that will call the model and apply the output to the market’s liquidation threshold value. We will utilize the RitualLib solidity library that exists to make it easier to call the ONNX inference precompile on-chain.
import "./RitualLib.sol";
...
...
mapping (MarketId => Market) markets;

function updateMarketLltv(MarketId _id) public {
    // check that our market exists
    Market market = markets[_id];
    require(market.initialized, "Market does not exist")

    // Setup the uploaded model we are planning to use (defined in prev step)
    RitualLib.ModelId memory modelId = RitualLib.ModelId({
        storageId: market.modelInputs.storageId,
        owner: market.modelInputs.owner,
        name: market.modelInputs.name,
        version: market.modelInputs.version,
        files: market.modelInputs.files
    });

    // Call ONNX precompile
    bytes memory result = RitualLib.requestOnnx(
        modelId,
        market.modelInputs.dataType,
        market.modelInputs.shape,
        market.modelInputs.values
    );
    (uint8 dtype, uint16[] memory shape, int128 newLltv) = abi.decode(output, (uint8, uint16[], int128));

    // Apply model output to market
    market.lltv = newLltv;
}
It’s important to note here that we are using the overloaded function call of requestOnnx that assumes both the input and output of the model are encoded as fixed point values with a scale of 18. These defaults are common when working with values on-chain, though the library allows you to set those values explicitly to whatever your use case requires.
4

Schedule automatic periodic updates

On most chains, rather than calling the updateMarketLltv function yourself, as the protocol, you want to decentralize this operation by incentivizing keepers. These keepers call the function and receive a reward from the market’s pool for performing this valuable service.A great feature of the Ritual chain is that it avoids this necessity and added expense by allowing you to enshrine scheduled executions on-chain through scheduled transactions. Using our handy IScheduler interface, we can first setup the Scheduler smart contract:
...
IScheduler public scheduler;
...
constructor(..., address schedulerAddress) {
    ...
    scheduler = IScheduler(schedulerAddress);
    ...
}
Then, we can setup a scheduled function that kicks off a request to our ONNX model at a fixed frequency:
function scheduleMarketLltvUpdate(
    MarketId _id,
    uint32 gasLimit,
    uint48 gasPrice,
    uint32 frequency,
    uint32 numBlocks
) public payable {
    uint256 amount = uint256(gasLimit) * uint256(gasPrice) * uint256(numBlocks / frequency);

    require(msg.value >= amount, "Insufficient funds");
    Market market = markets[_id];

    require(market.initialized, "Market does not exist")

    uint32 deadline = uint32(block.number + numBlocks);

    scheduler.schedule{value: msg.value}(
        bytes4(abi.encodeCall(this.updateMarketLltv, (_id))),
        gasLimit, // max gas limit
        gasPrice, // max gas price
        deadline, // max block number
        frequency // frequency
    );
}
Using the scheduleMarketLltvUpdate, you can initiate a request for having repeated executions running your ONNX model and updating the provided market’s liquidation threshold value.Note that the number and schedule of the repetitions is defined by the frequency and numBlocks that you pass as arguments that are ultimately provided to the Scheduler contract.
Four simple steps is all you need to begin automating lending protocol parameter updates via Classical ML inference and Scheduled Transactions!