Open Sourcing Arc: Run Your Own Arc Node and Bug Bounty Program

As Arc¹ approaches mainnet, we’re expanding how the network is tested and challenged. Today, we’re open sourcing Arc testnet code, launching an Arc bug bounty campaign on HackerOne, and enabling any developer to run an Arc node. Together, these steps expand the review surface before Arc mainnet and create a clearer path for researchers, audit firms, and infrastructure teams to inspect, test, and challenge Arc before capital is at risk.

Both internal and external reviews remain central to preparing any network for production. Mainnet readiness also depends on repeated scrutiny, reproducible testing, and operational steadiness. Publishing the code and establishing a formal disclosure path brings more of that work into the open.

What’s launching

This launch includes three connected pieces of work.

• Arc testnet code is now open source, giving researchers and builders direct access to the implementation so they can review it, compile it, and work from the code itself.
• The Arc bug bounty is now live on HackerOne, giving researchers a formal disclosure channel with defined scope, triage, and payouts for valid findings.
• Developers can also run Arc nodes,² making it easier to verify behavior independently and test Arc infrastructure without relying on third-party providers.

Together, these changes make Arc easier to evaluate in practice and give outside reviewers a clearer path to potentially discover meaningful findings before mainnet.

The testing model behind the bug bounty program

We are looking for reproducible, security-relevant findings that materially affect network safety, liveness, correctness, or reliability. The goal is to support serious review from researchers who can produce original findings, provide clear proof, and explain real impact.

Bug bounty testing must happen locally. Researchers should not test against Arc Public Testnet. To participate in the bug bounty program please follow these instructions to launch and use a Local Testnet.

The Local Testnet will allow you to reproduce and demonstrate any potential bug locally, without requiring a faucet nor an RPC.

Submissions should reproduce against correct, unmodified Arc nodes and include the material needed for quick verification: a working proof of concept, environment and version details, clear reproduction steps, and a concise explanation of impact. Reports that rely on vague theory, modified attacker-controlled nodes alone, or behavior that cannot be reproduced fall outside the scope of this program.

The attacker model is intentionally narrow, and consistent with standard Layer-1 threat models. We are interested in vulnerabilities where an external party runs a crafted node or sends crafted transactions or messages to attempt to break, slow, trick, or leak information from correct, unmodified Arc nodes. That keeps the program focused on findings that matter under realistic production conditions.

How to participate

Start with the HackerOne program page for scope, eligibility, and submission requirements.

Then use the relevant Arc documentation to set up your local test environment. Review the repositories in scope, reproduce findings locally, and submit complete reports through HackerOne with the required proof of concept and supporting documentation.

This program is separate from Circle’s broader HackerOne bug bounty. It is a campaign focused specifically on Arc, the repositories in scope, and a testing model built around reproducible findings ahead of mainnet.

Why this matters before mainnet

Arc is at a stage where broader external scrutiny matters. Open sourcing the testnet code, giving researchers a defined disclosure path, and enabling any team to run an Arc node all expand the ways issues can surface before launch.

That work complements internal review and external audits, providing the ability to inspect Arc closely, test it under controlled conditions, and help strengthen the network before mainnet.