fix(cli): notes --send silently accepts addresses from the wrong network - #2525
Open
batuhankocyigit wants to merge 6 commits into
Open
fix(cli): notes --send silently accepts addresses from the wrong network#2525batuhankocyigit wants to merge 6 commits into
batuhankocyigit wants to merge 6 commits into
Conversation
`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.
Collaborator
|
PR description looks off, please check formatting. |
juan518munoz
reviewed
Sep 9, 2026
juan518munoz
left a comment
Collaborator
There was a problem hiding this comment.
Changes look reasonable, could you please add a test for this?
|
|
||
| ## 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. |
Collaborator
There was a problem hiding this comment.
Changelog entries carry their related PR.
Changelog entries carry their related PR, per review feedback.
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
approved these changes
Sep 10, 2026
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.
Author
Fixed |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
address add,address remove, andaddress encodeall validate that adecoded bech32 address's network matches the client's configured network
(see
decode_account_addressincommands/address.rs).notes --senduses the same
Address::decode()call but discards the returned networkID (
_netid), so it silently accepts an address encoded for a differentMiden 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_hintproceedsnormally, 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 thedecoded network ID against
client.network_id()and return a clearCliError::Inputif they don't match.Repro (before fix)
miden-client address encode <account> basic-walleton a testnet-configured client → copy the printed bech32 address.miden-client notes --send <note-id> <that-address>→ succeeds with no error today.Address network `mtst` does not match configured network `mm`.Checklist
next, branch named per convention