With lending protocols like Compound V3 and its derivatives, such as Swaylend (a top lending protocol on Fuel Network), a liquidation happens when a borrower's collateral value drops below a certain threshold compared to their borrowed amount. In such cases, the user must be liquidated. Anyone can call the liquidation method; it is not limited to the governor. Liquidations are necessary to maintain a healthy market. They ensure that all debts are repaid appropriately and help prevent losses for both the protocol and its users.

With that purpose, instead of liquidating users manually, automated bots come in handy.

Steps

We roughly divide the liquidation process into three main steps:

1. Get and liquidate insolvent users

2. Buy off protocol's collateral

3. Sell collateral

The steps are explained in How to below.

Relevant contract methods

Let’s take a look at Swaylend’s and Compound’s contracts, which are written in Sway and Solidity, respectively. One runs on FuelVM, while the other operates on the traditional EVM. The most relevant methods are listed below.

1. Absorbing users

   // Sway
   fn absorb(accounts: Vec<Identity>, price_data_update: PriceDataUpdate);
   
   // Solidity
   function absorb(address absorber, address[] calldata accounts) override external;
   

   This method liquidates users passed as the accounts parameter when called.

2. Getting collateral quotes

   // Sway
   fn collateral_value_to_sell(asset_id: AssetId, collateral_amount: u64) -> u64;
   
   // Solidity
   function absorb(address absorber, address[] calldata accounts) override external;
   

   Calculates the amount of base asset to send along with the buy_collateral call to buy the desired amount of the collateral asset.

3. Buying collateral

   // Sway
   fn buy_collateral(asset_id: AssetId, min_amount: u64, recipient: Identity);
   
   // Solidity
   function buyCollateral(address asset, uint minAmount, uint baseAmount, address recipient) override external nonReentrant;
   

   Buys collateral for the amount of base asset passed along with the function and receives, at minimum, the passed min_amount.

How to

Liquidate users

1. Getting and updating configurations

First up, we need to get the latest market configurations to ensure we are working with the latest data.

marketConfig := marketContract.getMarketConfiguration()
collateralConfig := marketContract.getCollateralConfiguration()
marketBasics := marketContract.getMarketBasics()

liquidator.updateConfigs(marketConfig, collateralConfig, marketBasics)

2. Finding liquidatable users

Next, we first need to get users with negative principals and calculate the insolvent ones, ready to go underwater.

usersWithNegativePrincipal := indexer.fetchUsersWithNegativePrincipals()
insolventUsers := []

for each user in usersWithNegativePrincipal
  if isInsolvent(user)
    append user to insolventUsers

Under the hood, we can use indexers like The Graph and Envio to index the market contract and to get users with negative principals — users currently borrowing from our lending protocol. All calculations are then made offchain by using an adapted version of market contract's function is_liquidatable — be found here. Alternatively, instead of calculating users' insolvency off-chain, we can call the is_liquidatable method for each user. However, this approach is less efficient.

3. Absorbing users

The users we get from step 3 are then passed into the absorb call to liquidate underwater accounts.

marketContract.absorb(insolventUsers)

Note

The fees are not covered by the liquidator; they are paid by the protocol.

Buy collateral assets

1. Updating collateral reserves

First, we need to update the market’s collateral reserves in the liquidator's internal storage.

collaterals := marketContract.getCollateralConfigurations()

for each collateral in collaterals
  config := marketContract.getCollateralReservers(collateral.id)
  updateCollateralReserves(collateral.id, config)

2. Updating collateral values

Next, we update the actual value of the collateral reserves by iterating through the previously updated reserves, fetching the price from oracle for each asset, and storing it in liquidator’s internal storage.

collaterals := getCollateralConfigurationsFromInternalStorage()
for each collateral in collaterals
  price := oracle.getPrice(collateral.id)
  updateCollateralPrices(collateral.id, price)

3. Building and executing buy transactions

With the collateral amount and value now stored in internal storage, we can begin buying the collateral. In this step, we can set any limitations we want, such as buying only specific collateral assets or avoiding buying if the value does not exceed a specific threshold. For simplicity, we’ll leave those configurations and algorithms for building transactions to optimize your return to you.

collaterals := getCollateralsToBuy()
for each collateral in collaterals
  amountToBuy := calculateAmountToBuy(collateral)
  marketContract.buyCollateral(collateral.id, amountToBuy)

Note

An important step in building transactions is calculating the price of each collateral amount we buy from the protocol. These collaterals are sold at a discount to incentivize users to repay the debts of liquidated users in base assets. The amount of collateral to sell to a user is based on the base asset the user sent with the transaction. This amount is either fetched from the contract or calculated off-chain. For example, you can find out how Swaylend performs this calculation here.

Sell collateral assets for profit

Now that we hold the collateral value in the Liquidator’s wallet, we can decide whether to sell or hold it. We leave this decision up to you. There are many options for how to approach this step. A simple example would be to check which DEX offers the best price, as shown in the pseudocode below.

collaterals := getCollateralConfigurationsFromInternalStorage()
baseAssetId := marketConfig.baseAssetId

for each collateral in collaterals
  uniswapPrice := uniswapContract.getPrice(collateral.id)
  balancerPrice := balancerContract.getPrice(collateral.id)
  balance := wallet.getBalance(collateral.id)
  dexContract := null

  if uniswapPrice > balancerPrice
    dexContract := uniswapContract
  else
    dexContract := balancerContract

  poolId := dexContract.getPoolId(baseAssetId, collateral.id)
  deadline := now() + 10000

  dexContract.swap(
    collateral.amountToBuy,
    collateral.id,
    poolId,
    deadline
  )

Future improvements

Future improvements could focus on optimizing transaction-building efficiency and the liquidator's performance. This includes optimizing the processes for building buy and sell transactions, storing transaction history, and the liquidator's overall profit realized. Additionally, implementing parallel execution of all main steps can significantly boost the bot's performance when other market makers arrive, and checking more DEXes can help identify the best platforms for selling the acquired collateral to maximize profit.

Conclusion

A liquidator automates identifying and liquidating insolvent users, purchasing discounted collateral waiting in the protocol, and immediately selling it for profit. The bot aims to run at optimal performance and profitability by utilizing advanced transaction-building strategies.

By Lutra Labs

Website | Discord | LinkedIn | Twitter/X | GitHub | E-Mail

Written by Urban Vidovič, COO

As a blockchain developer experienced in building across multiple chains and working with various smart contract languages, I’ve been captivated by the ecosystem’s growing embrace of Rust and Rust-inspired languages. From Solana’s native Rust support to emerging languages like Sway on Fuel, Move on Sui and Aptos, and Fe on Ethereum, a clear trend is taking shape—and it’s wearing a crab badge. 🦀

This shift highlights Rust’s rising dominance in the blockchain space. Major platforms have chosen Rust for their core infrastructure, benefiting from its performance, robust memory safety guarantees, and zero-cost abstractions. The abundance of skilled Rust developers has further fueled this adoption. Rust is being used for both core infrastructure and smart contracts in new projects, and established chains are increasingly looking to add support for it to strengthen their ecosystems.

And this is where Stylus comes in—it eliminates the need for Rust-inspired approximations and allows you to build directly with Rust itself.

What is Stylus ?

Stylus is an upgrade to the Arbitrum Nitro tech stack, adding a second virtual machine that runs WebAssembly (WASM) instead of the Ethereum Virtual Machine (EVM). This allows developers to write smart contracts in languages like Rust, C, and C++, which compile to WASM. These languages are more efficient for compute-heavy tasks, resulting in faster execution and lower gas fees compared to Solidity. Developers can take advantage of existing libraries and tools from these languages to build smart contracts with greater efficiency.

Stylus is fully compatible with Solidity, meaning Solidity and WASM contracts can interact with each other. Developers can use Stylus to optimize specific parts of an application by replacing only the compute-heavy components with WASM contracts, while the rest of the application can remain in Solidity. This allows for fine-tuned performance improvements without having to rewrite entire dApps. Stylus is especially beneficial for memory and computation-intensive applications, such as complex DeFi protocols, zero-knowledge proofs and on-chain games.

Christmas Coding: Stylus × Advent of Code

To put Stylus through its paces, I decided to implement solutions to Advent of Code challenges as smart contracts. Not because the problems demand blockchain (they definitely don't 😄), but because coding challenges provide an excellent testbed for exploring a new technology's capabilities, limitations, and performance characteristics.

In case you haven’t heard of it, Advent of Code is an annual series of coding puzzles released each December. It’s a fun way to challenge yourself and improve your problem-solving skills. The code for this project is open source and available on GitHub.

Setting Up a Stylus Development Environment

Getting started with Stylus development required several tools, most of which I already had in my toolkit: the Rust toolchain, Docker, and Foundry. The only new component I needed was the Nitro devnode, which I set up using the scripts from the nitro-devnode repository.

With the environment ready, I installed cargo-stylus using cargo install cargo-stylus and created my first project with cargo stylus new <PROJECT_NAME>. This generated a project based on the Stylus hello world template, which implements Foundry's Counter example. I verified everything was working correctly by testing essential commands:

• cargo stylus check for dry-running the project, compiling to WASM, and verifying deployability

• cargo stylus export-abi for generating the contract's ABI

• cargo stylus deploy for deployment

I successfully verified the deployed contracts by calling them using Foundry cast.

Overcoming Testing and Monorepo Challenges

While the initial setup went smoothly, I encountered some interesting challenges when implementing tests and converting the project to a monorepo structure.

For testing, I utilized TucksonDev's e2e-lib, a simplified fork of OpenZeppelin's e2e library designed for testing Stylus contracts. The first issue I encountered involved the console!() macro, which wasn’t working during tests. Strangely, it worked fine when deploying contracts and interacting with them through Foundry cast, showing logs in the sequencer’s Docker container. The solution was straightforward once discovered: I needed to enable the debug feature in cargo dependencies by updating stylus-sdk = "0.6.0" to stylus-sdk = { version = "0.6.0", features = ["debug"] }.

The transition to a monorepo setup involved creating a Cargo workspace and organizing files. While this was relatively straightforward, both the cargo stylus check and cargo stylus deploy commands started throwing errors. I found inspiration in solving the issues in OpenZeppelin's Rust Contract repository, adapting their approach to create custom scripts for handling specific WASM files. Here's the resulting check-wasm.sh script:

#!/bin/bash

# Adapted code from `OpenZeppelin/rust-contracts-stylus`
# Ref: https://github.com/OpenZeppelin/rust-contracts-stylus/blob/main/scripts/check-wasm.sh

# Function for checking contract wasm binary by crate name
check_wasm () {
  local CONTRACT_CRATE_NAME=$1
  local CONTRACT_BIN_NAME="${CONTRACT_CRATE_NAME//-/_}.wasm"
  
  echo
  echo "Checking contract $CONTRACT_CRATE_NAME"
  cargo stylus check --wasm-file ./target/wasm32-unknown-unknown/release/"$CONTRACT_BIN_NAME"
}

# Retrieve all alphanumeric contract's crate names in `./contracts/solutions` directory.
get_solution_crate_names () {
  find ./contracts/solutions -maxdepth 2 -type f -name "Cargo.toml" | xargs grep 'name = ' | grep -oE '".*"' | tr -d "'\""
}

# Build all projects
cargo build --release --target wasm32-unknown-unknown

# Ceck all projects
for CRATE_NAME in $(get_solution_crate_names)
do
  check_wasm "$CRATE_NAME"
done

Crafting the Implementation

Initially, I started with a single smart contract containing all the Advent of Code solutions. However, by Day 5, the compressed size of the WASM smart contract exceeded the 24KB limit. To address this, I migrated to a more modular architecture and optimized contract size by:

• Using #![no_std] and instead importing needed data structures from external crates like alloc and hashbrown.

• Split solutions into separate files, with each file dedicated to solving its own specific puzzle

The final architecture consists of three main components:

1. An orchestrator smart contract:

   Acts as a proxy, tracking the addresses of deployed solution contracts for each day and routing calls appropriately. It also manages ownership and initialization status. Here's its storage structure:

   #[storage]
   #[entrypoint]
   pub struct Orchestrator {
       initialized: StorageBool,
       owner: StorageAddress,
       day_to_solution: StorageMap<u32, StorageAddress>,
   }
   

   The orchestrator's key function is solve, which handles solving specific Advent of Code puzzles. Users provide the day, part, and input data, and the orchestrator determines the correct contract and method to invoke.

   pub fn solve(&mut self, day: u32, part: u32, input: String) -> i64
   

2. A trait (or interface):

   Defines the external API for solution contracts.

   pub trait Solution {
       fn solvepart1(&self, input: String) -> i64;
       fn solvepart2(&self, input: String) -> i64;
   }
   

3. One smart contract per puzzle:

   Each solution contract is minimal, with no storage and two external methods:

   • solvepart_1

   • solvepart_2

   Each method corresponds to one of the two parts of an Advent of Code puzzle.

This architecture allowed for scalability and ensured that each puzzle solution remained within the size constraints. The modular approach improved maintainability, making it easier to debug and update individual solutions without affecting others. Perhaps most importantly, it enabled independent testing and deployment of specific solutions, eliminating the need to redeploy everything when making changes to a single puzzle's implementation. Solutions to all puzzles can be found here.

Other Notable Observations

Throughout the development process, I made the following noteworthy observations:

1. Large Binary Sizes: Some external crates, like regex, can significantly inflate the compiled WASM size. Adding regex pushed my contract size over 100KB, far exceeding the 24KB limit. This shows the importance of carefully choosing lightweight dependencies or creating custom implementations when needed.

2. Gas Limit Issues: Code that runs fast in native Rust can still exceed the gas limit in smart contracts. Profiling and debugging are essential to identify gas-heavy operations and optimize the most expensive parts, including not just computationally intensive tasks but also memory-intensive ones, to stay within the limits.

Findings

Using Arbitrum Stylus to solve Advent of Code challenges proved to be an excellent learning experience. While using smart contracts for solving coding puzzles might seem unconventional and overkill, it helped me explore both Stylus's capabilities and its current limitations. The project highlighted important considerations for Rust smart contract development, from managing contract sizes to optimizing for gas efficiency. As Stylus continues to mature, it offers an exciting option for developers looking to build compute-intensive applications on Arbitrum using Rust's powerful capabilities.

Links

• Repository

• Website

• Advent of Code

• Arbitrum stylus

• Arbitrum docs

By Lutra Labs

Website | Discord | LinkedIn | Twitter/X | GitHub | E-Mail

Written by Martin Domajnko, CTO

Now is the perfect time to build in Web3, with the Ethereum ecosystem maturing and expanding as a solid foundation for innovation. The introduction of MICA regulations and growing government clarity provide a more secure and predictable environment for developers. Decentralized networks for storage, computation, and AI are emerging, unlocking new possibilities. This is the ideal moment to create applications that offer unique advantages over Web2 and build solutions that wouldn’t be possible otherwise.

Who we are?

Lutra Labs is a deep-tech R&D venture studio specializing in delivering cutting-edge products to the masses. We collaborate with various partners, helping bring their visions and products to life while simultaneously developing our own innovative solutions.

Our core expertise lies in everything Web3 (we've been working in the space for 5+ years!), from infrastructure and application layers to smart contracts and system administration. However, as a team that continuously explores new technologies and endeavors, we also have expertise in machine learning, general software development, and the latest advancements in programming and computer technologies.

Portfolio

Some of the projects we've been working on:

• Masca: A decentralized identity wallet that allows you to store your digital identity and verifiable documents in an intuitive and simple way. Developed as a MetaMask snap, it integrates seamlessly with one of the most widely adopted Web3 wallets.

• endorse.fun: A reputation protocol where you can endorse and tip people and Web3 creators. Find users through their Farcaster, Lens, or ENS handles.

• Silius: Account abstraction is a key piece missing from broader Web3 adoption, enabling users to customize their blockchain accounts. Silius is an ERC-4337 bundler, a critical low-level infrastructure component in the - Ethereum account abstraction ecosystem.

• Swaylend: As developer contributors, we helped build one of the largest lending protocols in DeFi on the emerging Layer 2 — Fuel Ignition.

Team and background

We are a team of five tech enthusiasts with vast expertise in development (of all kinds — just tell us what you need), research, and product management. As a spin-off from the Blockchain Lab:UM, we have strong connections within the academic sphere, which allows us to tackle and solve the most complex and challenging problems.

Closing thoughts

That's it, folks! But only from our side... Have a project in mind? Want to brainstorm about the topics we mentioned in this blog post? Contact us, and let’s embark on the journey together!

By Lutra Labs

Website | Discord | LinkedIn | Twitter/X | GitHub | E-Mail