Browse documentation
Risk and governance
Isolation narrows the blast radius of a pool. It does not make an asset, oracle, rate model, creator, governance authority, or parameter set safe by itself. Review every layer that can change a user's outcome.
Risk register
| Layer | Questions to answer | Residual boundary |
|---|---|---|
| Token and custody | Is the token canonical, non-rebasing, correctly scaled, and exact-transfer? Does the pool hold the represented balance? | Unsupported token behavior or an external upgrade can still invalidate assumptions. |
| Oracle | Which feed prices the assets? What are its staleness, phase, bounds, and owner controls? | Feed governance and data quality are external to the pool bytecode. |
| Rate model | How does utilization change the borrow rate? Are the parameters within the approved economic policy? | A technically valid model can still be economically unsuitable. |
| Parameters | What are LTV, liquidation threshold, bonus, supply cap, and borrow cap? | Parameters bound exposure but do not promise liquidity or returns. |
| Creator | Who can pause the pool or recover reserves? Is that address governed and monitored? | Creator administration is an operational authority, even when the pool is curated. |
| Factory governance | Who can approve modules, pause pools, transfer ownership, or curate a pool? | The intended production owner is a Safe; signer controls, roles, and monitoring require separate evidence. |
Permissionless and curated tiers
Any address can create a pool through PoolFactory, subject to the contract's validation rules. That permissionless tier is useful for experimentation but should not be treated as reviewed.
The curated tier is opt-in. Governance approves the token, oracle, and interest-rate model; the factory and verifier compute a configuration hash; and the pool must pass health checks before isVerifiedPool(pool) becomes true. Ownership handoffs invalidate the curation epoch and require explicit re-curation.
Governance responsibilities
- Use a governed owner. The production target is a reviewed Safe, not an EOA left as final authority. Any Safe deployment without a timelock retains immediate administrative power.
- Accept ownership deliberately. Oracle and factory handoffs are two-step operations; pending or mismatched owners keep curation unavailable.
- Re-curate after changes. Feed, module, approval, and ownership changes can invalidate the stored curation epoch.
- Monitor admin actions. Track ownership, approvals, feed revisions, phase changes, pause reasons, and reserve movements.
- Retain evidence. Keep signed proposals, execution receipts, finalized block hashes, and the release archive outside the public repository.
Token and oracle boundaries
AnyLend's accounting assumes standard ERC-20 transfer semantics. Fee-on-transfer, rebasing, mutable-decimals, and opaque upgradeable assets need an independent review; the protocol's custody ledgers deliberately fail closed when observed balances no longer support represented values.
Oracle adapters normalize price and enforce sign, round, staleness, lower-bound, upper-bound, aggregator, and phase checks. These checks protect the adapter boundary, not the truth of the underlying market or the governance of the feed provider.
A reviewer’s minimum checklist
- Pin the factory, pool, token, oracle, and rate-model addresses to the intended network.
- Read the live code hashes and compare them with the reviewed deployment evidence.
- Inspect the pool configuration and verify that the parameters fit the risk policy.
- Check owner, pending owner, creator, Safe roles, and recent admin events.
- Confirm oracle feeds are healthy and current at a finalized block.
- Run a small lifecycle on the target network before treating the integration as exercised; use Sepolia for rehearsal and regression testing.