Stack Wallet

This commit is a routine UI tweak for the desktop version of a feature called ShopinBit. It changes the width of a first-run information dialog, removes a Cancel button, adjusts spacing, and indents bullet points. There is nothing here related to security.

A single-line fix changes which app feature flag controls whether a 'Gift cards' button appears in the wallet screen. The old code checked a flag named 'shopinBit' but should have checked 'cakePay'. This is almost certainly a UI/functional bug rather than a security vulnerability, but it could affect whether users see or can access a third-party gift-card service integration.

This commit changes the Stack Wallet app so it keeps checking (polling) the status of certain ShopInBit support tickets even after they are in a final, unchangeable state. Previously, the app stopped polling once a ticket was closed, merged, or refunded. The change removes those stop conditions. On its own, this is a behavior change rather than a direct security flaw, but it could slightly increase network traffic, battery use, and the number of API calls made to the ShopInBit server. There is no evidence in the commit that this fixes a security vulnerability or that it introduces one.

This commit flips a single setting in the Stack Wallet app so that its built-in ShopInBit shopping feature talks to a test/sandbox environment instead of the real production service. The change is explicitly marked with a TODO saying it must be set to false for production. Using sandbox mode in a production release could mean users see fake/test data, make payments that don't result in real orders, or interact with a less secure/test server. However, the diff alone does not prove this change was ever shipped to users, and the commit message only says it is reverting an earlier change that disabled the sandbox.

This commit changes a third-party shopping integration from 'sandbox' (test) mode to live mode. The developer left a note earlier saying it should be set to false in production. The change itself is a normal production toggle, but because it involves real money/purchases and secret API credentials, it is worth reviewing whether this was released safely and whether any test-only behavior or weaker security settings were carried over accidentally.

This commit changes the default Tezos blockchain server used by Stack Wallet from a public Tezos node to Stack Wallet's own node, and adjusts the API endpoint used to check the latest block height. There is no direct evidence in the commit of a security vulnerability, but running wallet traffic through a single party-controlled node and changing the data source for chain state can carry trust and reliability risks.

This commit simply hides the 'Masternodes' menu option for Firo wallets in both mobile and desktop versions of Stack Wallet. The underlying masternode management code is not removed or changed, only the user-facing button that opens it is commented out. The commit message says this is a temporary disablement 'until its fixed,' but gives no details about what is broken or whether it is security-related.

This commit tidies up the Firo masternode creation screen. It adds a button-lock so pressing 'Create Masternode' repeatedly doesn't fire multiple times, wraps long-running balance checks in loading spinners, and replaces several hand-built confirmation dialogs with a single reusable dialog widget. There is no obvious security vulnerability being fixed here; it reads as a routine UI polish and bug-fix change.

This commit adds a new third-party cryptocurrency exchange integration called LetsExchange to the Stack Wallet app. It is a feature addition, not a bug fix. The code introduces network calls to LetsExchange's API, handles user funds routing through that service, and embeds an affiliate/referral ID in transaction requests. There is no direct evidence in the commit of a vulnerability, but integrating a new financial service always carries security and trust risks that warrant review.

This commit simply swaps the default web address used to look up Fact0rn transactions in Stack Wallet. The old explorer (factexplorer.io) was reportedly not working, so the developer reverted to the official explorer.fact0rn.io. There is no code change that handles private keys, balances, or network connections differently. At most, users who click a transaction link may now land on a working website instead of a broken one.

This commit simply swaps the default server address used by the Stack Wallet app for the Fact0rn cryptocurrency from one Project Factor server (electrumx1) to another (electrumx2). It is a routine infrastructure update. There is no direct evidence in the commit that this fixes a security vulnerability, but changing default servers can be relevant to trust and availability.

This commit fixes a user-interface bug in the Salvium wallet. When the wallet tried to connect to a network node, the code that reports 'connected' or 'connection failed' was disabled by comment marks, so users saw 'Connecting...' forever even though the connection had already failed. The change simply re-enables those two status updates, making the sync status accurate. It is a reliability/usability fix, not a security vulnerability.

This change alters how a wallet feature called ShopInBit refreshes support-ticket details. Previously it fired three API calls at once; now it first checks ticket status and skips the other two calls if the server returns a 403 'permission denied' response. The stated goal is simply to reduce unnecessary network traffic. There is no direct evidence in the commit that this fixes a security vulnerability, but it does reduce the amount of ticket-related data the app requests when the user is no longer authorized to view a ticket.

This commit updates the wallet's integration with a third-party shopping service. The service's API now labels certain records as 'receipts', and the wallet now skips those records when refreshing ticket data. This appears to be a correctness or data-handling fix rather than a security vulnerability. There is no indication it fixes an exploit or protects user funds directly.

This commit fixes a data-handling bug in a car-research invoice payment screen. Previously, when the app polled the server for invoice status and discovered a newly created support ticket, it did not save that ticket to the local database. The patch adds logic to fetch the full ticket details from the server and store a minimal local record so the rest of the app can see and update it later. There is no indication this is a security vulnerability; it appears to be a functional bug fix.

This commit changes how a wallet app parses invoice data from a partner service. Previously, missing or malformed date/number fields were handled gracefully by returning null or skipping them. Now, those same missing or malformed fields will cause the parsing to crash with an exception. The commit title says this ungraceful failure is intentional. This is a defensive change: it makes the app fail loudly instead of silently accepting bad data, which can prevent subtle bugs or misuse. However, it is not a typical security patch and could in theory be abused if an attacker can feed malformed JSON to the app to trigger a crash (denial of service).

This commit removes an unused field called customerKey from a data structure used when the app talks to the ShopInBit service. There is no security fix here; it is a small cleanup that deletes dead code.

This commit removes a safety check and some explanatory comments from a Flutter screen that shows a fallback dialog when a car purchase ticket takes too long to appear. The removed 'mounted' check ensured the screen still existed before showing a dialog. On its own, this change does not create a security issue; it is a minor code-cleanup change that slightly increases the theoretical risk of a harmless UI crash if the screen is closed at exactly the wrong moment.

This commit fixes a UI timing bug in a cryptocurrency wallet's car-research payment flow. Previously, the app could mark the payment as 'complete' and try to open the order details before the backend ticket actually existed, which could briefly show the wrong screen or a fallback. Now it waits until the real ticket ID is available before marking the flow complete. There is no direct evidence this is a security vulnerability.

This commit fixes a UI state bug in the Stack Wallet app where leftover 'OP_RETURN' data (extra information sometimes attached to a cryptocurrency transaction) could stick around when a user changed the recipient address or scanned a new QR code. The leftover data could then incorrectly block or alter sending for coins that don't support it. The patch clears that stale state in more places and disables the preview-transaction button when OP_RETURN data is present for any coin other than Firo.

This commit fixes a UI/workflow bug in Stack Wallet's ShopInBit integration. When an order is fully covered by a voucher or store credit, the payment status becomes 'no_payment_required' and the invoice has no payment addresses. Previously the app treated this as a failed payment load and blocked the user; now it shows a 'fully covered' screen and lets the user continue. It is a functional bug fix rather than a security vulnerability.

This commit makes two small code cleanups in a car-research payment flow. One change removes a manual timer cancellation and relies on the caller to cancel it, which could in theory lead to a timer continuing to run briefly if the caller doesn't always do so. The other change replaces a safe integer parser (which throws a clear error on bad input) with a stricter parser that throws a less informative error. Neither change is obviously a security fix, and the commit message frames them as routine review follow-up rather than a security issue.

This commit changes how the Stack Wallet app parses data from its ShopInBit partner service. Previously, missing or malformed fields were silently replaced with empty strings, zero, or the current date/time. Now the app throws visible errors instead. That is generally a good defensive change, but it removes some safety comments and fallback behavior for unknown ticket states, and it makes parsing stricter. The patch is small and appears aimed at surfacing bugs rather than introducing a vulnerability, but it is only a partial hardening of the parsing layer.

This commit tightens how the Stack Wallet app reads data from its ShopInBit partner service. Previously, several fields were treated as optional and replaced with safe defaults (empty strings, false, current time) when missing. Now the code requires those fields to be present and correctly typed. This is a defensive correctness fix: it makes the app fail earlier and more visibly if the server sends unexpected or malformed data, rather than silently continuing with placeholder values. There is no direct evidence this fixes an active security vulnerability, but it reduces the risk of logic errors or misleading UI state caused by missing fields.

This commit fixes a bug in the Stack Wallet app's integration with ShopinBit's car-research service. Previously, if the invoice expiration date was missing or unreadable, the app would silently replace it with the current time, making a brand-new invoice look like it had already expired. Now the app keeps the expiration date as 'unknown' instead of guessing. This is a correctness and user-experience fix, not a remote code execution or theft vulnerability.