Permissionless-pool lending oracle
A oracle & external dependencies factor in the v1.7.0 rubric. Measured per protocol on a s cadence.
Methodology how we score #
**What this measures**
This factor assesses whether a lending protocol accepts spot prices from a DEX where any user can permissionlessly create new pools, without requiring a TWAP window, liquidity floor, or token-age minimum on the venue side. The failure mode is at the *oracle-acceptance layer* — the lending protocol may use a respected oracle source (Chainlink-tier or Uniswap v3 TWAP) for blue-chip assets, but if its acceptance logic also consumes spot prices from a permissionless venue without filters, attacker-created fake pools can be borrowed against as collateral.
**Why it matters**
This is structurally distinct from the better-known oracle-manipulation pattern (RD-F-053) where an attacker manipulates an existing pool via flash-loan to corrupt a spot price. With permissionless-pool acceptance, the attacker does not need to manipulate any real pool — they create their own pools, seed them with worthless tokens, and the lending protocol accepts those spot prices because its acceptance logic has no liquidity floor or venue allowlist. The exploit is *outside* the borrowing protocol's blast radius: nothing fails on-chain at the source, the lending protocol simply trusts a venue it should not trust.
**Green / Yellow / Red**
Green: oracle acceptance logic requires liquidity floor ≥$1M AND token age ≥7 days AND a TWAP window (not raw spot). Yellow: partial filters — one or two of the three controls present, but not all. Red: protocol accepts spot prices from any permissionlessly-created pool with no liquidity, age, or TWAP filter. Gray: source contract unverified on the chain explorer.
**Common gray cases**
Acceptance filters live in off-chain configuration that the contract reads at oracle-set time, requiring multi-step verification beyond static source inspection.
**Notable historical examples**
No cross-hacked incidents currently linked in database for this factor. The reference incident is **Rhea Finance** on NEAR (Apr 2026, $18.4M loss), where 8 fake pools were seeded via a 423-wallet fan-out, the lending protocol's oracle accepted the spot prices from those pools without venue filters, and the attacker borrowed against the synthetic collateral until liquidity drained.
Measurement what to look for #
Determine whether the lending protocol accepts spot prices from a DEX where any user can permissionlessly create new pools, without requiring a TWAP window, liquidity floor, or token-age minimum on the venue side.