hide receive actions for address entry cells in sp wallets
What changed, and why it matters
This commit removes the 'Receive To' button and menu option for a specific type of wallet called a 'single sig single purpose' (SINGLE_SP) wallet. Previously, these receive actions were shown for all wallets except BIP47 (PayNym) wallets. The change appears to be a UI hardening measure to prevent users from accidentally or inappropriately reusing addresses in wallets that are intended to be used only once.
No immediate action required. Treat as a minor defensive UI improvement. If auditing, verify that SINGLE_SP wallets also disable or warn against receive actions elsewhere in the codebase, since this patch only covers EntryCell.
Security signals we found
UI action restricted based on wallet policy type
Prevents receive action for SINGLE_SP wallets
Consistent with reducing address reuse risk
Evidence from the diff
The patch modifies EntryCell.java in two places. First, it adds a condition so that the receiveButton is not created when the wallet’s policy type is PolicyType.SINGLE_SP. Second, it adds the same condition to AddressContextMenu so that the ‘Receive To’ menu item is not shown for SINGLE_SP wallets. The change is purely UI-level: it hides actions rather than changing any address derivation, signing, or validation logic. There is no direct evidence in the diff of a vulnerability such as address reuse leading to theft, but the change is consistent with reducing a foot-gun for single-purpose wallets.
Changed components
src/main/java/com/sparrowwallet/sparrow/control/EntryCell.javaReceive button in address entry cellsAddressContextMenu 'Receive To' menu itemInspect captured patch +2 / −2
diff --git a/src/main/java/com/sparrowwallet/sparrow/control/EntryCell.java b/src/main/java/com/sparrowwallet/sparrow/control/EntryCell.java
index bf43bf1..e57cabf 100644
--- a/src/main/java/com/sparrowwallet/sparrow/control/EntryCell.java
+++ b/src/main/java/com/sparrowwallet/sparrow/control/EntryCell.java
@@ -136,7 +136,7 @@ public class EntryCell extends TreeTableCell<Entry, Entry> implements Confirmati
HBox actionBox = new HBox();
actionBox.getStyleClass().add("cell-actions");
- if(!nodeEntry.getNode().getWallet().isBip47()) {
+ if(!nodeEntry.getNode().getWallet().isBip47() && nodeEntry.getNode().getWallet().getPolicyType() != PolicyType.SINGLE_SP) {
Button receiveButton = new Button("");
receiveButton.setGraphic(getReceiveGlyph());
receiveButton.setOnAction(event -> {
@@ -669,7 +669,7 @@ public class EntryCell extends TreeTableCell<Entry, Entry> implements Confirmati
public static class AddressContextMenu extends ContextMenu {
public AddressContextMenu(Address address, String outputDescriptor, NodeEntry nodeEntry, boolean addUtxoItems, TreeTableView<Entry> treetable) {
- if(nodeEntry == null || !nodeEntry.getWallet().isBip47()) {
+ if(nodeEntry == null || (!nodeEntry.getWallet().isBip47() && nodeEntry.getWallet().getPolicyType() != PolicyType.SINGLE_SP)) {
MenuItem receiveToAddress = new MenuItem("Receive To");
receiveToAddress.setGraphic(getReceiveGlyph());
receiveToAddress.setOnAction(event -> {
Why this scored 32/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.