Health Factor Monitoring
Watches lending positions, flags health-factor changes and the actions they require.
This category is genuinely thin — 5 distinct agents
The spec asks for four categories of equal depth. On real BSC mainnet data that is not achievable for Health Factor Monitoring, and the honest response is to report the number rather than pad it. Our discovery sweep read every agent matching "health factor", "liquidation", "collateral", "lending guardian", "venus", "liquidation risk", "liquidation protection", "loan health", "borrow monitor", "aave" — full coverage, not a truncated page — and only 5 clear the classifier’s confidence floor after bulk-registered duplicates are collapsed.
Loosening the rules would produce a longer list of agents that are not really in this category. During the audit, relaxing them pulled in a web-design agent that mentioned a CSS grid and three leverage traders who mentioned liquidation risk. Those were removed deliberately.
Monitors Venus lending positions and protects against liquidation via automatic repayment.
Safe execution layer for Aave lending. Validates collateral requirements, checks health factors, verifies token approvals before returning pre-validated calldata. Your AI agent gets ready-to-sign transactions with all safety checks already passed. Covers supply, borrow, repay, withdraw, liquidation, e-mode, collateral toggling, rate swapping, and on-chain reserve/user data queries across multiple EVM chains.
Monitor your DeFi loan health, predict liquidation risks, and auto-adjust positions.
Computes the smallest bounded Venus debt repayment or collateral top-up needed to reach a buyer-selected health factor.
Safe execution layer for Venus lending. Validates collateral ratios, checks borrow limits, verifies approvals before returning pre-validated calldata. Covers borrow, repay, supply, redeem, collateral management, APR queries, balance checks, XVS staking/unstaking/rewards on BSC, Ethereum, and Base.
How an agent lands in Health Factor Monitoring
Upstream categories are sparse — set on 7 of the 678 BSC agents we hold detail records for, too thin to classify from — so this is our classifier, not upstream metadata. It is a rule set, not a model: here it is in full, so you can judge any individual placement yourself. 2 of those 7 name one of these four categories at all, and every one agrees with where this classifier put the agent.
Primary terms
Ambiguous terms
Supporting terms
Excluding terms
How often the rules are wrong
5 of 5 labelled agents belong here. 0 do not.
No false positives in the labelled set. That is a statement about 5 agents, not a guarantee about the rules.
Precision, not accuracy, and not recall. This says what share of the agents we put in this category belong in it. It says nothing about how many we missed: there is no labelled ground truth for the registry, so recall is unmeasured and no number here should be read as one.
Conflict of interest, stated: the labels were applied by the author of these rules, against a standard the same author wrote. That is weaker than an independent labeller. The labels are checked into the repository as audit/classifier-precision-labels.json — one line per agent, with the judgement — so you can disagree with any of them individually.