chore: update with latest miden-base

[SantiagoPittella]

closes #1522

THis PR update with the latest miden-base changing, affecting primary the network note detection.

I wanted to test this with the network monitor and its counter increment network transaction, but I started to receive the same error that I mentioned in #1490:

status: 'Client specified an invalid argument', self: "transaction's initial state commitment
0xfbdb4615d915c83feb32b3943992b305c72b4a3675cacdce407929a7507af245 does not match the account's
current value of 0x0000000000000000000000000000000000000000000000000000000000000000", metadata:
{"content-type": "application/grpc", "date": "Fri, 16 Jan 2026 15:25:52 GMT", "access-control-expose-headers":
"grpc-status,grpc-message,grpc-status-details-bin", "access-control-allow-credentials": "true", "vary": "origin,
access-control-request-method, access-control-request-headers"}

Update: fixed it by making get_vault_asset_witnesses return an empty vector as suggested in #1493 (comment)

[PhilippGackstatter]

Looks good - left a few comments.

[PhilippGackstatter]

Looks good to me from a protocol perspective.

I think the network account ID should eventually contain at least 64 or more bits of the account ID - ideally the full one. Anything less than 64 is not guaranteed to be unique, but probably not critical to do before 0.13 testnet.

[PhilippGackstatter]

Suggested change

	#[error("note does not have a valid NetworkAccountTarget attachment: {0}")]
	InvalidAttachment(String),
	#[error("note does not have a valid NetworkAccountTarget attachment: {0}")]
	InvalidAttachment(#[source] NetworkAccountTargetError),

Nit: Should this use asource error instead of stringifying it?

[SantiagoPittella]

NetworkAccountTargetError is not publicly exposed. In miden-base we have:

mod network_account_target;
pub use network_account_target::NetworkAccountTarget;

Should we make the whole module public?

[Mirko-von-Leipzig]

@SantiagoPittella if you could mark comments as resolved once you have addressed them (in your opinion). This let's me see that I can review without worrying about these.

[SantiagoPittella]

@SantiagoPittella if you could mark comments as resolved once you have addressed them (in your opinion). This let's me see that I can review without worrying about these.

Sure! I usually let the reviewer to decide that. I marked the comments that I consider addressed. There is one remaining #1526 (comment)

[Mirko-von-Leipzig]

@SantiagoPittella if you could mark comments as resolved once you have addressed them (in your opinion). This let's me see that I can review without worrying about these.

Sure! I usually let the reviewer to decide that. I marked the comments that I consider addressed. There is one remaining #1526 (comment)

I've gone back and forth and this myself as well. I should probably right some thoughts down at some point a bit more formally :D

[bobbinth]

We should go through comments/names etc. to make sure we no longer use "prefix" terminology.

[bobbinth]

I would maybe replace this with something like network_note_type or network_note_group and use the following value:

• 0 - not a network note (same as now).
• 1 - single account target network note (same as now).

In the future, this would allow us to to extend this to other type of network notes.

[Mirko-von-Leipzig]

We could also repurpose note_type I think so that we have:

enum NoteType {
    Private,
    /// Public, non-network
    Public,
    /// Public, single-target network
    SingleTargetNetwork,
    ...
}

or will these not remain orthogonal?

[bobbinth]

Possible, but may complicate note metadata construction logic because we'd need to convert SingleTargetNetwork to Public.