FRB vulnerability disclosure policy

Purpose of this policy

FRB relies on the research community to keep our execution stack safe. This policy explains how to report vulnerabilities, what systems are in scope, and what you can expect from us. Researchers who follow these guidelines are treated as partners, not adversaries, and every FRB vulnerability disclosure is handled with the same SLA we promise to customers.

Responsible disclosure helps protect MEV traders, validators, and downstream infrastructure. Thank you for helping us keep the ecosystem safe.

Systems in scope

The following assets are covered by this policy:

• ai-frb.com, docs, and associated marketing properties.
• Installer delivery pipeline, update endpoints, and release artifacts.
• Relay configuration APIs, telemetry collectors, and authenticated operator portals.

Testing against infrastructure owned by customers, partners, or cloud providers must follow their rules as well.

Out of scope & safe conduct

The following activities are prohibited even if they reveal a weakness:

• Accessing, modifying, or deleting customer data without explicit permission.
• Executing attacks that impact service availability for other users.
• Phishing FRB employees or social-engineering partners.
• Using automated scanners that generate excessive traffic.

Do not exploit the vulnerability beyond what is necessary to demonstrate impact, and never involve live funds or wallets.

Legal & testing boundaries

We will work with you to understand every finding as long as it stays in scope—our public properties and the FRB agent. Physical facilities, partner systems, and unrelated assets remain off limits so there is no confusion about impact, and FRB personnel will not pursue legal action related to your research when you follow these rules.

• Never compromise or exfiltrate data, degrade user experience, or access proprietary information or trade secrets.
• Keep proofs consistent with the extent necessary to confirm a vulnerability’s presence—avoid privacy violations and stop once impact is demonstrated.
• Do not run network denial of service (DoS or DDoS) tests or spam attempts; availability testing is out of scope.
• Do not contact outside entities or pursue legal action related to your research; keep everything coordinated through FRB so the right personnel stay involved.
• Use any suggestions for defensive purposes only to mitigate or remediate vulnerabilities; destructive proof-of-concept releases hurt the ecosystem.
• Never engage in scope creep or destruction or manipulation of data beyond what is required to validate the finding.

If you need encrypted channels, request our PGP key via Support/SLA and send logs there—we will keep everything consistent with the extent necessary to confirm a vulnerability’s presence while we remediate.

Responsible disclosure guidelines

To remain in good standing, please:

• Stop testing immediately after you confirm the issue.
• Keep vulnerability details confidential until FRB resolves the issue.
• Use only the data you generated; do not exfiltrate production data.
• Follow local laws and respect any contractual obligations you may have.

We offer safe harbor for good-faith testing that complies with these guidelines.

How to report securely

Follow these guidelines to keep sensitive data safe while we review your FRB vulnerability disclosure:

• Use our PGP key (request it via support) before sharing logs or wallet metadata.
• Send large payloads through your secure file portal rather than email attachments.
• Provide a Signal or phone contact only if real-time coordination is required; otherwise email is preferred.

What to include

1. Environment (OS version, FRB build hash, relay used).
2. Exact reproduction steps and proof-of-concept output.
3. Impact assessment (e.g., RCE, data exposure, DoS) plus suggested severity.
4. Any mitigations or temporary workarounds discovered during testing.
5. Your preferred disclosure timeline and name/handle for attribution (optional).

Encrypt sensitive payloads if possible and share logs or screenshots to speed up triage.

What you can expect from us

1. Acknowledge receipt within 48 hours.
2. Provide severity triage + next steps within five business days.
3. Collaborate on remediation timelines and request coordination for disclosure.
4. Share credit (if desired) once the fix is deployed and users are protected.

We believe in good-faith collaboration. Please encrypt sensitive reports if possible; our PGP key is available on request.

Triaging & remediation

Security engineering loops in the service owner, verifies exploitation, and assigns remediation work. Critical issues may trigger hotfixes or coordinated deployment windows; lower-severity bugs land in the weekly release train. Refer to the security overview for an outline of our control layers.

We will keep you updated as the issue progresses through fix, validation, and release, especially if we need further context.

Coordination & next steps

Once remediation is live, we will confirm the fix with you, discuss disclosure timelines, and—if applicable—share CVE or advisory references. Non-security follow-ups (billing, legal, or account changes) should go through the support team so the right people remain involved.

Questions about data handling related to your report can be answered via our privacy policy.