Summary
Minting from a FungibleFaucet account that has a TokenPolicyManager component installed
(with MintAllowAll / BurnAllowAll active policies) fails with a kernel assertion during
transaction execution:
failed to remove the fungible asset from the vault since the amount of the asset in the vault
is less than the amount to remove
This reproduces both via a custom miden-client Rust binary using
TransactionRequestBuilder::build_mint_fungible_asset(...), and via the official
miden-client CLI's mint command against a faucet the CLI itself deployed. This rules out
an application-level bug — the CLI and the SDK hit the identical kernel assertion against a
faucet built entirely through the official tooling.
Environment
miden-client: 0.16.1
miden-standards: 0.16.1
miden-protocol: 0.16.1
miden-lib: 0.16.1
miden-tx: 0.16.1
- OS: Ubuntu (WSL2, DESKTOP-ER0O7RV)
- Network: Miden testnet
Steps to Reproduce (official CLI, minimal repro)
- Create a fungible faucet via the CLI with
TokenPolicyManager (allow-all mint/burn policies),
6 decimals, any reasonable max_supply.
- Sync the client:
miden-client sync
- Run:
miden-client mint -t <any-valid-target-address> -a "10000::<faucet-account-id>" -n public --force
- Observe the transaction execution fail with the assertion below.
Expected Behavior
The mint transaction should succeed and produce a public note carrying 10,000 tokens
(6 decimals -> 10,000,000,000 base units) to the target account, since:
max_supply is well above the requested mint amount (verified independently, not the cause —
see Additional Context).
- The active mint policy is
MintAllowAll, so the policy check should pass unconditionally.
- The faucet has zero prior minted supply (freshly deployed).
Actual Behavior
Error: cli::client_error
x client error
|-> transaction execution failed
`-> failed to execute transaction kernel program:
x assertion failed with error message: failed to remove the fungible asset from the vault
since the amount of the asset in the vault is less than the amount to remove
Full CLI output also logs (repeatedly, once per .masl/component involved) prior to execution:
ERROR miden_core::mast::serialization: UntrustedMastForest expected HASHLESS input; supplied
artifact includes wire node hashes, and validation will recompute them and require them to match
This warning appears unconditionally on every transaction attempt against this faucet type and
may or may not be related — flagging it in case it's a symptom of the same root cause (possibly
a MAST forest / procedure-root mismatch between the FungibleFaucet component's mint_and_send
procedure and what TokenPolicyManager's dynexec dispatch resolves at runtime, which could
explain why the vault "receives" the minted asset via add_asset inconsistently before the
transfer-to-note step tries to remove_asset it).
Additional Context
- Confirmed this is not a
max_supply scaling issue (an earlier, separate error we hit and
fixed: max_supply must be expressed in base units matching decimals, same as the mint
amount).
- Confirmed this is not a dependency version skew issue: all
miden-* runtime crates
(miden-client, miden-standards, miden-protocol, miden-lib, miden-tx) resolve to the
identical 0.16.1 version in Cargo.lock. (A separate, older miden-protocol 0.15.3 does
appear in the dependency tree, but only via unrelated MASM compiler tooling crates —
cargo-miden / midenc-* — used to build custom note/contract scripts, not via any
miden-client/miden-standards/miden-tx runtime path.)
- Suspect the interaction between
TokenPolicyManager's dynexec-based mint-policy dispatch and
the FungibleFaucet component's mint_and_send procedure (which, per docs, both mints and
creates the output note in one call) is where the vault balance bookkeeping goes wrong —
possibly the mint policy's gated call short-circuits before the actual add_asset to the
faucet happens, so the subsequent remove_asset (to move the newly minted amount into the
output note) finds nothing there.
- Minting from a faucet built with the older/simpler
miden_lib::account::faucets::BasicFungibleFaucet
(no TokenPolicyManager) has not yet been tested as a comparison — will update if useful.
Request
Could someone confirm whether this is a known issue with TokenPolicyManager-composed fungible
faucets in 0.16.1, and if so, point to a workaround or fix timeline? Happy to provide the full
faucet-deployment code and/or a minimal reproducible Rust project if useful.
Summary
Minting from a
FungibleFaucetaccount that has aTokenPolicyManagercomponent installed(with
MintAllowAll/BurnAllowAllactive policies) fails with a kernel assertion duringtransaction execution:
This reproduces both via a custom
miden-clientRust binary usingTransactionRequestBuilder::build_mint_fungible_asset(...), and via the officialmiden-clientCLI'smintcommand against a faucet the CLI itself deployed. This rules outan application-level bug — the CLI and the SDK hit the identical kernel assertion against a
faucet built entirely through the official tooling.
Environment
miden-client: 0.16.1miden-standards: 0.16.1miden-protocol: 0.16.1miden-lib: 0.16.1miden-tx: 0.16.1Steps to Reproduce (official CLI, minimal repro)
TokenPolicyManager(allow-all mint/burn policies),6 decimals, any reasonable
max_supply.miden-client syncExpected Behavior
The mint transaction should succeed and produce a public note carrying 10,000 tokens
(6 decimals -> 10,000,000,000 base units) to the target account, since:
max_supplyis well above the requested mint amount (verified independently, not the cause —see Additional Context).
MintAllowAll, so the policy check should pass unconditionally.Actual Behavior
Full CLI output also logs (repeatedly, once per
.masl/component involved) prior to execution:This warning appears unconditionally on every transaction attempt against this faucet type and
may or may not be related — flagging it in case it's a symptom of the same root cause (possibly
a MAST forest / procedure-root mismatch between the
FungibleFaucetcomponent'smint_and_sendprocedure and what
TokenPolicyManager'sdynexecdispatch resolves at runtime, which couldexplain why the vault "receives" the minted asset via
add_assetinconsistently before thetransfer-to-note step tries to
remove_assetit).Additional Context
max_supplyscaling issue (an earlier, separate error we hit andfixed:
max_supplymust be expressed in base units matchingdecimals, same as the mintamount).
miden-*runtime crates(
miden-client,miden-standards,miden-protocol,miden-lib,miden-tx) resolve to theidentical
0.16.1version inCargo.lock. (A separate, oldermiden-protocol 0.15.3doesappear in the dependency tree, but only via unrelated MASM compiler tooling crates —
cargo-miden/midenc-*— used to build custom note/contract scripts, not via anymiden-client/miden-standards/miden-txruntime path.)TokenPolicyManager'sdynexec-based mint-policy dispatch andthe
FungibleFaucetcomponent'smint_and_sendprocedure (which, per docs, both mints andcreates the output note in one call) is where the vault balance bookkeeping goes wrong —
possibly the mint policy's gated call short-circuits before the actual
add_assetto thefaucet happens, so the subsequent
remove_asset(to move the newly minted amount into theoutput note) finds nothing there.
miden_lib::account::faucets::BasicFungibleFaucet(no
TokenPolicyManager) has not yet been tested as a comparison — will update if useful.Request
Could someone confirm whether this is a known issue with
TokenPolicyManager-composed fungiblefaucets in
0.16.1, and if so, point to a workaround or fix timeline? Happy to provide the fullfaucet-deployment code and/or a minimal reproducible Rust project if useful.