Support muxed (M…) source accounts in the contract invoke pipeline
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- rust
- Domain
- blockchain, cli
Research direction
Start in cmd/soroban-cli/src/commands/contract/invoke.rs at line 349 and trace the source-account use through sequence lookup and build_invoke_contract_tx. Check the existing simulation and contract-invoke integration tests, then add coverage for an M… source signed through an identity or --sign-with-* option. Done means --source-account M… and --from M… work through simulate, sign, and submit while preserving the mux id in the transfer argument.
Written by the indexing model from the issue text.
Description
Background
Spun out of review feedback on #2644 (stellar token transfer). SEP-41 supports muxed addresses (CAP-67 ScAddress::MuxedAccount), and --from M… almost works today: UnresolvedMuxedAccount resolves it, and arg parsing + simulation accept it.
Problem
It then fails in the shared contract invoke pipeline at cmd/soroban-cli/src/commands/contract/invoke.rs:349:
client.get_account(&config.source_account()?.to_string()).await?
The M… strkey is handed to a G-only ed25519 parser, aborting with a raw strkey DecodeError. Because this lives in the shared pipeline, contract invoke --source-account M… hits the same failure — it is not specific to token transfer.
Direction
stellar-xdr already provides xdr::MuxedAccount::account_id(). The pipeline should use the underlying AccountId (e.g. config.source_account()?.account_id().to_string()) for the sequence-number lookup and the classic transaction source in build_invoke_contract_tx, while the muxed form keeps flowing into the SEP-41 transfer(from, …) argument so the mux id is preserved on-chain / in events.
Acceptance
--source-account M…/--from M…works end-to-end through simulate → sign → submit.- Add an integration test with an
M…source (signing via an identity /--sign-with-*, since an M-literal carries no secret).
Notes
Pre-existing limitation, not a regression from #2644. Until this lands, token transfer may want a clear "muxed source not yet supported" guard error instead of the raw DecodeError.
Part of the "Improve Agent UX for Wallets" epic (#2620).
- Dominant language
- Rust
- Stars
- 123
- Forks
- 141
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 17
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stellar/stellar-cli
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
stellar/stellar-cli#2384 · 2 comments ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
stellar/stellar-cli#2347 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 68/100
stellar/stellar-cli#2723 ·
-
Difficulty 3/5 1-2 days Newbie friendliness 72/100
stellar/stellar-cli#2722 ·
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
stellar/stellar-cli#2703 ·
All issues in stellar/stellar-cli
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
kwakseongjae/auto-hwp#319 ·
-
area:cli bug filter-quality good first issue priority:medium
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
Difficulty 1/5 Under an hour Newbie friendliness 72/100
bevyengine/bevy#25861 ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
enhancement remote
Difficulty 2/5 1-3 hours Newbie friendliness 68/100