Create proposal flow

[dewabisma]

Summary

Added proposal creation feature. This encompass the whole step of picking recipient, inputing amount, reviewing, and pending proposal submission.

We also show the proposal created event in propose account activity as to not confuse proposer by balance being deducted.

Screenshots

• Multisig home

• Proposal details sheet

• Proposal details sheet

• Select recipient

• Input amount

• Review proposal

• After review done

[cursor]

Bugbot is paused — on-demand spend limit reached

Bugbot uses usage-based billing for this team and has hit its on-demand spend limit.

A team admin can raise the spend limit in the Cursor dashboard, or wait for the next billing cycle to continue.

[n13]

Review: Create proposal flow (PR #507)

Reviewed in an isolated worktree diffed against the actual base branch beast/discover-multisig-flow (not main). 56 files, +3665 / -1406.

Overall

A strong, well-structured PR. It replaces the previous dummy/stub multisig proposal code with a real indexer-backed flow: pick recipient → enter amount → review → optimistic pending → poll indexer → confirm. DRY discipline is excellent and test coverage for the new logic is solid. A few things are worth addressing before merge.

What's great

• Stubs fully replaced — getOpenProposals / getPastProposals / getProposal / estimateProposeFee / propose now hit real GraphQL/chain calls; all the _dummy* data and _dummyCurrentBlock magic is gone.
• Genuine DRY wins — appendConfirmedEventToHistory is shared by both creation and proposal reconciliation; new shared widgets (DetailSummaryRow, ProposalListTile, MultisigExpiryValue) and the MultisigProposalGraphql field constants remove real duplication.
• Correct balance accounting — proposer's pending outgoing is memberCost (network fee + deposit + pallet fee) and correctly excludes the transfer amount, which leaves the multisig account.
• Logging migration — chain_history_service moves from print to developer.log with error/stackTrace.
• Good tests — dedup behavior, indexer JSON parsing, unknown-status handling, the fee formula, and ProposeFeeBreakdown.memberCost are all covered.

Issues worth addressing

1. Nested submission retries → duplicate-proposal risk (medium)

In transaction_submission_service.dart, _submitProposalBackground retries service.propose(...) up to 3×. But propose → submitExtrinsic already retries 3× internally (quantus_sdk/lib/src/services/substrate_service.dart:172).

Each attempt fetches a fresh nonce (system_accountNextIndex, which counts pooled txs). If a submit lands on-chain but the response read fails, a retry re-submits at the next nonce → a second proposal that reserves another deposit + burns another fee. For a non-idempotent, deposit-reserving extrinsic this nesting (up to 9 attempts) is risky.

Suggestion: drop the outer retry, or short-circuit once an extrinsic hash has been obtained.

2. Fee-fetch fallback masks failure (medium — conflicts with the "fail early, no silent fallback" rule)

In propose_amount_screen.dart _fetchFee, the catch builds a ProposeFeeBreakdown with networkFee: BigInt.zero and sets _hasFee = true, so the user can proceed with an under-reported member cost (and the pending balance deduction is too low). It only debugPrints the error.

Suggestion: surface an error / keep submit disabled rather than falling back to a zero-fee estimate.

3. Circular import between model and service (low)

multisig_proposal.dart now imports multisig_service.dart (for MultisigService.proposalCreationFeeFor in the palletFee getter and parseStatus logging), while multisig_service.dart imports the model. It compiles, but it inverts the usual model→service direction.

Suggestion: move the fee formula to a constants/util the model can depend on to break the cycle.

Nits

• _onAmountFocusChanged uses Future.delayed(300ms) then Scrollable.ensureVisible — borderline against the "avoid post-frame callbacks" rule; a fixed delay for scroll-into-view tends to be flaky.
• MultisigService holds both an instance _palletConstants and a static _feeConstants (both Constants()); minor redundancy.
• multisig_service_test re-hardcodes the 10000 step factor rather than reading service.signerStepFactor — fine as a guard, slightly tautological.

Confirm intentional

• Ephemeral ngrok endpoints in app_constants.dart (rpcEndpoints / graphQlEndpoints) are bumped to new ngrok tunnels. The base branch already used ngrok, so this looks like the testnet workflow — just make sure these never ride along to main.
• The approve/cancel screens are deleted (approve_proposal_screen, approve_confirm_sheet, approve_done_screen, cancel_confirm_sheet) and replaced by a read-only detail sheet with "signing coming soon". No dangling references remain. Since those previously ran on dummy data, this is a sensible interim step — just confirming the temporary loss of approve UI is expected.

Note

Did not run flutter analyze / tests in the worktree (fresh worktree without .dart_tool / generated FRB bindings), so this is a static read.