You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A network account built with any fee faucet other than the chain's is accepted by newAccount, deploys fine, and then never has a single note consumed - the SDK could reject it up front instead.
Symptom: notes carrying a NetworkAccountTarget for the account commit but are never consumed. No error reaches the client. Only the node's ntx-builder.log says why: network account fee asset does not match the protocol configuration.
Cause: node 0.17's network-transaction builder compares the account's FeePolicyManager fee-asset slot with the chain's ProtocolConfig fee asset and refuses on a mismatch (bin/ntx-builder/src/actor/execute.rs, NtxDataStore::new). The slot is written from the feeFaucetId passed to AccountComponent.createNetworkAuthComponents.
Repro: build a network account with createNetworkAuthComponents(fees, (await client.newFaucet(...)).id()), insert and deploy it, emit a network note to it, and wait any number of blocks.
Expected:newAccount (one export shared by WASM and napi) rejects a network account whose fee-asset slot differs from client.feeFaucetId(), naming both, before anything is deployed. Importing an already-deployed account could warn instead.
Impact: hours of debugging the first time (chore: update rust-sdk to 0.17.0-rc.1 #406 chased note-script registration before reading the node log). The account cannot be repaired, only rebuilt.
The client holds both values before any transaction runs: the fee faucet of its registered protocol configuration (client.feeFaucetId()) and the account's storage, which upstream NetworkAccount already parses (account.rs). The factory itself cannot check, since it is static and has no client.
#406 documents the requirement in the rustdoc, README, network-notes guide, skills and CHANGELOG, and fixes the two tests that built such an account. Adding a new rejection to a public method was kept out of the 0.17 rc.
Test: on the mock chain, inserting a network account built with a freshly minted faucet rejects with a message naming feeFaucetId; one built with await client.feeFaucetId() inserts.
A network account built with any fee faucet other than the chain's is accepted by
newAccount, deploys fine, and then never has a single note consumed - the SDK could reject it up front instead.NetworkAccountTargetfor the account commit but are never consumed. No error reaches the client. Only the node'sntx-builder.logsays why:network account fee asset does not match the protocol configuration.FeePolicyManagerfee-asset slot with the chain'sProtocolConfigfee asset and refuses on a mismatch (bin/ntx-builder/src/actor/execute.rs,NtxDataStore::new). The slot is written from thefeeFaucetIdpassed toAccountComponent.createNetworkAuthComponents.createNetworkAuthComponents(fees, (await client.newFaucet(...)).id()), insert and deploy it, emit a network note to it, and wait any number of blocks.newAccount(one export shared by WASM and napi) rejects a network account whose fee-asset slot differs fromclient.feeFaucetId(), naming both, before anything is deployed. Importing an already-deployed account could warn instead.Why it is feasible and why it is not in #406
The client holds both values before any transaction runs: the fee faucet of its registered protocol configuration (
client.feeFaucetId()) and the account's storage, which upstreamNetworkAccountalready parses (account.rs). The factory itself cannot check, since it is static and has no client.#406 documents the requirement in the rustdoc, README, network-notes guide, skills and CHANGELOG, and fixes the two tests that built such an account. Adding a new rejection to a public method was kept out of the 0.17 rc.
Test: on the mock chain, inserting a network account built with a freshly minted faucet rejects with a message naming
feeFaucetId; one built withawait client.feeFaucetId()inserts.