Security Policy
Version 1.0.0 · revised 2026-09-02 · keccak256 0x4488e6714a71ecf3cdb3841802bb383535e4b83b734ef6f9cdb5ad3df5b94082
In scope: Protocol V3 contracts on Polygon PoS (chainId 137)
- VAULT_FACTORY
- 0xD01263C7ABee8c44BaEb652014Ee21b9fAafFEA3
- VAULT_IMPLEMENTATION
- 0xCb5c7b7264b36Dac6C45d3AD5ce5749B189c7B4f
Every vault deployed through the V3 factory is in scope. Prior Protocol versions and test deployments are out of scope (Policy, Section 3(f)).
SuperStrat Security Policy
Version 1.0.0 Date of last revision: 2026-09-02 Effective from: publication on the Interface
This Policy is an integral part of the SuperStrat Terms of Use (the "Terms") and defines the scope of the good-faith security research carve-out in Section 9(e) of the Terms. Capitalized terms have the meanings given in the Terms.
1. Purpose
The Operator welcomes reports of security vulnerabilities in the Protocol and the Interface. This Policy states what may be tested, how, how to report a finding, and what the Operator undertakes in return. Research conducted in accordance with this Policy is authorised and protected by the safe harbour in Section 6.
2. Scope
The following are in scope:
(a) the smart contracts of the current Protocol version deployed on Polygon PoS, as listed with their addresses on the Interface at superstrat.io/security, including the vault implementation, the vault factory, the fee splitter and every Vault deployed through the factory;
(b) the Interface at superstrat.io and its subdomains, including its API routes; and
(c) the Valuation Service, to the extent a defect in it can be demonstrated through the on-chain values it proposes or through the Interface.
3. Out of Scope
The following are not covered by this Policy, and testing them is not authorised by it:
(a) Prediction Market Venues, wallets, wallet connection services, RPC providers, blockchain networks, stablecoin issuers, bridges and any other third-party service;
(b) denial-of-service attacks, resource exhaustion, and any testing that degrades the availability of the Interface, the Protocol or a third party;
(c) social engineering, phishing, or any attack directed at the Operator's personnel, Curators or Users;
(d) findings that require physical access to a device, or a compromised or rooted device;
(e) automated scanner output without a demonstrated impact, missing best-practice headers, and issues in components the Operator does not control;
(f) contracts and Vaults that are not listed on the security page, including prior Protocol versions and test deployments; and
(g) the trading accounts controlled by Curators.
4. Rules of Engagement
Research is conducted under this Policy only if you:
(a) do not exploit a vulnerability beyond what is necessary to demonstrate it, and do not extract, move or retain any value belonging to a Vault, a User or the Operator;
(b) do not access, modify, exfiltrate or retain data of other Users beyond the minimum needed as proof, and delete any such data once the report is made;
(c) do not perform denial-of-service testing or any action that degrades availability;
(d) do not test against Vaults holding third-party funds in a way that could affect those funds; where a live test is needed, use your own funds and the smallest amount that demonstrates the issue;
(e) stop at the first proof of the vulnerability and report it, rather than continuing to explore its impact;
(f) do not disclose the vulnerability to any third party before the conditions in Section 8 are met; and
(g) comply with Applicable Law.
5. Reporting
5.1. Report every finding to security@superstrat.io. A report should include: a description of the vulnerability and its impact; the affected contract address, page or route; steps to reproduce, including transaction hashes or a proof-of-concept where applicable; and a wallet address for any reward.
5.2. The Operator acknowledges receipt of a report within 5 business days and keeps the reporter informed of the progress of remediation at reasonable intervals.
5.3. Reports may be made pseudonymously. The Operator does not require identification to accept a report; identification may be required to pay a reward.
6. Safe Harbour
6.1. Security research conducted in good faith and in accordance with Sections 2, 3, 4 and 5 of this Policy is not a breach of Sections 9(e) and 9(h) of the Terms, and the Operator will not bring or support any claim, civil or criminal, against a researcher in respect of such research.
6.2. Where a researcher's conduct is consistent with this Policy, the Operator will treat any inadvertent access to data or systems as authorised. Where the Operator becomes aware that a third party has brought a claim against a researcher for research consistent with this Policy, the Operator will make this authorisation known.
6.3. The safe harbour does not extend to conduct outside this Policy, and in particular does not extend to the exploitation of a vulnerability for gain, which remains subject to Section 9(e) of the Terms, including the constructive trust over any value extracted.
7. Rewards
7.1. The Operator may pay a reward for a report of a previously unknown vulnerability that is in scope and is confirmed by the Operator. The amount, if any, is determined by the Operator at its sole discretion, taking into account the severity of the vulnerability, the quality of the report and the assets at risk.
7.2. Rewards are paid in the Deposit Asset or another Crypto-Asset chosen by the Operator, to the wallet address provided in the report, subject to the Restricted Jurisdictions Policy and to Applicable Law.
7.3. No researcher has an entitlement to a reward. Duplicate reports, reports of issues already known to the Operator, and reports outside the scope of this Policy are not rewarded. The first complete report of a given vulnerability is the one eligible.
8. Disclosure
8.1. Disclosure is coordinated. A researcher may publish a finding only after the earlier of: (a) the Operator's written confirmation that the vulnerability has been remediated and that publication may proceed; and (b) 90 days after the report was acknowledged, unless the Operator has requested, with reasons, a defined extension because remediation requires a Protocol change that cannot be deployed within that period.
8.2. Any publication must not include information that would allow the vulnerability to be exploited against assets that remain at risk, and must not identify Users.
8.3. The Operator may publish the finding, the remediation and, with the researcher's consent, the researcher's name or pseudonym.
9. Review
This Policy is reviewed at least once a year and whenever the Protocol version or the scope of the Interface changes. Each review is dated and the version number incremented. Because the Terms incorporate this Policy by reference, an amendment to it is governed by Section 18 of the Terms.
SuperStrat Security Policy, Version 1.0.0. The authoritative version of this document and its cryptographic hash are published at superstrat.io/security.