Leather is a self-custodial wallet for Bitcoin and Stacks, available as a browser extension, mobile app, and web app. It lets users hold and manage BTC, STX, and related assets, sign transactions, and connect to dApps across the Bitcoin and Stacks ecosystems.
Triaged by Immunefi
Step-by-step PoC Required
KYC required
Arbitration enabled
Rewards
Rewards by Threat Level
Primacy of Impact vs Primacy of Rules
Primacy of Impact means that the impact is prioritized rather than a specific asset. This encourages security researchers to report on all bugs with an in-scope impact, even if the affected assets are not in scope.
For more information, please see Best Practices: Primacy of Impact.
When submitting a report on Immunefi's dashboard, the security researcher should select the Primacy of Impact asset placeholder. If the team behind this project has multiple programs, those other programs are not covered under Primacy of Impact for this program. Instead, check if those other projects have a bug bounty program on Immunefi.
If the project has any testnet and/or mock files, those will not be covered under Primacy of Impact.
All other impacts are considered under the Primacy of Rules, which means that they are bound by the terms and conditions set within this program.
Rewards are distributed according to the impact of the vulnerability based on the Immunefi Vulnerability Severity Classification System V2.3. This is a simplified 5-level scale, encompassing everything from consequence of exploitation to privilege required to likelihood of a successful exploit. If there is any discrepancy with the classification in the Impacts in Scope section, the classification in the Impacts in Scope section will hold true.
Websites and Applications
- Critical: USD 3000 up to USD 5000
- High: USD 2000 up to USD 3000
- Medium: USD 1000 up to USD 2000
- Low: Flat USD 1000
- Informational: Only in exceptional circumstances and solely at our discretion
Primacy of Impact: where a vulnerability in an in-scope Leather asset can be chained to a direct loss of user funds on Bitcoin or Stacks, the report escalates to the corresponding Blockchain reward tier of the Stacks program rather than being capped at the Websites and Applications tier. Escalation requires a complete, demonstrated exploit chain from the initial vulnerability through to the fund-loss impact, with each step proven by a working proof of concept.
We agree to:
- Respond meaningfully to all reported issues in a timely manner.
- Not pursue legal action against or "counter-hack" any researchers acting in good faith and abiding by this program's rules.
- Consider well-argued, evidence-based reports on their merits.
You must:
- Undergo KYC before any reward is paid.
- Not be based or test from an OFAC-sanctioned country or region, or be a sanctioned individual or organization, as defined here: https://ofac.treasury.gov/sanctions-programs-and-country-information
- Report all bugs using this template. All fields are required unless otherwise marked.
- Executive summary of issue:
- Finding details:
- Affected in-scope asset and the published build or version tested:
- Repository, file, and line of code where relevant:
- Steps to replicate (against testnet or a local build):
- Impact of finding (short term):
- Impact of finding (long term):
- Mitigation suggestions (short term):
- Mitigation suggestions (long term):
- (Optional) Suggested patch:
- (Optional) Any useful links or resources:
- (Optional) Do you want a shout-out on our Security Wall of Fame?
- Test only against testnet or a local build. Testing against mainnet with real user funds is forbidden.
A proof-of-concept is required for all submissions. Please include it in the corresponding form field.
Payouts are handled by the Stacks Endowment team directly and are denominated in USD. However, payments will be made in the USD equivalent in the Stacks token (STX).
Program Overview
This program covers the Leather wallet applications and their supporting code. We prioritizes the following attack vectors:
- Extraction or leakage of a user's secret recovery phrase or private keys
- Unauthorized transaction signing, or signing without clear and accurate user consent
- Manipulation of transaction details (recipient, amount, asset) between what the user approves and what is broadcast
- Bypass of wallet lock, authentication, or approval flows
- Compromise of the dApp connection or provider layer leading to any of the above
Audits
Completed audit reports for this project can be found at the links below.
Any unpatched or unresolved vulnerabilities disclosed in these reports are not eligible for rewards.
Known Issues
KYC required
The submission of KYC information is a requirement for payout processing.
Proof of Concept
Proof of concept is always required for all severities.
Responsible Publication
Category 3: Approval Required
Prohibited Activities
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty
- Any other actions prohibited by the Immunefi Rules
Feasibility Limitations
The project may be receiving reports that are valid (the bug and attack vector are real) and cite assets and impacts that are in scope, but there may be obstacles or barriers to executing the attack in the real world. In other words, there is a question about how feasible the attack really is. Conversely, there may also be mitigation measures that projects can take to prevent the impact of the bug, which are not feasible or would require unconventional action and hence, should not be used as reasons for downgrading a bug's severity.
Therefore, Immunefi has developed a set of feasibility limitation standards which by default states what security researchers, as well as projects, can or cannot cite when reviewing a bug report.