A Note on Recent Security Discussions

Verification standards, release deployment, and how we will improve

Recent discussions around UniSat Wallet’s security review, code changes, version deployment, and disclosure process have raised serious and reasonable questions from the community.

These questions should not be answered only with general assurances. For a self-custody wallet, users deserve to know: which facts have been confirmed and which claims have not been reproduced; which versions include improvements and whether users have actually received them; what a review covered and when reports will be disclosed; and how we will avoid unnecessary gaps between a security-related change and users being meaningfully protected.

This article is not intended to argue point by point with every comment, nor to discuss attribution, compensation, or communications involving individual researchers. Our goal is to state directly what can currently be confirmed, what shortcomings we should acknowledge, and what improvements we will implement next.

A few direct answers first

1. Does the latest stable version of UniSat Wallet include the recent security updates?

Yes. Extension wallet v1.7.19 includes the security enhancements described in our recent public update. We recommend that all extension-wallet users update to v1.7.19 or a later version through official channels.

2. Have earlier versions been proven to contain a complete attack path for “remote, silent theft” or “auto-signing”?

No. To date, we have not independently reproduced an end-to-end remote, silent-theft or auto-signing attack path corresponding to those claims. Publicly available materials also do not demonstrate that any historical user loss resulted from such issues.

This does not mean that earlier versions and the latest version provide exactly the same level of protection. Earlier versions do not include this set of additional defensive measures, which is why upgrading remains necessary and worthwhile.

3. Has any user loss been confirmed as resulting from issues raised in recent security reports?

No. Based on the information currently available to us, we have not identified any user-fund loss that can be attributed to issues raised through recent security-review or vulnerability-reporting channels.

We do occasionally receive support requests involving mixed-protocol UTXOs, where particular assets may have been unintentionally spent or burned through user operations. These cases are handled individually according to their circumstances, but they should not be conflated with the security claims currently under discussion. When handling UTXOs that contain multiple protocol assets, users should read wallet warnings carefully and, where possible, use UTXO-management tools to separate those assets before transacting.

4. Were the recent changes “vulnerability fixes” or “security enhancements”?

The more accurate description is that this work primarily consists of security enhancements and defense-in-depth improvements, including vault protection, trust boundaries, extension messaging, permission controls, and sensitive-data lifecycle management.

Some of these changes reduce potential attack surface. However, it is not supported by the currently verifiable evidence to infer directly from “we strengthened defenses” that a critical vulnerability existed.

5. Does updating mean users no longer need to worry about private-key or asset security?

No. Updating is important, but no software update can eliminate risks arising from device compromise, malicious extensions, malware, phishing websites, or seed-phrase exposure.

In particular, where an attacker already has complete control over a user’s device, browser environment, or input and output, the extraction of sensitive information or inducement of a transaction does not automatically demonstrate a remotely exploitable application-layer vulnerability in the wallet itself. We will continue strengthening defenses for such scenarios, but users must also maintain basic device and operational-security practices.

I. Versions, Deployment, and Existing-User Migration

The questions raised by the community have been specific:

Which stable versions actually contain the fixes?
Which versions are still affected?
What percentage of users are currently running a fixed version?
Were migrations for existing users validated, not just fresh installs?
Was a fixed stable release available before the security-relevant diffs became public?

These are fair questions. Security work cannot stop at changes in a code repository: release sequencing, store review, automatic updates, migration of existing data, and user notification are all part of security.

Version Scope

At present, v1.7.19 is the stable release that includes the recent security enhancements. We recommend that all users update to this version or a later version.

We do not describe earlier versions as versions proven to contain a specific critical exploit, because no end-to-end attack chain has been independently reproduced, and we have not identified any user-fund loss attributable to vulnerabilities of the type discussed in recent security reports.

However, earlier versions do not include the same set of security enhancements. Out of caution and as part of continuous improvement, we recommend updating rather than interpreting “remote theft has not been proven” as “an update is unnecessary.”

Existing Wallets and Migration Validation

Security changes must work not only in fresh-install environments. We have validated upgrade paths for existing wallets and local data, including existing-vault unlocking, compatible data handling, critical upgrade paths, and regression testing.

For compatible legacy vaults, strengthened derivation or protection mechanisms will apply when the relevant conditions are met. In a future technical note, we will publish the scope of migration coverage, the scenarios that have been validated, and any limitations users should be aware of, rather than offering only a general statement that testing has been completed.

Deployment and the Patch Gap

We also accept an important process lesson: when security-relevant code changes are public but a stable release has not yet reached all users, a patch gap can arise.

The relevant changes became public before the stable release had reached all users. We recognize that this created an avoidable patch-gap risk, and we will improve release sequencing and disclosure practices accordingly.

We will not assume that all users have upgraded merely because Chrome Web Store automatic updates typically reach most users within a few days. Unless we have reliable and interpretable coverage data, we will not provide a precise percentage for how many users are running the newer version.

Going forward, our default process for confirmed issues that may affect user security will be:

1. Receive reports privately and confirm reproducibility;
2. Assess the affected scope and realistic attack conditions;
3. Complete remediation, regression testing, and migration validation;
4. Release and deploy through official channels first;
5. Conduct coordinated disclosure after users have received reasonable protection.

This does not mean that all code changes must remain private indefinitely. Transparency is important in open-source projects, but the disclosure sequence for security-relevant changes must take users’ real deployment status into account.

II. Reports, Review Scope, and Public Disclosure

Other questions have focused on the verifiability of review work:

Are the audit reports, their scope, and the audited commit hashes publicly available? If not, why not?
Is there a public disclosure deadline, with a date attached?

First, it is important to clarify that not all security input received by an open-source project is of the same nature.

It may include formally commissioned independent audits, vulnerability reports submitted by researchers, internal code review, community feedback, and automated or AI-assisted analysis. Their scope, depth of validation, responsibility boundaries, and disclosure conditions differ. We have not previously distinguished these categories clearly enough, which could lead people to interpret “we received a security report” or “we completed code hardening” as a completed independent audit with a defined scope.

Formal Audits and Public Information

For each formally completed independent audit, we will publish or link to the following information:

• The auditor;
• Review date;
• Review scope;
• Relevant version or commit hash;
• Findings and remediation status;
• The full report, or a report summary that can be made public.

Not every full report is suitable for immediate publication once an issue has been confirmed. A report may contain directly reusable exploit details, or be subject to coordinated-disclosure arrangements and auditor terms. But where part of a report cannot yet be made public, we should at least explain its scope, affected versions, remediation status, the reason it is not yet public, and the expected disclosure date.

Disclosure Timeline

We plan to adopt a clearer default standard:

For confirmed security issues that have been remediated and deployed, our target is to publish a disclosure summary within 90 days of the release of the remediation.

If this cannot be done within that period because user deployment remains insufficient, third-party coordination is required, or another genuine security reason applies, we will explain the reason for the delay and provide a new target date rather than leaving the matter indefinitely unclear.

Mobile applications should also be treated as a separate review scope. Discussions concerning the browser extension should not be incorrectly extrapolated as conclusions of an equivalent review of the iOS or Android applications.

The Role of AI-Assisted Analysis

Modern AI models can help developers and researchers identify potential risks in open-source code, and we use such tools in our own internal review processes. Community members are also welcome to analyze public repositories independently and submit findings through responsible channels.

However, AI scanning is not a substitute for an independent audit, nor for complete vulnerability validation. A useful security report should help establish whether an issue actually exists, its triggering conditions, its real-world impact, whether it can be reproduced reliably, and how it can be remediated without increasing risk to users.

If a submitted finding does not overlap with known issues and is validated as a meaningful risk, it represents a real contribution to open-source software and user security. We will assess it based on impact, reproducibility, and report quality, and provide an appropriate bug bounty where applicable.

III. Historical Code Records

Some community members have also noticed that, following repository migration, portions of the earlier development history are no longer straightforward to browse in the current official repository.

Existing forks preserve a meaningful portion of the earlier commit history, but that is not a sufficient answer. Third-party forks cannot replace a stable, clear, project-maintained official historical archive; users and researchers should not be asked to reconstruct project history themselves from hundreds of forks.

Where we consider it appropriate, we may provide an official read-only historical archive and clarify:

• The relationship between repositories before and after the migration;
• The correspondence between historical tags, releases, and current versions;
• Which historical commits can be browsed directly;
• The specific reasons if any content cannot be republished in its original form.

If certain historical content first requires credential, privacy, or security review, we will state that limitation clearly rather than leaving the community to infer it.

Conclusion: Transparency Does Not Mean Overstatement, and Caution Must Not Become Evasion

Security discussions require transparency, but they also require evidence standards.

We should not dismiss serious claims that have not yet been reproduced. At the same time, defense-in-depth improvements, code refactoring, or scenarios in which an attacker already has complete control of a device should not be described as a confirmed remotely exploitable critical vulnerability. Either approach can mislead users.

Recent discussions have reminded us that security responsibility includes not only remediating code, but also clearly describing version scope, validating migrations for existing users, arranging an appropriate release sequence, explaining review coverage, and publishing sufficient information for community scrutiny at the right time.

We will improve our work according to these standards: take every valid report seriously, prioritize verification and user protection, avoid overstating uncertain conclusions, and not evade process shortcomings that have been clearly identified.

Lorenzo
August 2026

References

• Recent UniSat Wallet security announcement

E-2608B (Lorenzo’s Library)
Creative Commons BY-NC-ND 4.0