Rust `#[tx_script]` cannot be executed in 0.15.0 — `.masp` rejected by `exec`, and `--emit masm` output is component-model annotated

[Mustdzyl]

Environment

• toolchain 0.15.0 (midenup install stable)
• account component + transaction script both authored in Rust, built with cargo miden build --release

What works

Deploying a Rust account component works end to end:

miden client new-account -p my_component.masp -i init.toml --deploy

The account is created, and miden client call <account_id>:my_proc <arg> returns exactly the
storage delta I expect. So the component side of the toolchain is fine.

The problem

call only previews the delta — it never commits (repeated calls always start from the same
committed state, nonce does not advance). To persist state a transaction script is needed.

I wrote one in Rust:

#[account(my_pkg::MyIface)]
pub struct NativeAccount;

#[tx_script]
fn run(arg: Word, account: &mut NativeAccount) {
    account.my_proc(arg.a);
}

It builds successfully into my_script.masp.

1. exec rejects the compiled package.

$ miden client exec -a <account_id> -s target/miden/release/my_script.masp
Error: cli::script_builder_error
  x failed to build script: failed to parse transaction script:
    source manager is unable to load file
    `-> stream did not contain valid UTF-8

So --script-path wants MASM source, not the package.

2. --emit masm produces MASM the script parser cannot accept.

$ cargo miden build --release --emit masm=./masm_out
$ miden client exec -a <account_id> -s ./masm_out/my_script.masm
Error: cli::script_builder_error
  x invalid syntax
     ,-[my_script.masm:4:14]
   3 | @callconv("component-model")
   4 | pub proc run(struct { a: struct { inner: felt }, b: struct {
     :              ^^^|^^
     :                 `-- found a struct here
   5 |     inner: felt
     `----
  help: expected ")", or identifier

The emitted MASM carries component-model type signatures (@callconv("component-model"),
struct { ... } parameters), which the transaction-script parser does not understand.

Note: --emit masm only produces output when the compiler actually re-runs — with a warm cargo
cache the directory is created but stays empty, which is a little confusing.

Question

Is there a supported path from a Rust-authored #[tx_script] to something miden client exec
accepts in 0.15.0?

If transaction scripts must currently be hand-written in plain MASM, they would need to call the
account procedure by MAST root — but I could not find the per-procedure roots exposed anywhere
(miden client account -s shows only the Code Commitment, and the .masp exposes the export
name "miden:my_pkg/my_iface@0.1.0#my_proc" but not its digest). Is there a command to dump
procedure roots from a package?

Minor, possibly separate

miden deploy (top-level alias) fails before parsing any arguments:

$ miden deploy
error: unexpected argument '-s' found
Usage: miden client [OPTIONS] <COMMAND>

miden simulate resolves to miden client exec, which looks intentional, but deploy appears
to inject a stray -s.

[Mustdzyl]

Following up with what I found, in case someone else hits the same wall.

Short version: exec --script-path isn't the path. Transaction scripts are compiled through the Rust client library, not the CLI:

let tx_script = client
    .code_builder()
    .with_linked_module("my_ns::my_contract", account_masm_source)?
    .compile_tx_script(script_masm_source)?;

let request = TransactionRequestBuilder::new()
    .custom_script(tx_script)
    .build()?;

client.submit_new_transaction(account_id, request).await?;

The account module is linked as MASM source on the same CodeBuilder chain as the script, which is why handing exec a compiled .masp was never going to work.

On my second question (dumping procedure roots): not needed either — procref.<module>::<proc> resolves the MAST root at assembly time. 0xMiden/tutorials#240 switches the FPI example over to exactly that, replacing a manual get_procedure_root_by_path lookup plus string substitution into the script source.

So from my side this is resolved as a usage question. What I think is still worth keeping open:

1. miden client exec --script-path accepts only MASM source. Passing a .masp fails with stream did not contain valid UTF-8, rather than a message saying a compiled package isn't supported there.
2. cargo miden build --emit masm output is @callconv("component-model") annotated with struct parameters, which the tx-script assembler rejects (invalid syntax: found a struct here). So a Rust-authored #[tx_script] still has no working route in 0.15 as far as I can tell.
3. The miden deploy alias injects an invalid -s flag.

Happy to close this if (2) is expected for 0.15 and Rust tx-scripts simply aren't supported yet — a line saying so in the docs would have saved me a couple of days.

[greenhat]

Thank you!

So from my side this is resolved as a usage question. What I think is still worth keeping open:

1. miden client exec --script-path accepts only MASM source. Passing a .masp fails with stream did not contain valid UTF-8, rather than a message saying a compiled package isn't supported there.
2. cargo miden build --emit masm output is @callconv("component-model") annotated with struct parameters, which the tx-script assembler rejects (invalid syntax: found a struct here). So a Rust-authored #[tx_script] still has no working route in 0.15 as far as I can tell.
3. The miden deploy alias injects an invalid -s flag.

Happy to close this if (2) is expected for 0.15 and Rust tx-scripts simply aren't supported yet — a line saying so in the docs would have saved me a couple of days.

Yes, (2) is expected. The MASM code emitted by the compiler is not intended to be compiled by the assembler.

[bitwalker]

Regarding (2) - the --emit output is not intended to be fed directly into the Miden assembler, as it will emit multiple modules in a single output stream for display (using comments to indicate the individual modules), and this is not something recognized by the assembler. As @greenhat noted, this output is for debugging purposes, not as a formal output artifact that can be used directly with other tooling. In theory we could emit a Miden project with MASM sources that could be assembled, but that wouldn't solve your problem anyway - miden client exec wants a script path (a single source file), and that is not how Miden Assembly is structured to begin with.

Regarding (3) - we recently updated the client aliases for miden, so the issue with deploy is likely fixed. Please report issues with aliases to midenup directly.

---

The issue here is that miden-client is not providing an avenue for giving it the transaction script package that was already assembled via miden client exec - assuming there is no such flag for this, I would report that issue in the client repo.

Pinging @igamigo for visibility on that.

[Mustdzyl]

Coming back to (2) with something that works, in case anyone else is stuck in the same place.

A Rust #[tx_script] package can be turned into a TransactionScript today, without going anywhere near MASM source. cargo miden build emits a package with kind = transaction-script, and TransactionScript::from_package refuses it, because it goes through Package::try_into_program, which insists on TargetType::Executable:

cannot convert package of type transaction-script to Executable

Package::make_executable bridges exactly that. Pointing it at the run export produces a package from_package accepts:

let package = Package::read_from_bytes(&fs::read(path)?)?;
let entrypoint: QualifiedProcedureName =
    r#"::"miden:base/transaction-script@1.0.0"::run"#.parse()?;
let tx_script = TransactionScript::from_package(&package.make_executable(&entrypoint)?)?;

Two details that cost me a while — the manifest lists the entrypoint in two forms and only one of them resolves: "miden:base"::"transaction-script@1.0.0"::run fails with library does not contain a module named ..., while the ::"miden:base/transaction-script@1.0.0"::run form works. And is_library() returns true for a transaction-script package, since it is defined as !is_executable(), which sent me looking in the wrong direction for a while.

I have only verified the conversion here, not execution of the resulting script against an account.

So the route does exist in 0.15, it just isn't wired into anything: miden client exec --script-path still assembles source, so there is no way to hand the CLI the package. I will open that on the client repo as suggested.