Vulnerability Disclosure Policy

1. Purpose

Runtime Guard is security software for Safe multisig operations. Coordinated vulnerability disclosure is therefore part of the product's security posture.

This policy gives researchers a clear reporting route while protecting Runtime Guard, users, and third parties from unsafe testing.

2. Reporting channel

Send vulnerability reports to contact@runtime-guard.io.

Include, where available:

• the affected domain, application, extension, smart contract, API endpoint, repository path, or product workflow;
• a concise vulnerability description;
• reproducible steps;
• expected and actual impact;
• screenshots, logs, transaction hashes, Safe transaction hashes, proof-of-concept code, or calldata where useful;
• whether the issue may affect customer funds, signatures, policy evaluation, report integrity, billing, privacy, or availability;
• your preferred contact details for follow-up.

Do not include private keys, seed phrases, recovery phrases, customer secrets, personal data, or third-party confidential information.

3. Scope

In scope:

• www.runtime-guard.io;
• app.runtime-guard.io;
• Runtime Guard browser extensions published by Runtime Guard;
• Runtime Guard APIs, report-generation flows, entitlement checks, and Paddle-integration logic exposed by Runtime Guard;
• Runtime DeFi Guard report, policy, co-signing, and signature-verification workflows;
• Runtime Lockdown Guard smart contracts, relayer workflows, timelock, lockdown, and recovery workflows once publicly deployed or explicitly shared for review;
• public open-source Runtime Guard code or documentation that Runtime Guard identifies as part of the product.

Out of scope unless Runtime Guard gives written authorization:

• third-party products such as Safe, Paddle, wallet providers, RPC providers, Cloudflare, Google Cloud, GitHub, browser stores, or blockchain explorers;
• user-owned Safes, wallets, devices, accounts, browser profiles, private keys, or seed phrases;
• phishing, social engineering, spam, physical attacks, coercion, or attempts to compromise employees, contractors, users, vendors, or families;
• denial-of-service, stress testing, volumetric testing, or resource-exhaustion testing;
• attacks requiring access to leaked credentials, compromised devices, or secrets not obtained through Runtime Guard;
• low-impact findings without a plausible security consequence, such as missing cosmetic headers on non-sensitive pages, clickjacking on non-interactive pages where framing is already denied elsewhere, or version banners without exploitability.

4. Testing rules

Researchers must:

• use only accounts, wallets, Safes, transactions, subscriptions, and devices they own or are authorized to test;
• avoid accessing, modifying, deleting, freezing, delaying, signing, or broadcasting transactions for third-party Safes or wallets;
• avoid moving, locking, freezing, draining, approving, or transferring assets that do not belong to them;
• avoid persistent access, lateral movement, malware, credential theft, or attempts to bypass physical security controls;
• stop testing and report promptly if they encounter customer data, secrets, private keys, payment data, or material service instability;
• keep vulnerability details confidential until Runtime Guard has investigated and either remediated the issue or agreed to disclosure.

For on-chain or Safe-related issues, use a test Safe, local fork, testnet, simulation, or dry-run environment whenever possible. Do not test against live customer funds.

5. Safe harbor

Runtime Guard will not pursue legal action against researchers who make a good-faith report and comply with this policy.

This safe harbor does not apply to:

• extortion, threats, ransom demands, or requests for payment in exchange for silence;
• intentional harm to Runtime Guard, users, third parties, systems, funds, data, reputation, or availability;
• violations of applicable law;
• testing outside the scope or rules of this policy;
• disclosure of private, confidential, personal, or security-sensitive information without authorization.

This policy does not authorize testing against third-party systems. Third-party systems remain subject to their own rules.

6. Response process

Runtime Guard aims to:

• acknowledge receipt within 5 business days;
• triage credible reports within 15 business days;
• prioritize issues affecting funds, signatures, policy enforcement, private keys, report integrity, lockdown, timelock, billing authorization, or personal data;
• keep the reporter informed where practical;
• coordinate public disclosure when a fix, mitigation, or risk decision is complete.

These timelines are targets, not contractual commitments.

7. Bounties and compensation

Runtime Guard does not operate a public bug bounty program unless a separate bounty page, contest, or written agreement says otherwise.

Submitting a report does not create an entitlement to payment, equity, employment, advisory status, public credit, or reimbursement.

Runtime Guard may choose to provide thanks, credit, or compensation at its sole discretion, subject to legality, sanctions rules, tax requirements, and the quality and usefulness of the report.

8. Public disclosure

Do not publicly disclose a vulnerability before Runtime Guard has had a reasonable opportunity to investigate and remediate it.

Runtime Guard may ask for additional time where the issue affects customer funds, on-chain contracts, third-party vendors, user privacy, or coordinated ecosystem response.

9. Emergency handling

If a report indicates an active exploit, imminent customer-fund risk, private-key exposure, production signing-path compromise, lockdown/timelock bypass, or material payment or privacy incident, state this clearly in the email subject.

Suggested subject format:

URGENT SECURITY REPORT - Runtime Guard - [short issue name]

10. Changes

Runtime Guard may update this policy from time to time. The latest version is published on the Runtime Guard website.