Midas Midas

Details

Scope

My Submission

Introduction

Midas is a platform that enables asset managers to turn institutional strategies into regulatory-compliant investment products. Unlike vaults, Midas products are regulated financial instruments offering full transparency, instant redemptions, and native composability across protocols like Morpho and Pendle.  Investment products include, amongst others, mTBILL (referencing U.S. Treasury Bills), mBASIS (referencing delta-neutral strategies), and mHyperBTC (referencing BTC-denominated yield strategies). These strategies are managed and monitored by appointed risk managers, such as BlackRock, Hyperithm and Edge Capital, with ongoing oversight of risk parameters and performance.

Docs

Disclosure Requirements

When reporting a vulnerability, follow these disclosure requirements:

  • Do not disclose the vulnerability publicly, to other researchers, or to any third party before the program owner has been notified, the issue has been fixed, and permission to disclose has been granted.
  • Report as soon as possible—ideally within 24 hours of discovery.
  • Provide a clear, actionable report including:
    • A concise description of the vulnerability and its impact.
    • Proof-of-concept (PoC) demonstrating the issue (reproducible steps and/or exploit code minimized to demonstrate impact).
    • The exact conditions under which the issue occurs (environment, preconditions, affected components).
    • Potential implications and attack scenarios if the vulnerability were to be exploited.
    • Any relevant logs, stack traces, transaction hashes (where applicable), or test scripts that reproduce the problem.
  • Limit the demonstration to the minimum necessary to prove the issue. Do not exfiltrate private data or otherwise cause harm while validating.
  • The program owner may request additional information (e.g., KYC) to validate the report before processing eligibility and rewards.

Eligibility

To be eligible for recognition under this program, researchers must meet the following criteria:

  • Be the first to report a previously unknown, non-public vulnerability that the program owner has not been made aware of.
  • If the same vulnerability is reported through multiple platforms or channels, only the submission with the earliest verifiable timestamp will be considered eligible for a reward. Subsequent or duplicate submissions will not be rewarded.
  • Provide sufficient information to reproduce and fix the issue (clear PoC, reproduction steps, or test case).
  • Not have exploited the vulnerability in a malicious manner.
  • Not have disclosed the vulnerability to third parties prior to receiving permission.
  • Comply with all program rules and applicable laws in the researcher’s jurisdiction.
  • Provide any requested identity verification (KYC) or documentation necessary for reward processing and legal compliance.
  • Not be a current or former employee, vendor, contractor, or other person who was involved in the development of the affected code.
  • Be of legal age in their jurisdiction at the time of submission and not be resident in countries under sanctions or legal restrictions that would prohibit participation.

To maximize the efficiency of the reward pool and reviews, explicitly exclude any low-risk vulnerabilities that were already identified, acknowledged, or fixed in previous external audits.

Severity

Vulnerabilities are classified in four distinct levels based on their impact and likelihood of exploitation. The severity of a vulnerability is determined by combining these two factors using the Risk Classification Matrix below:

SeverityLevelImpact: CriticalImpact: HighImpact: MediumImpact: Low
Likelihood: HighCriticalHighMediumLow
Likelihood: MediumHighHighMediumLow
Likelihood: LowMediumMediumLowInformational

1. Critical

  • Impact: Catastrophic damage to the protocol or its users.
    • Examples include severe loss of assets, permanent system disruption, or widespread compromise.
  • Likelihood: High, with minimal or no user interaction required.
    • Exploitation is very easy or highly incentivized.
  • Examples:
    • Permanent loss or freezing of assets.
    • Network-wide shutdown or inability to confirm transactions.
    • Unintended permanent chain splits requiring a hard fork.
    • Protocol insolvency or governance manipulation leading to direct financial harm.
    • Web2: Account takeover with significant impact (e.g., admin account compromise).

2. High

  • Impact: Significant damage to the protocol or its users, but not catastrophic.
    • Examples include notable financial loss or significant harm to user trust.
  • Likelihood: Medium to high, with some user interaction or specific conditions required.
    • Exploitation is possible under certain conditions.
  • Examples:
    • Temporary freezing of assets or transactions.
    • Unintended chain splits (network partitions).
    • Theft of unclaimed yield or royalties.
    • Exploits requiring elevated privileges but with high impact.
    • Web2: Account takeover with moderate impact (e.g., user account compromise).

3. Medium

  • Impact: Moderate damage, often limited to specific users or conditions.
    • Examples include limited financial damage or moderate system impact.
  • Likelihood: Medium, requiring specific conditions or user interaction.
    • Exploitation is possible but not trivial.
  • Examples:
    • Increased resource consumption or temporary disruption of network nodes.
    • Theft of gas or griefing attacks with no direct profit motive.
    • Bugs causing unintended smart contract behavior without direct financial risk.
    • Web2: Non-sensitive data disclosure, open redirects, or reflected HTML injection.

4. Low

  • Impact: Minor damage, often limited to non-critical functionality.
    • Examples include minimal direct risk or areas for improvement.
  • Likelihood: Low, requiring significant user interaction or unlikely conditions.
    • Exploitation is difficult or requires highly specific conditions.
  • Examples:
    • Shutdown of a small percentage of network nodes without network-wide impact.
    • Modification of transaction fees outside design parameters.
    • Non-critical UI/UX issues or minor information disclosure.
    • Web2: Minor UI/UX issues or non-critical functionality disruptions..

Out of Scope

The following are considered out of scope for our vulnerability classification system:

  • Weird ERC20 Tokens: Issues related to non-compliant or weird ERC20 tokens.
  • Centralization related risks
  • Admin errors: Issues based on admin errors, such as calling a function with wrong parameters and admin actions on integrated protocols
    • Note: Issues based on a wrong implementation of admin functions will have the severity defined based on the severity matrix
  • Malicious admin: Issues based on a malicious or compromised admin, unless explicitly included in the contest scope.
  • User errors: Issues based on a user error, without significant impact on other users
  • Issues related to the design philosophy of the protocol: for example, issues related to trade-offs made on permissionless protocols
  • Speculation on Future Code/Integrations: Issues based on future changes, integrations, or upgrades should not be submitted unless the finding directly relates to the current code and behavior.
  • Known Issues by the team.
  • Theoretical vulnerabilities without proof of concept.
  • Social engineering attacks or phishing.
  • Issues requiring physical access to a user's device or local network.
  • Best practice recommendations or feature requests.
  • Third-party integrations or dependencies not under our control.
  • Denial of Service (DoS) attacks without demonstrated impact.
  • Self-XSS or non-exploitable UI/UX issues.
  • Clickjacking on pages with no sensitive actions.
  • Server Information & Status Pages (e.g., stack traces, descriptive error messages).
  • SSL/TLS best practices (e.g., missing SSL Pinning, insecure configurations).
  • Optional email security features (e.g., SPF/DKIM/DMARC configurations).
  • Most issues related to rate limiting.
  • Content-Security-Policy configuration opinions.
  • Verbose error messages without proof of exploitability.
  • Attacks requiring MITM or physical access to a user's device.
  • Reports from automated tools or scans.
  • Missing HTTP Only flags on non-sensitive cookies.
  • Content spoofing, text injection.
  • Issues without clearly identified security impact.
  • Self-exploitation (e.g., self-XSS, self-DoS, cookie reuse).
  • Tabnabbing.
  • Brute forcing account credentials.
  • Known vulnerable libraries without a working Proof of Concept.
  • Open access to publicly-exposed resources (e.g., Google Sheets) without demonstration of vulnerability exploitation.

Scope

Ethereum Contract

Solana Contract

Contract configuration

  • Any misconfiguration or unsafe configuration state in deployed smart contracts (used in production) that could reasonably lead to loss of funds, protocol insolvency, unauthorized privilege escalation, or creation of exploitable attack paths.

Midas Web Interface

Reward

Ethereum contract

Severity LevelReward Range
Critical25,00025,000 - 500,000
High5,0005,000 - 25,000
MediumFlat $5,000
LowFlat $1,000

Solana contract

Severity LevelReward Range
Critical10,00010,000 - 200,000
High2,0002,000 – 10,000
MediumFlat $2,000
LowFlat $500

Contract configuration

Severity LevelReward Range
Critical2,5002,500 – 50,000
High500500 – 2,500
MediumFlat $500

Midas Web Interface

Severity LevelReward Range
Critical2,5002,500 – 50,000
High500500 – 2,500
MediumFlat $500

Reward Calculation for Critical Vulnerabilities:

For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to the maximum cap defined in the applicable reward range. The amount of funds at risk will be determined based on the time and date the bug report is submitted.

A minimum reward will be granted for critical vulnerabilities to incentivize responsible disclosure and discourage withholding of bug reports. A vulnerability must place at least $10,000 USD at direct risk to be classified as Critical.

Reward Calculation for High Severity Vulnerabilities

For high severity vulnerabilities, rewards will be capped at up to 100% of the funds directly affected, up to the maximum cap defined in the applicable reward range.

Bug bounty Cap

Under no circumstances will total rewards for a given scope exceed the applicable hard cap. If multiple valid bug reports are submitted and the cumulative rewards would exceed this limit, rewards will be allocated on a first-come, first-served basis, determined by the submission timestamp of each report, until the hard cap is reached. In all cases, the sum of total rewards paid will not exceed $1,000,000.

ScopeHard cap
Ethereum contract$1M
Solana contract$400,000
Contract configuration$100,000
Midas Web Interface$100,000
Max total payout$1M

Terms and Conditions

By submitting a report, you accept the following terms and conditions:

  • You grant the program owner the rights necessary to investigate, mitigate, and disclose the vulnerability, including the right to patch, mitigate, and publicly disclose the issue once remediated.
  • Eligibility, reward decisions, and any recognition are at the sole discretion of the program owner. Submission does not guarantee a reward or public acknowledgment.
  • The program owner may require identity verification (KYC) and other documentation before processing eligibility or rewards.
  • The program terms, scope, and conditions may be revised at any time. Researchers are responsible for reviewing the latest program rules prior to submission.
  • Reports that violate the prohibited actions above, applicable laws, or that demonstrate malicious intent will be rejected and may be referred to law enforcement.
  • The program owner is not liable for any actions taken by researchers that violate these rules or applicable laws; researchers participate at their own risk and responsibility.

Max Rewards

500,000 USDC

Status

Live since

Last updated

LIVE

Mar 21, 2026, 3:32 AM

Mar 21, 2026, 3:32 AM

Report a bug