Tenor Labs Bug Bounty Program

Tenor is a suite of non-custodial smart contracts built on top of Morpho Midnight. It extends the base protocol with migration callbacks that enable renewals between Morpho Blue and Midnight, and between vaults and Midnight, along with a custom ratifier that leverages these callbacks to auto-roll positions at maturity. Tenor also provides Midnight and vault gates, a custom Midnight router contract, and a set of adapters and periphery contracts.

Severity and Rewards

Vulnerabilities are classified using two factors: Impact and Conditions. The combination of these factors determines the severity and guides the reward amount.

Severity Levels

Vulnerabilities will be classified according to the following severity levels:

• Critical
  • Direct theft of any user funds (or assets), whether at-rest or in-motion, other than yield or rewards, without limitations of external conditions. The loss must exceed 20% of the protocol's TVL.
  • Permanent freezing of user funds
  • Protocol insolvency due to accounting errors
• High
  • Direct theft of user funds, including yield and rewards, with moderate conditions. The loss must exceed 5% of the protocol's TVL
  • Temporary freezing of user funds (>7 days)
  • Permanent freezing of unclaimed yield

Impact Assessment

The severity level of a vulnerability will be determined based on both its impact and conditions:

• Impact Factors
  • Amount of funds at risk
  • Number of users affected
  • Duration of the vulnerability's effect
  • Complexity of exploitation
  • Requirement for privileged access
• Conditional Factors
  • Technical complexity of the exploit
  • Required preconditions for exploitation
  • Opportunity window for exploitation

Reward Structure

Reward Amounts

Rewards will be paid in USDC according to the following structure:

Severity Level	Reward Range
Critical	20,000 USD - 200,000 USD
High	5,000 USD - 10,000 USD

• Reward Calculation for Critical Vulnerabilities
  • For critical vulnerabilities, the reward amount will be calculated as 10% of the funds directly affected, up to a maximum of 200,000 USD. The calculation of the amount of funds at risk will be based on the time and date the bug report is submitted.
  • A minimum reward of 20,000 USD will be awarded for critical vulnerabilities to incentivize security researchers against withholding bug reports.
• Reward Calculation for High Severity Vulnerabilities
  • For high-severity vulnerabilities, rewards will be capped at up to 100% of the funds affected, with a maximum of 10,000 USD.
  • A minimum reward of 5,000 USD will be awarded for high-severity vulnerabilities to incentivize security researchers against withholding bug reports.

General Notes

• Sherlock's Criteria for Issue Validity guide can be a helpful resource for more context on out-of-scope issues, etc. but nothing in the guide should overrule the definitions above
• A coded Proof of Concept (POC) with instructions to run the POC is required
• If the protocol team has the ability to take measures (upgrade the contract, pause the contract, etc.) against an exploit, the potential damage is limited to a 1-hour exploit period before it is assumed that the protocol team takes measures to prevent further damage

Platform Rules

Please review the Sherlock Bug Bounty Platform Rules before submitting any vulnerability.

Out of scope

• External oracles are assumed to operate correctly, remain available, and not deviate from expected behaviour. Incorrect data or pricing information supplied by third-party oracles is out of scope.
• Vulnerabilities that have already been reported or are known to the protocol team
• Issues that have been identified in previous audits and are pending fixes
• Vulnerabilities in the blockchain itself
• Issues in third-party libraries or dependencies not developed by the protocol team
• Theoretical vulnerabilities without a working proof of concept
• Issues requiring privileged access (e.g., governance or admin keys)
• Economic or tokenomic vulnerabilities that do not result in direct loss of funds
• Centralization risks inherent to the protocol design
• UI/UX issues that do not impact security
• Documentation errors or inconsistencies
• Spelling or grammar mistakes
• Issues caused by attacks requiring access to leaked keys/credentials
• A one-block DOS — where the attacker causes a transaction to revert in a single block, but it can be successfully re-executed in the next block — is evaluated based on that single occurrence only, even if the attack is theoretically repeatable. Such an issue is presumed not to repeat. It qualifies as valid only if the affected functionality is clearly time-sensitive.
• Issues caused by incorrectly configured user parameters (e.g., enabling multiple migration routes that, when combined, result in a loss of funds for that user)

Disclosure Policy

All vulnerabilities must be reported exclusively through the Sherlock platform and must not be disclosed publicly until:

1. The vulnerability has been verified by the protocol team
2. A fix has been implemented and deployed
3. The protocol team has granted explicit permission for public disclosure
   Premature public disclosure can result in disqualification from the reward.

Testing

When testing for vulnerabilities:

• Do not test on public mainnet deployments
• Use local test environments or testnets for all testing
• Do not attempt to access or modify other users' data
• Do not perform any actions that could disrupt the normal operation of the protocol
• Do not use automated scanning tools without manual verification

Prohibited actions

The following actions are strictly prohibited:

• Attempting to access private user data
• Social engineering or phishing attacks
• Denial of service attacks
• Physical or electronic attempts to access protocol's infrastructure
• Any testing that violates applicable laws or regulations
• Threatening or harassing behavior

Additional Context

Chains in scope

Base, Mainnet, Arc.

Tokens

Tokens included in the Tenor Markets page.

Design choices

Users can set dangerous migration routes (badly configure markets, enabling multiple migration routes that, when combined, result in a loss of funds for that user).

In Tenor's delayed liquidation gate, a position that's unhealthy and becomes healthy again during the grace or liquidation period doesn't reset the grace and liquidation periods, one has to wait for the periods to end.

Protocol Resources

• Documentation: https://www.docs.tenor.finance/get-started/overview

• Contracts repo: https://github.com/tenor-labs/tenor-contracts/tree/main

• Deployment addresses: https://www.docs.tenor.finance/smart-contract-docs/addresses/

• Website: https://www.tenor.finance/

Previous audits and known issues

https://github.com/tenor-labs/tenor-contracts/tree/main/audits