Security

​

Overview

Security is a top priority for the Firedancer project. This page describes the security program, including how to report vulnerabilities, the bug bounty program, and information about security audits.

​

Bug Bounty Program

​

Scope

The bug bounty program covers Firedancer v0.1, which has undergone rigorous security testing and auditing. This includes:

• Frankendancer validator implementation
• Core networking stack
• Block production components
• Consensus-critical code in scope

​

How to Submit

Security-relevant bugs in Firedancer v0.1 should be submitted to our Immunefi bug bounty program.

​

Out of Scope Code

Code outside the scope of the bug bounty program is still in development and has yet to go through more rigorous security testing and auditing. For out-of-scope code:

• Full Firedancer implementation (non-Frankendancer components)
• Experimental features
• Code marked as in-development

These findings should be reported through the standard GitHub issue process rather than through the bug bounty program.

​

Reporting Vulnerabilities

​

In-Scope Vulnerabilities (v0.1)

For security issues in Firedancer v0.1:

1. Submit through Immunefi: Use the official bug bounty program
2. Do not disclose publicly: Avoid creating public GitHub issues for security vulnerabilities
3. Provide details: Include reproduction steps, impact assessment, and any proof of concept

​

Out-of-Scope Vulnerabilities

For security issues in code outside the bug bounty scope:

1. Create a GitHub issue: Submit to Firedancer issues
2. Use appropriate labels: Tag with security-related labels if available
3. Provide context: Explain the issue, affected code, and potential impact

​

What to Include

When reporting any security issue, include:

• Description: Clear explanation of the vulnerability
• Location: File paths and line numbers of affected code
• Severity: Your assessment of the impact
• Reproduction Steps: Detailed steps to reproduce the issue
• Environment: OS, compiler version, and configuration details
• Proof of Concept: Code, commands, or scripts demonstrating the issue
• Suggested Fix: If you have ideas for remediation (optional)

​

Security Best Practices

​

For Contributors

​

Fuzzing Requirements

• Most code should be covered by fuzz tests
• Use graceful error handling instead of aborting
• Provide test APIs for mocking state in security-sensitive code

​

Test Vectors

Firedancer runs extensive test vectors in CI that test conformance with Agave down to the same error code. Test vector inputs are sourced from:

• Vectors generated by past fuzzing campaigns
• Hand-written/manually generated unit tests
• Fixed mismatches, added as regression tests

​

Secure Coding Guidelines

​

Sandbox Architecture

During initialization:

• A seccomp profile is installed to each tile
• Only allowed syscalls can be executed
• Unexpected syscalls will crash Firedancer

When contributing:

• Be aware of which syscalls glibc uses under the hood
• Syscalls used can differ between glibc versions
• Test your code with seccomp enabled
• Document any new syscall requirements

​

Third Party Security Audits

The Firedancer project engages third-party security firms to conduct independent security audits.

​

Published Audits

As third-party audits are completed and issues are sufficiently addressed, we make those audit reports public.

​

Audit Process

The security audit process includes:

1. Engagement: Third-party firms are engaged to audit specific components
2. Review: Auditors conduct comprehensive security reviews
3. Remediation: Issues found are addressed by the Firedancer team
4. Publication: Once remediation is complete, audit reports are published

​

Audit Contest

Leading up to the mainnet launch of Firedancer v0.1, an audit contest was held on Immunefi.

​

Contest Details

• Platform: Immunefi Audit Contest
• Duration: July 10, 2024 to August 21, 2024
• Focus: Comprehensive security review before mainnet launch

​

Security Features

​

Sandboxing

Firedancer’s architecture allows it to run with:

• Highly restrictive sandbox
• Almost no system calls during operation
• Strict seccomp profiles per tile

​

Independent Implementation

Security benefits of independent implementation:

• No shared vulnerabilities with other clients
• Different attack surface
• Resilience to dependency vulnerabilities
• Protection against supply chain attacks in build tooling

​

Continuous Testing

Firedancer employs extensive testing:

• Fuzz testing coverage for most code
• Test vectors verifying consensus compatibility
• Continuous integration testing
• Conformance testing against Agave

​

Responsible Disclosure

​

Our Commitment

The Firedancer team is committed to:

• Responding promptly to security reports
• Working with researchers to validate and fix issues
• Providing credit to researchers who report issues responsibly
• Maintaining transparency through public audit reports

​

Researcher Guidelines

We ask that security researchers:

• Report vulnerabilities through proper channels (Immunefi or GitHub)
• Allow reasonable time for fixes before public disclosure
• Do not exploit vulnerabilities beyond proof of concept
• Do not access or modify data without permission
• Comply with the bug bounty program terms and conditions

​

Contact

For security-related questions or concerns:

• Bug Bounty (v0.1): Immunefi Program
• Other Issues: GitHub Issues
• General Questions: Firedancer Documentation

​

Resources

• Immunefi Bug Bounty Program
• Firedancer v0.1 Audit Reports
• Test Vectors Repository
• Audit Contest Details
• GitHub Repository