defirisk.co
rubric v1.7.0

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.

Data & output #

Data source
Source inspection of oracle acceptance logic + venue-listing configuration on Etherscan-verified source; check if protocol uses Uniswap v2/v3 factory without pool filters
Output format
Green / Yellow / Red
Evidence artifact
Oracle acceptance logic source excerpt + venue factory address + liquidity/age filter presence
Confidence signal
green = oracle acceptance requires liquidity floor ≥$1M AND token age ≥7 days AND TWAP; yellow = partial filters (one or two of the three); red = accepts any permissionlessly-created pool spot price with no filters; gray = source unverified

Scored protocols 0 carry this factor#

No protocols have been scored for this factor yet.

Linked hacks no historical incidents linked#

No historical incidents are linked to this factor.
rubric_version v1.7.0factor RD-F-181category 3carried 0critical no