Skip to content

Security: Rotwang9000/flashbank-net

Security

SECURITY.md

Security Policy

FlashBank.net is committed to maintaining the highest security standards for our immutable flash loan network. This document outlines our security practices, vulnerability reporting process, and security guarantees.

πŸ›‘οΈ Security Guarantees

Immutable Architecture

  • Non-Upgradeable: Contracts cannot be modified after deployment
  • No Proxy Patterns: Direct contract deployment with no upgrade mechanisms
  • Hardcoded Limits: Maximum fee rates and flash loan amounts cannot be exceeded
  • No Admin Backdoors: Owner cannot steal user funds or bypass security checks

Smart Contract Security

  • Reentrancy Protection: All state-changing functions protected against reentrancy attacks
  • Access Control: Strict permissions for administrative functions
  • Input Validation: All inputs validated and sanitised
  • Overflow Protection: Using Solidity 0.8.19+ built-in overflow protection
  • Event Logging: All critical operations emit events for transparency

Operational Security

  • Zero Trust Model: Trust minimised through immutable code
  • Transparent Operations: All functions and their purposes clearly documented
  • Public Auditing: Code is open source for community review
  • Automated Testing: Comprehensive test suite with 47 security tests

πŸ”’ Security Features

Flash Loan Protection

// Maximum fee rate: 10% (hardcoded, cannot be changed)
uint256 public constant MAX_FEE_RATE = 1000;

// Absolute maximum flash loan: 10,000 ETH (hardcoded)
uint256 public constant ABSOLUTE_MAX_FLASH_LOAN = 10000 ether;

// Reentrancy protection for all critical functions
modifier nonReentrant() { ... }

Access Control

// Only owner can modify operational parameters (within limits)
function setFlashLoanFeeRate(uint256 newFeeRate) external onlyOwner {
    require(newFeeRate <= MAX_FEE_RATE, "Fee rate too high");
    // ...
}

// Users can only withdraw their own funds
function withdraw(uint256 amount) external nonReentrant {
    require(amount <= userDeposits[msg.sender], "Insufficient balance");
    // ...
}

Fund Protection

  • Temporary Custody: User ETH only held during flash loan execution (microseconds)
  • Automatic Return: Failed flash loans automatically return all ETH to users
  • Profit Distribution: Successful flash loans add profits to user accounts
  • No Fund Locking: Users can withdraw anytime (when no flash loan active)

πŸ” Security Testing

Automated Test Suite

  • 47 Security Tests: Comprehensive coverage of attack vectors
  • Anti-Rug Pull Tests: Verify owner cannot steal funds
  • Reentrancy Tests: Protect against recursive attacks
  • Access Control Tests: Verify permissions are properly enforced
  • Arithmetic Tests: Prevent overflow/underflow vulnerabilities
  • Edge Case Tests: Handle boundary conditions and error states

Test Categories

# Run all security tests
npm test

# Run specific security categories
npx hardhat test test/SecurityTests.test.js

# Run with gas reporting
REPORT_GAS=true npm test

Attack Vector Testing

  • Reentrancy Attacks: Malicious contracts attempting recursive calls
  • Flash Loan Griefing: Borrowers attempting to break the system
  • Admin Privilege Escalation: Attempts to bypass owner restrictions
  • Arithmetic Exploits: Overflow/underflow attack attempts
  • Access Control Bypass: Unauthorised function calls

🚨 Vulnerability Reporting

Responsible Disclosure

We appreciate security researchers who help keep FlashBank.net secure. Please follow responsible disclosure:

DO NOT create public GitHub issues for security vulnerabilities.

How to Report

  1. Email: Send details to security@flashbank.net
  2. PGP Encryption: Use our public key for sensitive information
  3. Include:
    • Detailed description of the vulnerability
    • Steps to reproduce the issue
    • Potential impact assessment
    • Suggested fix (if available)
    • Your contact information for follow-up

What to Expect

  • Acknowledgment: Within 24 hours
  • Initial Assessment: Within 72 hours
  • Status Updates: Weekly until resolved
  • Resolution Timeline: 30-90 days depending on severity
  • Public Disclosure: After fix is deployed and users protected

Severity Levels

Critical (P0) - Immediate Action

  • Funds can be drained or stolen
  • Core contract functionality broken
  • Immutability compromised

High (P1) - 24-48 Hours

  • Significant DoS attacks possible
  • User funds temporarily at risk
  • Major functionality impacted

Medium (P2) - 1-2 Weeks

  • Minor DoS or griefing attacks
  • Non-critical functionality issues
  • Information disclosure

Low (P3) - 1-4 Weeks

  • Cosmetic issues
  • Documentation errors
  • Minor UX problems

πŸ† Bug Bounty Program

Rewards

  • Critical: $10,000 - $50,000
  • High: $2,500 - $10,000
  • Medium: $500 - $2,500
  • Low: $100 - $500

Scope

  • In Scope:

    • Smart contracts in /contracts/ directory
    • Deployment scripts with security implications
    • Frontend wallet integration security issues
  • Out of Scope:

    • UI/UX issues without security impact
    • Social engineering attacks
    • Physical attacks
    • Third-party services (RPC providers, etc.)

Eligibility

  • First to report gets the bounty
  • Must follow responsible disclosure
  • No public disclosure before fix
  • Cannot exploit on mainnet
  • Must provide clear reproduction steps

πŸ” Security Best Practices

For Users

  • Verify Contract Address: Always check you're interacting with the correct contract
  • Start Small: Test with small amounts before large deposits
  • Understand Risks: Flash loans involve smart contract risk
  • Keep Private Keys Safe: Never share your wallet private keys
  • Use Hardware Wallets: For large amounts, use hardware wallet security

For Developers

  • Code Review: All changes reviewed by multiple developers
  • Test Coverage: Maintain >95% test coverage for critical functions
  • Static Analysis: Use tools like Slither for vulnerability detection
  • Formal Verification: Consider formal verification for critical functions
  • Dependency Management: Keep dependencies updated and audited

For Integrators

  • Follow Examples: Use provided integration examples
  • Error Handling: Implement proper error handling for failed flash loans
  • Gas Limits: Account for gas costs in your MEV strategies
  • Testing: Test thoroughly on testnets before mainnet
  • Security Review: Have your integration code reviewed

πŸ”’ Audit History

Planned Audits

  • Pre-Launch: Comprehensive security audit before mainnet deployment
  • Annual Reviews: Yearly security assessments
  • Code Changes: Audit any significant modifications

Current Status

  • Self-Audited: Extensive internal security review completed
  • Community Reviewed: Open source code available for public audit
  • Test Coverage: 47 security tests covering known attack vectors
  • Static Analysis: Clean results from security scanning tools

πŸ“‹ Security Checklist

Before each deployment:

  • All tests pass including security tests
  • Static analysis shows no vulnerabilities
  • Code review completed by multiple team members
  • Gas costs optimised and limits verified
  • Documentation updated with security implications
  • Deployment script tested on testnet
  • Contract addresses verified and documented

πŸ“ž Contact Information


⚠️ Disclaimers

  • Smart Contract Risk: All smart contracts carry inherent risks
  • No Guarantees: Security measures reduce but cannot eliminate all risks
  • User Responsibility: Users are responsible for their own due diligence
  • Beta Software: This is experimental DeFi technology
  • Regulatory Risk: Flash loans may face future regulatory scrutiny

Security is our top priority. Help us keep FlashBank.net the most secure flash loan protocol in DeFi! πŸ›‘οΈ

There aren't any published security advisories