Skip to content

fix(cli): notes --send silently accepts addresses from the wrong network - #2525

Open
batuhankocyigit wants to merge 6 commits into
0xMiden:nextfrom
batuhankocyigit:fix-notes-send-network-mismatch
Open

fix(cli): notes --send silently accepts addresses from the wrong network#2525
batuhankocyigit wants to merge 6 commits into
0xMiden:nextfrom
batuhankocyigit:fix-notes-send-network-mismatch

Conversation

@batuhankocyigit

@batuhankocyigit batuhankocyigit commented Sep 9, 2026

Copy link
Copy Markdown

Problem

address add, address remove, and address encode all validate that a
decoded bech32 address's network matches the client's configured network
(see decode_account_address in commands/address.rs). notes --send
uses the same Address::decode() call but discards the returned network
ID (_netid), so it silently accepts an address encoded for a different
Miden network (mainnet vs testnet vs devnet).

Impact

A user pasting a testnet address into a mainnet client (or vice versa) gets
no error: send_private_note/send_private_note_with_block_hint proceeds
normally, but the note is effectively unreachable to the intended recipient
on the other network.

Fix

Mirror the same network check already used in address.rs: compare the
decoded network ID against client.network_id() and return a clear
CliError::Input if they don't match.

Repro (before fix)

  1. miden-client address encode <account> basic-wallet on a testnet-configured client → copy the printed bech32 address.
  2. On a mainnet-configured client: miden-client notes --send <note-id> <that-address> → succeeds with no error today.
  3. After this fix: fails with Address network `mtst` does not match configured network `mm`.

Checklist

  • Forked from next, branch named per convention
  • Commit signed (GitHub web UI)
  • Commit message / code style follow conventions
  • CHANGELOG.md entry added

`notes --send` decoded the recipient's bech32 address but discarded its
network ID (`_netid`), unlike `address add`/`address remove`/`address encode`
which validate the decoded network against the client's configured network.
A note could be silently sent to an address encoded for a different Miden
network (e.g. testnet vs mainnet), with no error and no way for the
recipient to consume it.
@igamigo
igamigo requested a review from juan518munoz September 9, 2026 18:22
@juan518munoz

Copy link
Copy Markdown
Collaborator

PR description looks off, please check formatting.

@juan518munoz juan518munoz left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look reasonable, could you please add a test for this?

Comment thread CHANGELOG.md Outdated

## Unreleased

- [FIX][cli] `notes --send` now rejects a recipient address whose network doesn't match the client's configured network, instead of silently sending to it.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changelog entries carry their related PR.

@batuhankocyigit

Copy link
Copy Markdown
Author

Thanks for the review fixed the PR description formatting, added a unit test for the network-mismatch decode path, and linked the CHANGELOG entry to this PR (#2525).

@juan518munoz

Copy link
Copy Markdown
Collaborator

Please look into fixing the failing CI job

cargo +nightly fmt --all --check was failing due to an unnecessary line break in the network-mismatch test.
@batuhankocyigit

Copy link
Copy Markdown
Author

Please look into fixing the failing CI job

Fixed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants