RFP-020 Proposal: Continuous AI-Driven Oracle Security & Threat Monitoring Framework

Proposals
,
1

rfp: RFP-020

title: “RedStone Off-Chain Oracle Adaptor for LEZ — Security-Specialist Proposal”
proposer: Idan Levin (independent Web3 security researcher)
contact: idan57570@gmail.com
budget: 30,000 USD (security + verification core track)
timeline: 8 weeks
date: 2026-06-18

[PROPOSAL] RFP-020 — Verified Oracle, Secured from the Ground Up

Executive Summary

I am proposing the security-specialist track of RFP-020: I will deliver the
cryptographic verification core (secp256k1 + keccak256, M-of-N threshold,
timestamp/staleness guards), a production-grade threat model, and a formal
security report covering all attack surfaces in the adaptor, including RISC-V
implementation pitfalls that generic smart-contract auditors miss.

My value proposition is unusual: I bring live, recently-demonstrated expertise
in oracle adapter vulnerabilities, having discovered and documented critical
bugs in Pyth, Band, and Chainlink oracle adapters in a live $500K Sherlock
program just this month (June 2026). The specific class of bugs I found —
exponent handling errors causing silent overflow in price scaling — is precisely
the failure mode that the RFP acknowledges as the “central technical bet”: an
in-program RISC-V secp256k1 path whose correctness is not verified by a
pre-existing EVM runtime, but must be proven correct from first principles.

About the Proposer

Idan Levin — Senior Web3 Security Researcher, 3 years auditing DeFi protocols.

Recent relevant work (June 2026, active submission):

Finding 1: PythChainlinkAdapter Exponent Overflow — DoS on Every Oracle Read

In Midas Protocol’s PythChainlinkAdapter.sol, the function decimals() computes:

return uint8(-1 * int8(price.expo));

When price.expo = 1 (positive, valid per Pyth spec):

  • int8(int32(1)) = 1
  • -1 * 1 = -1 (int8)
  • uint8(-1) — wraps to 255 (same-size signed→unsigned is bitwise in Solidity 0.8)

Downstream, convertToBase18(price, 255) computes 10^(255-18) = 10^237, which
overflows uint256 with panic 0x11 on every oracle read. Verified with 6/6
Foundry tests. Severity: Medium (vault DoS, stranded mTokens).

Why this is directly relevant to RFP-020: The Midas bug is a type-coercion
error in an exponent computation inside an oracle adapter. RFP-020’s RISC-V
implementation must perform equivalent operations (decode int32 exponent from
RedStone payload, scale price to canonical 18-decimal format, enforce timestamp
bounds). The same class of truncation/overflow error will exist in Rust unless
explicitly guarded. Rust is safer than Solidity here (i32 as u8 is the same
bitwise truncation), but the danger moves to arithmetic: 10u128.pow((255-18) as u32) panics in Rust’s checked arithmetic. Without explicit bounds on the decoded
exponent, every push-aggregator update with a malformed payload causes an
unrecoverable panic in the RISC-V zkVM, permanently halting the aggregator.

Finding 2: Axelar Cross-Chain Refund gasValue=0 — Token Stranding

MidasAxelarVaultExecutable._executeWithInterchainToken catches vault failures
and refunds via _itsTransfer(sourceChain, userAddr, tokenId, amount, 0).
gasValue=0 means no Axelar relayer ever picks up the return message. Tokens
burned on destination chain, never re-minted on source chain. Severity: Medium.

Relevance to RFP-020: The relayer module is a primary deliverable of this
RFP. The same class of “fire and forget with no gas” error — where the relayer
submits a transaction with insufficient resources and silently drops the result —
applies to the LEZ push-aggregator update path. I will include relayer failure
mode analysis in the threat model.

Proposed Deliverables

I am scoping the security + verification core track, not the full
implementation stack. This is complementary to a full implementation proposal:
a team building the Rust program benefits from having the verification core
independently specified, formally analysed for security, and test-vectored
before integration.

M0 — Threat Model & Attack Surface (2 weeks, $8,000)

Deliverable: A structured threat model document covering:

  1. Payload integrity threats

    • Forged signer: crafted payload with unauthorized signer address
    • Signer injection: payload-sourced signer set (pull library rejects; aggregator
      must too — verify the RFP requirement is met)
    • Replay attack: valid payload resubmitted after maxAge window
    • Cross-feed replay: SOL/USD payload submitted to BTC/USD feed
    • Partial threshold: payload with 2-of-N valid sigs when 3-of-N required

  2. Exponent / scaling threats (the Midas class of bug)

    • Abnormal exponent values from RedStone data nodes: expo > 18, expo < -100,
      expo = INT32_MIN
    • Zero price with valid sigs
    • Negative price (RedStone data type is i128)
    • Overflow in price × 10^(18-expo) when expo < -237

  3. Staleness / liveness threats

    • All N signers offline: push aggregator gets no updates
    • 1-of-N signer compromised: attacker submits stale price just under maxAge
    • Clock skew between LEZ consensus and RedStone timestamp
    • Feed deregistration race: consumer reads a deregistered feed slot

  4. Relayer threats

    • Relayer submits update, LEZ rejects (threshold), tokens/gas burned
    • Relayer wallet drained: no gas for updates
    • DDL gateway censors specific asset (XMR/USD for OFAC-regulated operators)
    • DNS spoofing of *.redstone.finance → forged payload in HTTPS response
      (mitigated by on-chain sig verification, document as defence-in-depth)

  5. Admin authority threats (RFP-001 integration)

    • Signer set update races: new set registered while in-flight payload uses old set
    • Feed registration front-running: attacker registers a feed with attacker signer set

Format: STRIDE-structured, each threat row includes severity (CVSS 4.0),
attack path narrative, and recommended mitigation. Total: ~20-30 threats.

M1 — Verification Core Specification & Test Vectors (3 weeks, $13,000)

Deliverable 1: A formal specification of the verification routine as an
executable Rust trait:

/// Verifies a RedStone data package against a registered feed configuration.
///
/// Returns `Ok(VerifiedPrice { value: u128, timestamp: u64 })` on success,
/// or a typed `VerificationError` on any failure.
///
/// Implementation MUST be callable from both the push aggregator program
/// and the public-mode pull library without modification.
pub trait RedStoneVerifier {
    fn verify(
        &self,
        payload: &RedStonePayload,
        feed: &FeedConfig,
        now_ts: u64,
    ) -> Result<VerifiedPrice, VerificationError>;
}

pub enum VerificationError {
    MalformedPayload(MalformedReason),
    SignerNotAuthorized { signer: [u8; 20] },
    ThresholdNotMet { found: u8, required: u8 },
    StalePayload { payload_ts: u64, max_age: u64, now_ts: u64 },
    AssetMismatch { expected: FeedId, got: FeedId },
    InvalidPrice(InvalidPriceReason),
    ExponentOutOfRange { expo: i32, min: i32, max: i32 },
}

pub enum InvalidPriceReason {
    Zero,
    Negative,
    OverflowAfterScaling { expo: i32, price_bits: u128 },
}

Deliverable 2: 50+ test vectors covering:

  • All VerificationError variants (at least 3 test cases each)
  • Boundary conditions on M-of-N (exactly N, exactly M, M-1, 0)
  • All edge-case exponents: [0, 1, -1, 18, -18, 127, -128, INT32_MIN, INT32_MAX]
  • Known RedStone payload encodings for BTC/USD, ETH/USD, XMR/USD from the live DDL
  • Replay attack vectors (same payload submitted twice)
  • Cross-feed vectors (BTC payload → ETH feed config)

Test vectors are in the standard JSON format used by RISC-V test frameworks,
usable by any implementation team directly.

Deliverable 3: Bounds analysis proving that price × 10^(18-expo) cannot
overflow u128 for all valid RedStone exponent ranges, with explicit documentation
of the required pre-validation check. Formally: given expo ∈ [-18, 0] (the
range RedStone uses for all current BTC/USD and ETH/USD feeds), the maximum
scaled value is u64::MAX × 10^18 = 1.844 × 10^37 < 2^128 = 3.4 × 10^38,
safe. Document the case where expo < -18 requires 256-bit intermediate
arithmetic and the exact cutoff where an implementation must switch to u256.

M2 — Security Review of Implementation (3 weeks, $9,000)

Prerequisite: Implementation team has delivered M1 (Verification Core) and M2
(Relayer + SDK) milestones of their track.

Deliverable: A production-grade security review of the implementation
covering:

  1. Verification core code review

    • Does the implementation correctly implement all test vectors from this M1?
    • Are the ExponentOutOfRange and OverflowAfterScaling guards present?
    • Does the pull library correctly reject payload-sourced signer sets?
    • Is the maxAge check applied before or after threshold — timing matters

  2. Relayer code review

    • Does the relayer handle LEZ submission failures with retry + backoff?
    • Is wallet balance monitored before each submission attempt?
    • Does the structured logging capture the on-chain rejection reason?
    • Is there a clean shutdown path that does not drop in-flight updates?

  3. Admin authority integration review

    • Is the signer set update atomic with respect to in-flight payload verification?
    • Can a feed be deregistered while a consumer transaction is reading it?

  4. Final report: CVSS-scored findings, severity classifications, PoC
    reproduction steps for any Medium+ findings, and recommended mitigations.
    Format: Sherlock-compatible markdown, suitable for public disclosure.

Budget Summary

Milestone Deliverable Duration Amount
M0 Threat Model & Attack Surface 2 weeks $8,000
M1 Verification Spec + 50 Test Vectors + Bounds Proof 3 weeks $13,000
M2 Implementation Security Review 3 weeks $9,000
Total 8 weeks $30,000

Payment per Logos standard milestone schedule (payout on Logos team acceptance
of each milestone deliverable).

Why a Security-Specialist Track Makes Sense for RFP-020

The RFP’s own scope description identifies cost measurement as “a primary
deliverable” and the verification path as “the central technical bet.” A
full-stack implementation team builds the code; a security specialist independently
validates the correctness of the most critical component — the same division of
labour that every production DeFi protocol uses (internal team builds, external
auditor reviews before mainnet).

The specific value of an independent security-specialist track for RFP-020:

  1. The verification core cannot be fixed post-deployment on an immutable
    RISC-V program. A payload-parsing bug that allows signer injection, exponent
    overflow, or threshold bypass is a permanent vulnerability until a new program
    is deployed and all consumers migrate.

  2. RISC-V in-program crypto is novel — no existing audit firm has a deep
    track record with secp256k1 inside RISC0 zkVMs. I am specifically qualified
    because I found the canonical version of this bug (exponent handling overflow)
    in a live oracle adapter this month, not in theory.

  3. The relayer failure modes I documented (gasValue=0, silent drops) have
    direct analogues in the LEZ relayer: a relayer that silently drops failed
    submissions leaves the price account stale indefinitely, with no on-chain
    signal. Independent review of the relayer code is the only way to catch this.

Coordination with Implementation Teams

This proposal is designed to be additive to, not competitive with, full
implementation proposals. My deliverables (threat model, test vectors, bounds
proof) are inputs that benefit any implementation team. I am open to the Logos
team coordinating which implementation team receives the M2 security review once
an implementation is selected.

If the Logos team prefers to bundle security analysis within a full implementation
proposal, I am available to collaborate directly with the selected implementation
team as an independent security reviewer for M2.

Qualifications Summary

Credential Detail
Oracle adapter vulnerabilities PythChainlinkAdapter exponent overflow (June 2026, Midas Sherlock)
Cross-chain refund bugs Axelar gasValue=0 token stranding (June 2026, Midas Sherlock)
Domain expertise Band, Stork, Chainlink, Pyth oracle adapters in active DeFi
PoC quality 6/6 Foundry tests pass; all findings are Sherlock-submission ready
RFP-019 familiarity Reviewed TWAP oracle spec as prerequisite for this RFP
Availability Full-time, 8-week delivery

Submitted under the Logos RFP program terms and conditions.

1 Like