Layer3 Smart Contracts: Program info

While we've outlined specific 'In Scope' and 'Out of Scope' areas, if you discover a vulnerability that doesn't clearly fit into these categories, we encourage you to submit it following the Program Rules. Your submission will be carefully reviewed and triaged accordingly.

IN SCOPE: SMART CONTRACT VULNERABILITIES

We are looking for evidence and reasons for incorrect behavior of the smart contract, which could cause unintended functionality:

Critical

• Stealing or loss of funds
  • Staked funds
  • Rewards distributed to the contract
  • Unclaimed rewards earned by stakers
• Unauthorized transaction(s)
• Calling privileged functions bound to the owner
• Bypassing access controls to alter staking parameters
• Transferring staked funds without proper authorization
• Performing an emergency withdrawal
• Permanent freezing
  • Staked funds
  • Rewards distributed to the contract
  • Unclaimed rewards earned by stakers

High

• Temporary freezing
  • Staked funds
  • Rewards distributed to the contract
  • Unclaimed rewards earned by stakers

Medium

• Griefing or malicious disruption

OUT OF SCOPE: SMART CONTRACT VULNERABILITIES

We are excluding issues that do not directly impact the intended functionality of the smart contract or do not demonstrate a practical, real-world vulnerability. This includes theoretical concerns, issues related to non-critical aspects of the contract, or vulnerabilities in external dependencies that fall outside our direct control.

Conceptual

• Theoretical vulnerabilities without practical proof or demonstration.
• Vulnerabilities in our staking contract that do not demonstrate a direct impact within the specified scope.

Build and Code Quality

• Use of an old compiler version.
• Lack of compiler version locking.
• Vulnerabilities in imported contracts.
• Code style guide violations.
• Presence of redundant or unused code.
• Issues found in test files or configuration files.
• Vulnerabilities specifically related to the OpenZeppelin proxy implementation or contract upgrades.

Feature-Specific

• Gas optimizations.
• Best practice recommendations.
• Feature requests or suggestions for improvement.
• Issues related to the triggering of withdrawals, as long as funds reach the correct address.

Permissions & Roles

• Impacts caused by attacks requiring access to leaked keys or credentials.
• Impacts caused by attacks requiring access to privileged roles (e.g., owner, admin), except in cases where the contracts are explicitly designed to have no privileged access.
• Assumptions that trusted roles like Owner or Admin will behave maliciously. Reports based on these assumptions will be considered invalid.

Network and External Factors

• Incorrect data supplied by third-party oracles.
• Impacts requiring basic economic or governance attacks (e.g., 51% attack).
• Impacts involving centralization risks.
• Sybil attacks or other similar non-contract-specific exploits.

Miscellaneous

• Known issues that have already been publicly disclosed or self-reported.
• Issues related to the OpenZeppelin proxy contract itself, rather than the custom logic implemented in the staking contract.
• Any issues described in previous security audit reports.

Known issues

• Please be aware that the Layer3 team actively monitors and addresses vulnerabilities across all assets internally and across platforms. If you report an issue that is already known to us, it will be marked as a duplicate and closed. We kindly ask for your understanding in respecting our final decision and refraining from further negotiations once a decision has been made.
• The parameter swap issue on the function withdrawERC1155 is a known issue.

1. Submission Guidelines:

   • Submit one vulnerability per report unless multiple vulnerabilities need to be chained to demonstrate impact.
   • A Proof of Concept (PoC) is required for all severity levels.

2. Testing Guidelines:

   • Perform testing only within the defined scope. Avoid testing on mainnet or public testnet deployed code; all testing should be done on local forks of public testnet or mainnet.
   • Make every effort not to damage or restrict the availability of products, services, or infrastructure.
   • Avoid compromising personal data, and do not cause any interruption or degradation of service.
   • Do not access or modify other users' data. Localize all tests to your own accounts.

3. Prohibited Activities:

   • Do not use automated web application scanners that generate excessive traffic.
   • Do not exploit any DoS/DDoS vulnerabilities, social engineering attacks, or spam techniques.
   • Avoid spamming forms or account creation flows using automated tools.
   • Do not break any laws or exceed the defined scope during testing.

4. Vulnerability Handling:

   • If you find chain vulnerabilities, only the vulnerability with the highest severity will be eligible for a reward.
   • Critical issues are defined as those resulting in the loss or permanent freezing of staked funds.

5. Confidentiality:

   • Any details of discovered vulnerabilities must not be communicated to anyone outside of the authorized team (e.g., HackenProof Team or Company employees) without proper permission.

6. Bounty Payments:

   • Critical severity issues are rewarded with a 6-month linear vesting schedule, with a maximum payout of USD 500,000 in $DEXE.
   • Medium severity bounties are paid in stablecoins, while high and critical severity bounties are paid in $DEXE.
   • Low severity issues are considered out of scope and are not eligible for a bounty.

7. Legal Compliance:

   • Ensure that all testing is conducted legally and within the scope of the program.
   • If your finding is valid, you may be required to undergo additional KYC verification to proceed with payment.

• Do not discuss this program or any vulnerabilities (even resolved ones) outside of the program without express consent from the organization
• No vulnerability disclosure, including partial is allowed for the moment.
• Please do NOT publish/discuss bugs

We are happy to thank everyone who submits valid reports which help us improve the security. However, only those that meet the following eligibility requirements may receive a monetary reward:

• You must be the first reporter of a vulnerability.
• The vulnerability must be a qualifying vulnerability
• Any vulnerability found must be reported no later than 24 hours after discovery
• You must send a clear textual description of the report along with steps to reproduce the issue, include attachments such as screenshots or proof of concept code as necessary.
• You must not be a former or current employee of us or one of its contractor.
• ONLY USE the EMAIL under which you registered your HackenProof account (in case of violation, no bounty can be awarded)
• Provide detailed but to-the point reproduction steps