Skip to content
Quantix Security Labs

Veyra Finance research programme.

Pooled lending on Base with permit-based deposits and flash loans. The programme includes the transaction-building API used by the web application.
OpenOpened 20 September 2026

Programme overview

Protocol category
Lending
Ecosystems in scope
Base
In-scope components
5 (4 contracts, 1 other)
Languages
Solidity

Focus areas

Where research is most wanted.

  • 01

    Flash-loan interactions

  • 02

    Permit signature handling

  • 03

    Oracle and sequencer checks

  • 04

    Transaction-building API integrity

Scope

In scope.

Identifiers belong to the programme’s research deployment. Test only on a local fork or the programme’s test environment.
ComponentTypeIdentifierNotes
LendingPoolBaseSmart contracts0x64cbe6014f0b69614c56d6c9624e0e0bbea2e1d4Deposits, borrows, repayments and flash loans
vTokenBaseSmart contracts0x216a68878d10880deb793ea3e821ad4140dfa3daInterest-bearing deposit receipts
PriceOracleBaseSmart contracts0xe4ea1a41be679e3cb79cd21bdf5b505cfb37e38dAggregated price feeds with sequencer-uptime check
LiquidatorBaseSmart contracts0x93080013ceda0fa14013eab21068f800ac76e697Liquidation auctions for unhealthy positions
Transaction APIWeb / APIapi.veyra-finance.exampleBuilds unsigned transactions for the web app (test deployment)

Out of scope

  • Third-party wallets
  • Marketing site and analytics
  • Issues already reported in the research assessment
  • Findings that require compromised keys or privileged access the attacker could not obtain

Severity

How findings in this programme are rated.

Examples specific to Veyra Finance. The full criteria are in the severity guidelines.
  • Critical
    • Draining pool liquidity through flash loans
    • Executing deposits with replayed permits
  • High
    • Borrowing against manipulated prices
    • API returning attacker-controlled calldata
  • Medium
    • Liquidations that leave bad debt under realistic conditions
  • Low
    • Rate limits missing on read-only API endpoints

Rules of engagement

Research within these rules.

  1. 01Test only against a local fork or the programme’s test deployment. Never interact with production systems or other users’ funds.
  2. 02Do not run denial-of-service, spam or social-engineering tests, and do not access data that is not yours.
  3. 03Report privately through the submission form. Keep details confidential until a disclosure date is agreed.
  4. 04One finding per submission, with a reproducible proof of concept where code is involved.
  5. 05Issues already listed in the protocol’s research assessment as acknowledged or open are not eligible for recognition.

These rules, together with the disclosure policy, define what the programme authorises. Testing outside them is not authorised.

Recognition

Validated findings receive recognition. This programme offers no monetary reward.

  • Acknowledgement in the report

    Validated findings are credited in the protocol’s research assessment or advisory, by name or handle, with your consent.

  • Recognition ledger

    Each validated finding becomes a ledger entry recording programme, vulnerability class, severity and validation date. Entries are published only with the researcher’s consent.

  • Researcher standing

    Standing reflects validated findings over time: Contributor after the first, Recognised after three, Distinguished after a validated critical or high finding with a published write-up.

  • Research collaboration

    Researchers with standing are invited to closed challenge rounds and to co-author research on the vulnerability classes they reported.

Report a finding in this programme.

One finding per submission, with steps to reproduce. Keep details private until a disclosure date is agreed.