The execution layer is now public
OpenLend soft liquidation is designed around external execution. When a position's oracle price and internal cursor diverge enough, a solver can move the band by calling the pool and settling the trade against market liquidity.
That solver surface is now easier to access. The OpenLend solver bot is public, so operators can inspect the code, configure the supported Arbitrum markets, run dry checks, and compete to execute valid soft-liquidation or de-liquidation fills.
What a solver actually does
A solver watches each market for an executable gap. In a soft-liquidation fill, it helps convert collateral exposure into debt-token exposure. In a de-liquidation fill, it can move the position back when price recovers and the reverse trade is valid.
The work is economic, not ceremonial. Solvers are paid through protocol-defined discounts and premiums that can make execution profitable after gas, swap costs, and inventory risk. If a fill is not attractive, a profit-only solver can skip it.
- Soft liquidation path: execute valid `fill` opportunities.
- De-liquidation path: execute valid `fillUp` opportunities.
- Optional hard liquidation path: call `liquidate` only when explicitly enabled and funded.
- Profit-only mode: skip simulated fills that do not produce positive flash profit.
Why public solvers matter
Open execution makes the mechanism more robust. A system that depends on one internal process has an operational bottleneck. A system that exposes the same execution path to many operators can attract independent searchers, market makers, and technically capable users.
That does not make execution instant. Gas, liquidity, and profitability still matter. But it means the opportunity is visible and callable by anyone who can meet the operational requirements.
The recommended path is flash mode
The public bot supports direct mode, but the recommended live path is flash mode. In flash mode, the operator does not need to pre-fund large token balances for every market. The flash executor handles settlement around the fill, while the bot checks whether the opportunity is worth taking.
Each operator deploys their own `SoftbandsFlashSolver`. That contract is owner-gated, so it should be controlled by the solver wallet running the bot. Reusing another operator's executor is not the intended setup.
- Clone the public solver bot repository.
- Configure an Arbitrum RPC URL and a dedicated solver wallet.
- Deploy a personal flash solver contract.
- Run the dry command after every configuration change.
- Start live mode only after dry checks pass.
Markets covered by the bot
The public repository includes the current Arbitrum Softbands markets: Aave long markets, Aave reverse markets, and Morpho long markets. Operators can choose which markets to run through the `SOLVER_MARKETS` environment variable.
This matters because the economics differ by asset, liquidity venue, and current band state. A solver can start narrow, observe dry-run output, and expand market coverage when it understands the execution profile.
- Aave WBTC/USDT and WETH/USDT.
- Aave reverse USDT/WBTC and USDT/WETH.
- Morpho WBTC/USDT and WETH/USDT.
Operational safety
Running a solver is real market infrastructure. The wallet can send transactions, pay gas, deploy contracts, and, if configured incorrectly, take actions the operator did not intend. Treat it like production software, not like a browser script.
Use a dedicated wallet with limited funds. Never commit `.env` or private keys. Keep hard liquidation disabled unless the wallet is intentionally funded with the relevant debt tokens and the operator understands that path.
Where to start
The public solver bot repository includes install instructions, environment variables, flash solver deployment, dry-run flow, live mode, direct mode, Telegram notifications, and safety notes.
If you want to participate in OpenLend's execution layer, start by reading the repository, deploying your own flash solver, and running dry checks against the markets you intend to cover.
Inspect the code, configure an Arbitrum RPC, deploy your own flash solver, and start with dry-run validation before going live.