Reward ranges below are preliminary and will be replaced with final values when the program launches alongside the first audited release. The scope, severity model, and submission rules are not preliminary — those are the rules to follow today.
Scope
In scope
Anything a malicious actor could use to steal user funds, halt the protocol, corrupt finalized state, or break one of the four protocol-native guarantees (OTD, PTA, RNS, PTAD) is in scope by default. Concretely:- IntentionKernel — execution semantics, the closed-world instruction set, sequencing discipline, byte-determinism. Anything that lets one validator’s execution diverge from another’s, or lets a transaction take an effect not present in the protocol specification.
- IntentionBFT — consensus safety and liveness, leader election, canonical sequencing commitments, signature aggregation, and the post-quantum migration path.
- Oracle and price quorum — observation submission, MAD-based outlier rejection, the certified-price envelope, and any path that lets a transaction read a price not committed in the same consensus event.
- Cross-chain bridge — the validator-attested deposit and withdrawal flow, the on-chain bridge contracts on supported destination chains, the threshold signing and key-management process, and the operational controls around them.
- Trading engine — matching, mark pricing, liquidation cascades, the insurance fund, ADL, funding settlement, and the protocol-native risk pipeline.
- Public API surfaces — REST and WebSocket endpoints under API Reference, authentication, signing, rate limiting, and any code path reachable from the internet.
- Validator software — the node binary, key handling, peer-to-peer transport, and any operational tool that a validator runs in production.
Out of scope
The following categories are explicitly excluded from the bounty program. Reports against these targets will be acknowledged but are not eligible for a reward.- Volumetric denial-of-service attacks against validator infrastructure or public RPC endpoints. The defense for these lives in operational mitigation (see DDoS defense), not in protocol patches.
- Issues in third-party software, dependencies, or services that Intention does not control.
- Findings that depend on physical access to validator hardware, social engineering against Intention Labs employees, or supply-chain attacks against tools the team uses internally.
- Self-XSS, content spoofing without security impact, missing security headers, and other low-impact issues against the marketing site or this documentation site.
- Bugs in software that has been formally retired and is no longer running on any validator or in any production service.
- Theoretical attacks that require improbable preconditions (for example, a 51% honest-stake compromise) without a concrete path to triggering those preconditions.
Severity classification
Findings are graded on a four-tier scale. The grade is determined by the combination of impact (what an attacker can achieve) and likelihood (how realistic the attack scenario is, including required preconditions and resources). Asset-at-risk is the dominant impact factor for any finding that touches user funds.| Tier | What it means | Representative examples |
|---|---|---|
| Critical | Direct theft, permanent loss, or unauthorized minting of user funds; consensus safety violation; oracle forgery that can be persisted. | A path through the kernel that lets a transaction credit an account it did not pay for. A signature aggregation flaw that lets $f$ validators commit a block. A bridge withdrawal that mints destination tokens without a corresponding lock. |
| High | Loss limited to a subset of users or a specific market; consensus liveness halt; griefing attacks on the bridge; targeted forced liquidation. | A liquidation engine path that can be triggered against a specific position without a real margin breach. A bridge state machine that can be wedged so withdrawals stop processing for one chain. Privilege escalation against validator software short of consensus compromise. |
| Medium | No direct fund loss, but a meaningful breach of protocol guarantees or operational integrity. | Unauthorized read of state that should be private. A rate-limit bypass that materially raises the cost of running the chain. A way to make the Verifiable Execution Stream emit events that are inconsistent with finalized state. |
| Low | Limited-impact issues with no path to fund loss or consensus disruption. | Non-impactful information disclosure. Inconsistent error responses on the public API. Minor operational issues with no exploit path. |
Reward ranges
All bounty rewards are paid in USDC to a wallet address designated by the reporter. There is no native token involved.| Tier | Preliminary reward range |
|---|---|
| Critical | TBD — high five to six figures |
| High | TBD — mid four to low five figures |
| Medium | TBD — low four figures |
| Low | TBD — symbolic / swag |
- One bounty per unique vulnerability. If the same root cause produces multiple findings, the team consolidates them into a single award at the highest applicable severity.
- First reporter wins. Duplicate reports of an issue already under triage are acknowledged but not rewarded.
- No reward for known issues. Findings that match items already on the security team’s internal backlog or already covered by a published audit are not eligible. The team will share the relevant reference when this happens.
- Reward is contingent on cooperation. Public disclosure before remediation, exploitation beyond a minimal proof of concept, or any harm to users voids the reward.
Rules of engagement
Researchers participating in the program agree to the following constraints. These exist to protect users, to protect other researchers, and to keep the program something Intention can keep running.- No testing against production with real user funds. Use the public testnet (when live) or a private fork. If a finding can only be reproduced on production, contact
security@intention.xyzfirst and do not execute the proof of concept until the security team has acknowledged the request. - No social engineering. Do not target Intention Labs employees, contractors, validators, or partners with phishing, pretexting, or other social attacks.
- No volumetric attacks. No traffic-flood denial-of-service, no resource-exhaustion attacks against shared infrastructure.
- Minimal proof of concept only. Demonstrate impact with the smallest possible action. Do not exfiltrate user data, do not move funds beyond the amount required to prove the issue, and do not persist on the system after the proof of concept is complete.
- No public disclosure before remediation. Coordinated disclosure is the default. The security team will work with you on a public disclosure timeline once the fix is deployed.
- Comply with applicable law. The safe-harbor language below applies to good-faith research conducted under these rules. Activities that violate computer-misuse laws in any relevant jurisdiction are not protected.
How to submit
Prepare the report
A complete report includes: a clear written description of the vulnerability, the affected component and version, step-by-step reproduction, a minimal proof of concept (code or transaction hashes), the impact you believe the issue has, and any suggested remediation. The clearer the report, the faster triage runs.
Send to `security@intention.xyz`
Email the report to
security@intention.xyz. A PGP key for encrypted submissions will be published with the program launch — until then, send the initial mail in plaintext and the team will move sensitive details to an encrypted channel during the first round-trip. Do not post any part of the finding publicly before the team has acknowledged it.Receive an acknowledgement within 48 hours
The security team acknowledges every submission within two business days. The acknowledgement confirms receipt, asks for any missing information, and assigns a triage owner. If you have not received an acknowledgement after 72 hours, please re-send.
Triage and remediation
Validated findings move into remediation. The security team works with the relevant engineering owners to ship a fix, and shares progress with the reporter on a regular cadence. The team may ask for clarification or additional reproduction steps; replies typically arrive within one business day.
Reward and disclosure
Once the fix is deployed and the issue is no longer exploitable, the reward is paid in USDC to the address the reporter provided. The reporter is credited in the post-mortem and any subsequent disclosure with their consent. Full post-mortems are published when doing so does not expose users to residual risk.
Safe harbor
Good-faith security research conducted within the rules above will not be pursued legally by Intention Labs. The safe-harbor commitment covers researchers who:- Stay within the scope and rules of engagement on this page
- Do not access, modify, or destroy user data beyond what is strictly required to demonstrate impact
- Report findings privately and follow the coordinated disclosure timeline
- Do not exploit findings for personal gain or for any purpose beyond the bounty program
Contact
- Security disclosures:
security@intention.xyz - General support questions:
support@intention.xyz - Press, partnerships, and bounty program inquiries that are not vulnerability reports:
contact@intention.xyz