Stack Wallet

This commit fixes how transaction fees are subtracted from Spark mint outputs. The old code could mis-handle cases where an output was too small to cover its share of the fee, potentially leaving leftover fees unassigned or removing outputs incorrectly. The new code walks through outputs one by one, recalculating each remaining output's fair share of the fee, and cleanly removes outputs that cannot cover their portion. It also adds a guard to drop the whole input set if every output gets removed because fees exceed the mint amount.

This commit revises how Stack Wallet builds Spark mint transactions. The visible changes fix a fee-rate floor bug, correct a loop that could remove the wrong recipient when outputs are too small, and tighten error handling when signing keys or change addresses are missing. It also replaces an eager key-caching approach with lazy caching. The commit is framed as responding to an external review, but no security incident or CVE is mentioned in the materials provided.

This commit is purely a code-formatting cleanup. It runs the Dart formatter on several files related to the ShopinBit feature, adjusting line breaks, indentation, and whitespace. No functionality, logic, or security behavior was changed.

This commit is purely a code-formatting cleanup. It runs the Dart formatter on 21 files related to the CakePay and ShopinBit features, changing only whitespace, line breaks, and indentation. No functionality, logic, or security behavior was altered.

This commit is purely a code-formatting cleanup. It runs Dart's automatic formatter on two files, adjusting whitespace and line breaks without changing any logic, calculations, or behavior. There is no security issue here.

This commit is a small internal cleanup for the Mimblewimblecoin wallet code. It replaces several repeated blocks of 'open the wallet' code with a single shared helper, and adds a 60-second timeout to one wallet-opening call so the app doesn't hang forever if something goes wrong. There is no obvious security bug being fixed; it is a code-quality and reliability improvement.

This commit embeds a hardcoded secret string (nodeApiSecret) directly into the source code for the default Mimblewimblecoin (MWC) node configuration in a cryptocurrency wallet app. If this secret is meant to authenticate or protect access to the node, publishing it in public source code means anyone can read it. That could let an attacker interact with or abuse the default node in ways the developer did not intend. However, the commit itself does not explain what nodeApiSecret does, so we cannot be certain of the exact risk.

This commit removes a hardcoded API password that was embedded in the Stack Wallet source code for connecting to a default Mimblewimblecoin (MWC) node. Previously, anyone reading the code could see the secret password. Now the wallet reads the password from user-configured node settings instead. This is a security improvement, but the change also shows that a real secret was once hardcoded and may have been exposed to anyone inspecting older versions of the app.

This entry is a merge commit that pulls in a branch named 'fix/global-chain-type-race' from a sub-project called flutter_libmwc. No actual code diff is available, and no verified public references were supplied. The title suggests a race-condition fix related to a global 'chain type' setting in MWC (a cryptocurrency plugin), but we cannot see what changed or whether it has security implications.

This change adds a lock (mutex) around wallet-opening operations for the Mimblewimblecoin (MWC) wallet. Without the lock, multiple parts of the app could try to open the same wallet at the same time through the native library, which could cause crashes, corrupted wallet state, or the wallet being opened twice. The fix makes these calls happen one at a time.

This commit fixes how Stack Wallet's Mimblewimblecoin (MWC) wallet connects to the default MWC node. Previously, the wallet did not write the required API secret file, so the Rust backend could not authenticate to the default node. The patch now writes a hardcoded secret to a file named .api_secret in the wallet directory when the configured node is the default one. The security concern is that the secret is embedded in the source code and stored on disk, and any app or process with access to the wallet directory can read it. However, this appears to be the intended public secret for the default node, not a private user credential.

This commit fixes how Stack Wallet reads Solana token transactions. Previously, the wallet only recognized a specific detailed transfer format called 'transferChecked'. Now it also accepts the simpler 'transfer' format. Without this fix, some legitimate token transactions may have been missed or misrecorded, which could lead to incorrect balances or transaction history.

This commit fixes bugs in how Stack Wallet refreshes private Spark (privacy coin) balances and generates new Spark addresses. The changes prevent the wallet from skipping coins when its local cache gets out of sync, avoid duplicate database entries, and ensure new Spark addresses are derived from the correct prior address. These are reliability/correctness fixes that could affect whether a user sees their full balance or receives funds to a valid address, but they do not appear to introduce a remote exploit path.

This commit changes how the Stack Wallet app finds a user's Firo masternodes. Previously, the wallet guessed masternode identities by scanning local transaction records and 1000-FIRO UTXOs, which could miss masternodes or include wrong transactions. The new code fetches full transaction details from the ElectrumX server and matches each ProRegTx transaction to its exact collateral transaction ID. There is no direct evidence in the commit that this fixes an exploitable security vulnerability; it appears to be a correctness/reliability fix for the masternode list display and management.

This commit is a routine user-experience fix for the Firo masternode registration flow in Stack Wallet. It makes the registration form clearer, remembers when a user has dismissed a collateral prompt, and shows a confirmation dialog after a masternode registration transaction is submitted. There is no clear security vulnerability in the changes, but one small code-quality issue (a broken `mainAxisAlignment: .spaceBetween` expression) was introduced and may cause a build failure. The commit also switches a build script to use the Firo test network by default, which is a configuration change rather than a security issue.

This commit fixes a visual layout problem in the desktop version of Stack Wallet. It prevents menus and dialog boxes from extending beyond the screen when there are too many items, by making them scrollable and limiting their maximum height. There is no security issue here.

This commit fixes a bug in Stack Wallet's Firo Spark coin-minting code where the estimated transaction fee could be too small because the temporary 'dummy' transaction used for fee estimation had shorter digital signatures than the final real transaction. With many inputs, the difference could exceed the old fixed 10-byte safety buffer, causing the wallet to create transactions that failed a minimum-fee check and could not be broadcast. The patch scales the buffer with the number of inputs, pre-computes expensive key derivations for performance, and also catches a negative-mint-amount edge case. There is no direct evidence this was exploited as an attack; it appears to be a reliability/DoS bug for the wallet user.

This commit only adds a new automated test file for a car-purchase feature. It does not change any production code, so it cannot introduce a security vulnerability or fix one directly. The tests verify that certain data fields survive being saved and reloaded by the app.

This commit adds a 'Complete Request' retry button to a ticket detail screen for a car-research ordering feature. It lets users resubmit a request that previously failed to create. The change is a routine UI/flow improvement and does not, on its own, introduce an obvious security vulnerability. There is no indication in the commit that this fixes a security issue or that it was disclosed as such.

This commit adds a 'save and resume' feature for an in-app car-research purchase flow. It stores the user's progress locally so they can continue later instead of losing it if they close the screen. There is no security bug or fix visible in the change.

This commit fixes a small logic bug in a cryptocurrency wallet's car-research payment screen. Before saving a payment ticket to the local database, the code now clears a 'resume/retry' flag (isPendingPayment). Without the fix, the app might incorrectly think a payment was still pending after it had already completed, which could confuse the user or allow an unintended retry/refund flow. There is no direct evidence of a security vulnerability such as theft of funds.

This commit adds three new data fields to the app's internal database and in-memory model for tracking pending car-research payments in a shopping feature. It is purely a schema and state-management change; no security-sensitive logic is introduced, and no vulnerability is visible in the diff.

This commit fixes the checkout flow for a third-party shopping service inside the Stack Wallet app. It mainly corrects navigation behavior after a user pays, prevents duplicate database records, and changes the service type label sent to the backend from 'car_research' to 'car'. There is no clear security vulnerability being patched; it reads like a bug-fix for a broken purchase/resume experience.

This commit rewrites the car-research payment flow in a shopping feature. It replaces two simple boolean flags with a single state machine (an enum) and adds a retry path so that if the second backend call fails, the user can retry later instead of losing the payment record. There is no obvious security bug introduced; it is a reliability/usability improvement.

This is a routine maintenance commit. It pins a development tool (the Dart analyzer package) to a version below 8.4.0 to avoid a build-time incompatibility with another code-generation tool, and it regenerates some automatically produced database files. There is no direct security fix or user-facing vulnerability patch in the diff.