NoirWallet: Program info

NoirWallet is a non-custodial, privacy-focused cryptocurrency wallet supporting Zcash Transparent and Shielded Transactions, with expanding capabilities in multichain asset management, Confidential Accounts, and Privacy DeFi.

NoirWallet has open-sourced its browser extension, Rust/WASM wallet core, and related wallet connectivity components. We welcome independent security researchers to identify and responsibly disclose vulnerabilities that may compromise user assets, private keys, transaction integrity, or financial privacy.

This Bug Bounty Program focuses on the following security areas:

Private Key Security: Unauthorized exposure of seed phrases, private keys, viewing keys, or other sensitive credentials.

Asset Security: Unauthorized transactions, signatures, asset transfers, or manipulation of transaction details.

Authorization Security: Wallet access control, dApp permissions, transaction approvals, and security boundaries between websites and wallet components.

Privacy Security: Unauthorized disclosure of protected Shielded Transaction data, private memos, or other non-public wallet information.

Wallet Core Security: Security vulnerabilities in transaction construction, signing, account recovery, synchronization, and critical wallet operations.

Integration Security: Exploitable vulnerabilities in NoirWallet's own SDK, wallet adapters, and cross-chain or Confidential Account integration logic.

Program Scope

This program covers security vulnerabilities within NoirWallet's own software and the components explicitly listed as in scope.

Only officially supported releases and Beta versions explicitly included in the program scope are eligible. Experimental branches and unsupported versions are excluded unless otherwise specified.

Vulnerabilities originating exclusively from third-party smart contracts, DeFi protocols, bridges, RPC providers, or external services are excluded unless a security flaw in NoirWallet's own implementation or integration code directly creates an exploitable vulnerability.

All reports are subject to the detailed scope, eligibility, testing, and reward rules defined in this program.

2.1 In-Scope Components

Component	Repository / Location	Coverage
Chrome Extension	NoirWallet/noir-wallet	Wallet frontend, Background, Offscreen, local storage, key management, transaction authorization, and security boundaries.
Rust/WASM Core	NoirWallet/zcash-wallet-wasm	Zcash accounts, key operations, transaction construction, signing, synchronization, and balance management.
dApp SDK	noir-wallet/packages/sdk	Wallet connectivity, provider communication, permission management, and transaction requests.
Zcash Wallet Adapter	NoirWallet/zcash-wallet-adapter	Wallet connectivity, WalletConnect integration, messaging, authorization, and security-sensitive transaction handling.
Legacy dApp SDK	NoirWallet/noir-wallet-sdk	Archived repository; only explicitly listed, supported published versions are eligible.
WASM Integration	wasm-package.lock.json and related integration code	WASM package integrity, loading, verification, and security boundaries in official wallet builds.

Version Eligibility

Eligible targets include:

• Officially supported production releases of NoirWallet.
• Official Beta builds explicitly listed as in scope by NoirWallet.
• Supported published SDK and Adapter versions explicitly included in the program.

Experimental branches, unpublished development builds, unsupported historical versions, websites, backend infrastructure, and components not explicitly listed are excluded by default.

Eligibility is determined based on the supported versions and authorized targets listed in the program at the time of a valid report's initial submission.

Scope Limitations

Listing a repository as an eligible target does not automatically include every module, dependency, or third-party integration within that repository.

Only vulnerabilities affecting NoirWallet's own implementation, security boundaries, authorization mechanisms, or security-sensitive integration code are eligible.

Vulnerabilities originating exclusively from third-party protocols, smart contracts, DeFi services, or external infrastructure are excluded.

A vulnerability identified in publicly available source code does not automatically qualify for a reward. Researchers must provide sufficient technical evidence that the vulnerability affects an eligible official wallet build or a supported published SDK or Adapter version.

Actual exploitation against production users or assets is not required.

2.2 Eligible Vulnerability Categories

A. Wallet & Private Key Security

• Unauthorized access to seed phrases, private keys, viewing keys, or other sensitive key material.
• Exploitable weaknesses in local encryption, wallet locking, or key access controls.
• Malicious websites bypassing wallet security boundaries.
• Unintended disclosure of sensitive credentials caused by wallet implementation flaws.

B. Transaction & Signing Security

• Transaction signing or broadcasting without valid user authorization.
• Mismatches between user-confirmed transaction details and actual signed transactions.
• Exploitable signature replay, account confusion, or authorization bypass.
• Security flaws in WASM transaction construction, signing, or PCZT processing that could compromise user assets.
• Exploitable transaction validation failures resulting in unauthorized asset transfers or unintended transaction execution.

C. Extension, SDK & dApp Security

• Bypassing dApp connection or transaction authorization.
• Exploitable privilege escalation across Content Script, Background, Offscreen, or other extension components.
• Unauthorized access to accounts or sensitive wallet information across website origins.
• Exploitable script injection, code execution, or message origin validation vulnerabilities.
• Security vulnerabilities in SDK, Wallet Adapter, or WalletConnect integration that bypass wallet authorization or compromise transaction integrity.

D. Privacy & Zcash Security

• Unauthorized disclosure of protected Shielded Transaction information.
• Unauthorized access to viewing keys, sensitive transaction history, private memos, or non-public wallet information.
• Implementation flaws that expose sensitive information intended to remain confidential.
• Security vulnerabilities in Zcash synchronization, balance management, or Note/UTXO handling that create a demonstrable risk to user assets.

Ordinary synchronization failures, balance display inconsistencies, or performance issues without demonstrable security impact are not eligible.

Information publicly available on a blockchain, or network metadata not intended to be protected by NoirWallet, does not automatically constitute a privacy vulnerability.

However, implementation flaws that expose protected wallet information or bypass an established privacy security boundary may qualify.

E. Cross-Chain & Confidential Integration

For officially supported versions explicitly included in scope:

• Incorrect wallet-side transaction construction resulting in unintended destination addresses, assets, or networks.
• Unauthorized access to or manipulation of Confidential Account ownership, permissions, or destination addresses.
• Discrepancies between user-confirmed transactions and actual signed or submitted transaction parameters.
• Exploitable vulnerabilities in wallet-side validation of third-party quotes, deposit addresses, or refund addresses.
• Security vulnerabilities in NoirWallet's own cross-chain or Confidential integration logic that result in unauthorized transactions or direct risks to user assets.

Only vulnerabilities within NoirWallet's own implementation, validation, or authorization mechanisms are eligible.

Vulnerabilities originating exclusively from third-party bridges, Confidential protocols, DEXs, lending protocols, or other external services are excluded unless NoirWallet's own implementation introduces an independently exploitable security flaw.

NoirWallet offers rewards based on vulnerability severity, demonstrated security impact, and exploitability.

Severity	Reward Range	Typical Impact
Critical	2,000–5,000 USD	Private key exposure, unauthorized asset transfers, or severe wallet security boundary compromise
High	500–2,000 USD	Significant sensitive data exposure, critical authorization bypass, or substantial risk to user assets
Medium	100–500 USD	Exploitable permission bypass or sensitive information disclosure with limited impact
Low	100 USD	Demonstrable security vulnerabilities with relatively minor impact

All rewards are denominated in USDC.

The reward amount is determined within the applicable severity range based on demonstrated security impact, exploitability, required attack conditions, and the scope of affected users or assets.

The maximum reward for each severity level is not guaranteed.

3.1 Critical — 2,000–5,000 USD

Examples include:

• An attacker can extract a user's seed phrase or private key through a vulnerability in NoirWallet under a supported browser environment.
• An attacker can transfer user assets without valid authorization.
• A transaction signing vulnerability allows funds to be redirected to an address not approved by the user.
• A severe and broadly exploitable flaw in key management or transaction signing.

Critical severity generally applies to vulnerabilities that directly compromise user assets, private keys, or fundamental wallet security boundaries.

The final reward depends on the demonstrated impact, exploitability, attack prerequisites, and affected user scope.

3.2 High — 500–2,000 USD

Examples include:

• Bypassing critical transaction authorization under specific conditions.
• Unauthorized disclosure of a viewing key with significant privacy implications.
• Exploitable signature authorization vulnerabilities involving incorrect accounts, networks, or permission boundaries.
• Security control failures that expose users to substantial asset-related risks.

High severity generally applies to significant security vulnerabilities with meaningful impact but more restrictive exploitation conditions or a narrower scope than typical Critical findings.

Vulnerabilities demonstrating Critical-level impact may be classified as Critical regardless of whether user interaction or specific prerequisites are required.

3.3 Medium — 100–500 USD

Examples include:

• Limited but exploitable account permission or origin isolation bypass.
• Unauthorized access to protected wallet transaction or account information.
• Transaction validation, signing, or message-handling vulnerabilities with restricted security impact.

Medium severity generally applies to exploitable security weaknesses with limited impact that do not directly compromise private keys or enable unauthorized asset transfers.

3.4 Low — 100 USD

Examples include:

• Low-impact exposure of sensitive metadata.
• Minor but demonstrably exploitable permission control vulnerabilities.
• Other security issues with limited impact and no direct risk of significant asset loss.

Low severity findings must demonstrate a genuine security vulnerability rather than a purely theoretical concern, functional defect, or general best-practice recommendation.

3.5 Severity Assessment

Severity is determined based on:

• Demonstrated security impact.
• Exploitability and attack complexity.
• Required prerequisites and user interaction.
• Scope and scale of affected users or assets.
• Potential impact on private keys, user funds, transaction integrity, or protected privacy information.

CVSS may be used as a reference but does not solely determine severity or reward eligibility.

Actual financial loss is not required. Researchers may demonstrate the impact through a safe proof of concept, a controlled testing environment, or rigorous technical evidence.

The severity assigned to an in-scope target represents the maximum potential vulnerability severity for that target. It does not determine the severity or reward of individual reports. Each finding is assessed independently based on its demonstrated security impact and exploitability.

Reward Determination

• Each valid vulnerability is assigned a severity level based on its demonstrated security impact and exploitability.
• Rewards are determined within the published range for the assigned severity.
• The maximum reward is reserved for findings demonstrating particularly severe impact, broad exploitability, or significant risks to user assets.
• A valid finding does not automatically qualify for the maximum reward within its severity range.
• Final severity classification and reward amounts are determined by NoirWallet in coordination with HackenProof, subject to the program rules and applicable platform policies.
• Confirmed vulnerabilities will be assessed according to their technical impact rather than downgraded solely to accommodate budget limitations.

Additional Rules

• Multiple findings with the same root cause are generally treated as a single vulnerability.
• Multiple steps in one exploit chain that do not independently create a security impact are generally assessed as one finding at the highest demonstrated impact.
• Independently exploitable vulnerabilities with distinct root causes may qualify for separate rewards.
• Previously fixed vulnerabilities that are reintroduced may qualify if they constitute a new, independently valid report.
• Previously known or internally confirmed vulnerabilities are subject to the Known Issues and Duplicate Reports policies defined in this program.
• Reward eligibility and amounts are subject to the published program scope, testing requirements, and disclosure policies.

The following findings are generally not eligible for rewards:

1. UI defects, display issues, performance problems, and ordinary functional bugs without demonstrable security impact.

2. Routine balance synchronization failures, incorrect balance displays, or transaction history inconsistencies that do not create demonstrable asset security risks or expose protected information.

3. Transactions explicitly approved by users after accurate disclosure of the transaction details, provided no wallet security control, transaction validation mechanism, or authorization boundary was bypassed.

4. Attacks that require a fully compromised device, operating system-level malware, a malicious browser extension with higher privileges, or unauthorized physical access, unless an independently exploitable vulnerability within NoirWallet is demonstrated.

5. Vulnerabilities solely affecting browsers, operating systems, or third-party software without demonstrating an independently exploitable security flaw within NoirWallet.

6. Outdated dependency versions, missing security headers, configuration recommendations, or general security best-practice observations without demonstrated exploitability and security impact.

7. Theoretical issues without sufficient technical evidence, unverified automated scanner findings, or AI-generated reports that lack reproducible evidence of a genuine security vulnerability.

8. DDoS attacks, service disruption, request flooding, social engineering, phishing campaigns, or credential harvesting targeting employees or users. Security vulnerabilities in NoirWallet that can be exploited through malicious websites may still qualify if they bypass wallet security boundaries.

9. Vulnerabilities originating exclusively from third-party bridges, RPC providers, Intents, Confidential protocols, DEXs, lending protocols, smart contracts, or other external services, without an independently exploitable flaw in NoirWallet's own implementation.

10. Publicly available blockchain addresses, transactions, balances, or other information that is not intended to be confidential, unless a NoirWallet implementation flaw exposes additional protected information.

11. Vulnerabilities that can only be triggered by modifying the researcher's own wallet source code, altering local security controls, or introducing malicious modifications that cannot affect an official supported NoirWallet release.

12. Vulnerabilities affecting unsupported historical releases, experimental branches, unpublished development builds, websites, backend infrastructure, or other components not explicitly included in the program scope.

13. Previously disclosed, internally confirmed, independently audited, or previously reported vulnerabilities with the same root cause and previously documented security impact.

Exceptions

Third-Party Integration Vulnerabilities

A vulnerability involving a third-party dependency, protocol, or service may qualify if NoirWallet's own implementation, validation, or integration logic introduces an independently exploitable security weakness that directly affects users of an eligible official release.

The existence of a vulnerability in a third-party component alone does not establish reward eligibility.

Previously Known Vulnerabilities

A previously known issue may qualify for reconsideration if the researcher demonstrates a materially distinct, independently exploitable vulnerability or a previously unidentified, substantially more severe security impact.

A new reproduction method or attack variation involving the same root cause and substantially the same security impact does not independently qualify for an additional reward.

For vulnerabilities classified as previously known or duplicate, NoirWallet must be able to provide verifiable evidence that the same root cause and security impact were documented before the report's initial submission.

Such evidence may be reviewed by HackenProof without publicly disclosing confidential internal security records.

Controlled Security Research

Vulnerabilities demonstrated using local testing, controlled environments, or researcher-owned accounts and assets may qualify if the researcher establishes a credible and reproducible security impact on an eligible official release.

Actual exploitation against production users or real user assets is not required.

4.1 Known Issues

The June 2026 BlockSec audit of the Zcash Rust/WASM component identified two Low Severity findings that remain unresolved:

• Finding #10: Incomplete error handling for certain transaction broadcast failures.
• Finding #12: Incomplete balance synchronization when an incorrect historical scanning start date is selected during wallet recovery.

The previously documented behavior, root causes, and security impacts of these findings are not eligible for duplicate rewards.

However, independently exploitable vulnerabilities with distinct root causes, or newly demonstrated security impacts that are substantially more severe than the original findings, may still qualify for evaluation.

The exclusion of these known issues does not automatically exclude unrelated vulnerabilities affecting the same components.

Audit Report:

BlockSec — NoirWallet Zcash Wallet WASM Security Audit (June 2026)

Security researchers are encouraged to conduct source code reviews, static analysis, local testing, fuzzing, and other responsible security assessments.

Testing must be conducted using accounts, wallets, credentials, and assets controlled by the researcher, preferably in isolated local environments or explicitly authorized test networks.

Controlled testing using researcher-owned wallets and assets on officially supported production releases is permitted, provided that such testing does not compromise other users, disrupt services, or involve unauthorized security testing of production infrastructure or third-party systems.

Automated testing, fuzzing, and vulnerability scanning must be performed in isolated environments. High-volume or disruptive testing against production RPC endpoints, synchronization services, or other infrastructure is prohibited without explicit authorization.

Researchers must not:

1. Transfer, steal, destroy, or otherwise compromise assets belonging to other users.

2. Intentionally access, retain, disclose, or misuse real users' private keys, seed phrases, viewing keys, or other sensitive information.

3. Conduct unauthorized security testing against production infrastructure, third-party services, or systems outside the explicitly defined program scope.

4. Disrupt production services, degrade infrastructure availability, or interfere with normal wallet operations.

5. Conduct social engineering, phishing, credential harvesting, or other attacks targeting employees or users.

6. Modify or compromise other users' wallets, accounts, devices, or transactions.

7. Publicly disclose unresolved vulnerabilities, exploit code, or sensitive proof-of-concept materials without authorization in accordance with the program's coordinated disclosure policy.

8. Exploit vulnerabilities for personal gain or purposes unrelated to responsible security research.

Researchers should use the minimum testing necessary to demonstrate a vulnerability and avoid unnecessary exposure of sensitive information.

If testing unintentionally exposes real user data or creates an immediate risk to user assets, researchers must stop the affected testing activity, avoid further access or disclosure, and report the issue privately through HackenProof as soon as possible.

Researchers are not required to exploit vulnerabilities against real users or cause actual financial loss to demonstrate security impact. Safe proofs of concept, controlled testing, and rigorous technical evidence are acceptable.

5.1 Safe Harbor

NoirWallet supports good-faith security research conducted in accordance with this program and within its explicitly authorized scope.

NoirWallet will not initiate legal action against researchers solely for security research activities that comply with the published program rules.

Researchers must act in good faith, avoid unnecessary harm, respect user privacy, and promptly report discovered vulnerabilities through HackenProof.

This authorization applies only to software, systems, and activities that NoirWallet has the authority to authorize.

It does not extend to third-party infrastructure, services, smart contracts, assets, or systems outside the program scope.

This Safe Harbor does not authorize unlawful activities or exempt researchers from applicable laws and regulations.

Activities that violate the program's scope, testing restrictions, or responsible disclosure requirements are not covered by this Safe Harbor.

All Bug Bounty reports must be submitted privately through NoirWallet's official HackenProof program.

Reports must provide sufficient technical information to identify, reproduce, and assess the reported vulnerability.

Reports should include the following information:

Field	Requirement
Title	Clear and descriptive vulnerability title
Affected Component	Extension, Rust/WASM Core, SDK, Wallet Adapter, or another explicitly in-scope component
Version	Affected wallet version, SDK version, source commit hash, or build information
Description	Technical explanation of the vulnerability, its root cause where identifiable, and conditions required for exploitation
Steps to Reproduce	Clear reproduction steps using a controlled testing environment
Proof of Concept	Minimal test code, technical evidence, relevant logs, screenshots, recordings, or other sufficient supporting evidence
Security Impact	Demonstrable or technically substantiated impact on user assets, private keys, privacy, transaction integrity, or authorization
Attack Prerequisites	Required permissions, user interactions, environmental conditions, or other assumptions necessary for exploitation

6.1 Proof of Concept Requirements

Researchers should provide minimal, reproducible proofs of concept using researcher-controlled accounts, wallets, credentials, and assets.

A report must establish a credible security impact on an eligible official release or supported published component.

Vulnerabilities demonstrated only through modifications to the researcher's own source code, without a verifiable impact on an eligible official release, are not eligible.

Actual exploitation against production users or assets is not required.

For complex cryptographic vulnerabilities, rigorous technical analysis, formal reasoning, or other sufficient technical evidence may be accepted without requiring researchers to demonstrate an actual transfer of funds.

If a complete proof of concept would create unnecessary risk to users or production systems, researchers should provide the safest available evidence and explain any testing limitations.

6.2 Sensitive Information

Reports must not contain:

• Real users' seed phrases, private keys, viewing keys, or other sensitive credentials.
• Personal information or confidential data belonging to other users.
• Unredacted sensitive information obtained from systems or accounts outside the researcher's control.

Researchers should use disposable test credentials and redact sensitive information from screenshots, logs, and other supporting materials.

If sensitive user information is unintentionally encountered, researchers must stop further access, avoid unnecessary retention or disclosure, and notify NoirWallet privately through HackenProof.

6.3 Report Validation

NoirWallet may request additional technical evidence, clarification, or reproduction details when necessary to validate a report.

Reports that lack sufficient technical evidence may require additional investigation before eligibility or severity can be determined.

Automated scanner results and AI-assisted findings are acceptable only when supported by sufficient technical evidence of a genuine, exploitable security vulnerability.

Researchers should submit distinct vulnerabilities separately where practical. Findings sharing the same underlying root cause may be treated as duplicates or consolidated in accordance with the program's reward and duplicate-report policies.

The final assessment of report validity, severity, and reward eligibility will follow the published program rules and applicable HackenProof policies.

NoirWallet proposes the following response, assessment, payment, and resolution timelines.

Stage	SLA
First Response	10 Business Days
Triage Time	30 Business Days
Reward Time	90 Business Days
Resolution Time	180 Business Days

These are proposed timelines and are subject to HackenProof's approval and configuration.

Business-day definitions, SLA starting points, pauses, and extensions will follow the applicable HackenProof platform rules.

7.1 First Response

NoirWallet aims to acknowledge submitted reports within 10 business days.

An initial response confirms that the report has entered the review process. It does not imply that the vulnerability has been reproduced, accepted, or assigned a final severity rating.

7.2 Triage Time

The target initial triage period is 30 business days.

Vulnerabilities involving Rust/WASM, cryptography, transaction signing, or complex cross-chain interactions may require additional investigation and validation.

If further evidence is required, NoirWallet may request clarification through HackenProof. Any applicable SLA adjustments will follow platform rules.

7.3 Reward Time

NoirWallet proposes a reward payment SLA of 90 business days, subject to the timing rules approved by HackenProof.

Reward payment does not depend on the final completion of the security fix.

Cases involving identity verification, payment compliance, or other exceptional circumstances will be handled according to HackenProof policies, with appropriate status updates provided to the researcher.

7.4 Resolution Time

The proposed resolution period is 180 business days.

Complex vulnerabilities may require updates to WASM components, cryptographic validation, frontend changes, compatibility testing, or Chrome Extension release approval.

If a vulnerability cannot reasonably be resolved within the target timeframe, NoirWallet will coordinate with HackenProof regarding progress, mitigation measures, and any permitted extension.

Critical vulnerabilities presenting an immediate and credible risk to users will be prioritized for risk assessment and appropriate mitigation. NoirWallet will not defer necessary protective measures until the standard resolution deadline.

8.1 Eligibility

To qualify for a reward, a researcher must:

• Be the first to submit a valid report for the vulnerability.
• Provide sufficient technical evidence of its security impact.
• Comply with all program scope, testing, and responsible disclosure requirements.
• Meet applicable HackenProof identity verification and payment compliance requirements.

Current NoirWallet employees and contractors are not eligible for bounty rewards during their engagement with NoirWallet.

Former employees, contractors, and security auditors are not eligible for rewards for vulnerabilities discovered or learned through their professional responsibilities for NoirWallet.

Reports involving previously known vulnerabilities are subject to the Known Issues and Duplicate Reports policies defined in this program.

8.2 Duplicate Reports

Only the first valid report for a particular vulnerability is eligible for a reward.

Reports involving the same underlying root cause and substantially the same security impact are generally considered duplicates and are not rewarded separately.

Multiple independently exploitable vulnerabilities with distinct root causes may qualify for separate rewards, even if they affect the same component.

Previously fixed vulnerabilities that are subsequently reintroduced may qualify for reconsideration in accordance with the reward policies defined in Section 3.

Vulnerabilities classified as previously known or duplicate must be supported by verifiable evidence of an earlier valid report, audit finding, or internal security record.

NoirWallet may provide such evidence privately to HackenProof without publicly disclosing confidential security information.

Submission order, report validity, and duplicate status will be determined based on HackenProof records and supporting technical evidence.

8.3 Coordinated Disclosure

All vulnerabilities submitted under this program are subject to coordinated disclosure.

Researchers must not publicly disclose vulnerability details, exploit code, or proof-of-concept materials without authorization through HackenProof or as otherwise permitted by its applicable disclosure policy.

This restriction includes publication on social media, GitHub, technical forums, and other public platforms.

NoirWallet will coordinate with researchers through HackenProof to establish an appropriate disclosure timeline based on vulnerability severity, remediation progress, and user safety.

Public disclosure will follow HackenProof's applicable disclosure policies and any mutually agreed disclosure arrangements.

For vulnerabilities presenting an immediate risk to users, NoirWallet may take necessary protective measures and issue appropriate security notices without disclosing unnecessary technical details that could facilitate exploitation.

8.4 Program Changes

NoirWallet reserves the right to modify the program's scope, reward structure, eligibility requirements, and policies for future submissions.

Program changes apply only to reports initially submitted on or after the effective date of the changes.

Reports submitted before that date will be evaluated under the program rules in effect at the time of their initial submission, regardless of when validation is completed.

Only reports determined to be valid and eligible under those applicable rules will qualify for rewards.

The maximum individual reward is 5,000 USD, as defined in the published reward structure. The program does not establish a publicly disclosed aggregate reward cap.

NoirWallet may temporarily pause or terminate the program in accordance with HackenProof's applicable platform policies.

Any suspension, termination, or material program changes will be communicated through HackenProof.

Reports submitted before the effective date of a suspension or termination will continue to be evaluated under the applicable program rules.

Eligible rewards for such reports will remain subject to the published reward structure, program requirements, and applicable HackenProof payment policies.

Item	Details
Project	NoirWallet
Platform	HackenProof
Project Type	Non-Custodial Privacy-Focused Cryptocurrency Wallet
Security Scope	Chrome Extension, Rust/WASM Core, dApp SDK, Zcash Wallet Adapter, WASM Integration
Maximum Reward	$5,000 USD
Critical	$2,000–$5,000
High	$500–$2,000
Medium	$100–$500
Low	$100
First Response	10 Business Days
Triage	30 Business Days
Reward	90 Business Days
Resolution	180 Business Days
SLA Conditions	Subject to HackenProof approval and applicable platform policies
Testing	Source Code Review, Static Analysis, Local Testing, Fuzzing, Authorized Test Environments, Controlled Testing with Researcher-Owned Wallets
Disclosure	Coordinated Disclosure in accordance with HackenProof policies

NoirWallet is committed to protecting users' assets, private keys, transaction integrity, and financial privacy. We appreciate the contributions of the security research community in helping us build a more secure non-custodial wallet.