7.9
/ 10
1 evaluations
2.2k Downloads
Overview
Runs an autonomous liquidation keeper for Torch Market lending on Solana, scanning all migrated tokens for underwater loan positions and liquidating them through a dedicated vault so that all profits and costs are isolated in that vault.
Key Advantages
1.End-to-end liquidation flow: discovers lending markets, bulk-scans positions, and executes liquidations in a continuous loop without human intervention.
2.Strong vault safety model: authority-only withdrawals, disposable controller keypair, and clear separation between vault custody and the agent signer.
3.Low operational complexity: single process, simple env-based configuration, and a focused ~200-line TypeScript implementation with minimal dependencies.
4.Efficient scanning: uses Torch SDK bulk loan scanner (getAllLoanPositions) to minimize RPC calls and automatically prioritize liquidatable positions.
5.Clear security practices: no private key files by default, no seed phrases, and no logging of secret key material; agent keypair is ephemeral and low-value by design.
Use Cases
- Running a dedicated liquidation keeper for a Torch vault to capture the 10% liquidation bonus and protect the Torch community treasury from bad debt.
- DAO or treasury operators deploying a safe, vault-based liquidation bot to earn yield and safeguard protocol health without exposing core authority keys.
- Advanced users or market makers who want to operate independent Torch keepers as a strategy, possibly across multiple vaults or RPC endpoints.
- Protocol-aligned actors (e.g., Torch team, stakeholders) ensuring there is always at least one reliable keeper live for each Torch lending market.
- Developers and auditors using a mainnet-fork (e.g., Surfpool) to test liquidation behavior, stress RPC, or validate the safety model before deploying to mainnet.
Evaluation Scores
7.9
/ 10
Reliability
7.5
Functionality
8.3
Usability
7.8
Safety
7.7
Performance
7.9
Compatibility
8.0
Based on 1 evaluation · Latest: 3/20/2026
Download Trend
Loading...
Evaluation History (1)
7.9/103/20/2026▼
OS: win32-x64LLM: anthropic/claude-sonnet-4.6
**Judgement:** High-quality, specialized liquidation keeper for Torch Market on Solana. Well-scoped, technically sound, and clearly documented, but suitable mainly for users who understand Solana/Torch and on-chain financial risk.
**What it does well**
- Implements a complete, autonomous liquidation loop: discovers migrated Torch tokens, bulk-scans loan positions, and liquidates those with `health === 'liquidatable'` (LTV > 65%).
- Uses a **vault-centric safety model** where all SOL and collateral are held by the vault; the agent wallet is disposable and holds only fee dust.
- Minimizes dependency surface: just `@solana/web3.js` and a pinned Torch SDK, with clear, explicit versions.
- Operational flow is straightforward: set env vars, create/fund vault, link agent wallet once, then run the bot.
**Key risks / limitations**
- **Protocol & market risk:** Depends entirely on Torch Market contracts, Raydium-based pricing, and Solana L1 behavior; any bugs, oracle issues, or extreme volatility can still cause economic loss at the vault level.
- **Misconfiguration risk:** Incorrect `VAULT_CREATOR`, RPC URLs, or authority handling could lead to unintended behavior or stuck funds; requires careful setup and verification by the operator.
- **Infrastructure dependency:** Relies on a stable Solana RPC and external read-only services (CoinGecko, Irys). Failures should degrade gracefully, but outages will reduce effectiveness.
- **No strategy sophistication:** It liquidates all liquidatable positions it can reach; there’s no configurable risk/priority strategy, gas optimization across multiple keepers, or advanced MEV handling.
- **Technical barrier:** Assumes comfort with Node/TypeScript, Solana keypairs, and Torch vault concepts; not appropriate for non-technical retail users.
**Recommended scenarios**
- A Torch participant or DAO wanting a **dedicated keeper** to protect the lending treasury while capturing liquidation bonuses in a controlled vault.
- Operators running **multiple independent keepers** (possibly across different RPC endpoints or infrastructure providers) to increase liquidation coverage and resilience.
- Teams that will **test on a mainnet fork** (Surfpool) first, validate configuration and behavior, and only then deploy to mainnet with meaningful capital in the vault.
- Use in environments where the operator can continuously monitor logs, RPC health, and vault balances, and is prepared to revoke the agent wallet quickly if needed.
Comments (0)
No comments yet. Be the first!