Skip to content

TokenPolicyManager-composed FungibleFaucet: mint fails with 'amount in vault is less than amount to remove' #3912

Description

@anaraydinli55

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)

  1. Create a fungible faucet via the CLI with TokenPolicyManager (allow-all mint/burn policies),
    6 decimals, any reasonable max_supply.
  2. Sync the client: miden-client sync
  3. Run:
    miden-client mint -t <any-valid-target-address> -a "10000::<faucet-account-id>" -n public --force
  4. 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.

Activity

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions