feat(standards): Add `DelayedExecution` (Timelocked Accounts) to `AuthMultisigSmart` by onurinanc · Pull Request #3044 · 0xMiden/protocol

onurinanc · 2026-06-04T11:22:20Z

Closes: #3043.

Previously opened a draft PR implementing all features regarding Smart Multisig here: #2973. That PR still relatively big, and we separate the delayed execution logic into this PR.

…ution' into onur-multisig-smart-delayed-execution

PhilippGackstatter

I left a few questions/comments/nits. Overall, I'm having a hard time wrapping my head around this PR. In particular:

it seems we have multiple names for the same concept - would be great to unify.
I find the use of the pending slots hard to follow, and I'm not sure I understand why we need these. I left a question/suggestion to use auth args instead.
I don't understand why we need the cancel_and_propose functionality when we already have the individual cancel and propose.

PhilippGackstatter · 2026-06-08T08:20:55Z

+# Map entries: [TX_HASH] -> [unlock_timestamp, proposal_timestamp, min_cancel_sigs, 1]
+const TX_PROPOSALS_SLOT = word("miden::standards::auth::multisig_smart::tx_proposals")


Nit: I'd call this TX_SUMMARY_COMMITMENT instead of TX_HASH for accuracy (everywhere it is used in this PR).

PhilippGackstatter · 2026-06-08T08:32:58Z

+#! Loads the delayed execution policy configuration from `DELAYED_EXECUTION_SLOT`.
+#!
+#! Inputs:  []
+#! Outputs: [min_delay, propose_expiration_delta, 0, 0]


Nit: Returning the zeros is unnecessary.

PhilippGackstatter · 2026-06-08T08:42:01Z

+proc get_propose_expiration_delta
+    exec.get_delayed_execution
+    # => [min_delay, propose_expiration_delta, 0, 0]


Suggested change

proc get_propose_expiration_delta

exec.get_delayed_execution

# => [min_delay, propose_expiration_delta, 0, 0]

proc get_propose_expiration_delta

exec.get_delayed_execution_config

# => [min_delay, propose_expiration_delta, 0, 0]

Nit: Maybe the current procedure name could be a bit clearer.

PhilippGackstatter · 2026-06-08T08:44:13Z

+proc apply_expiration_delta
+    dup neq.0 assert.err=ERR_EXPIRATION_DELTA_ZERO
+    # => [expiration_delta]
+
+    exec.tx::update_expiration_block_delta
+    # => []
+
+    exec.tx::get_expiration_block_delta
+    # => [tx_expiration_delta]
+
+    dup neq.0 assert.err=ERR_TX_EXPIRATION_DELTA_NOT_SET
+    # => [tx_expiration_delta]
+
+    drop
+    # => []
+end


I don't understand why we set and then get the delta - this seems redundant. The neq.0 check is already done in tx::update_expiration_block_delta (but it is not documented in a Panics if section - if you don't mind, we could add it in this PR).

So, I think the whole procedure can be removed in favor of calling tx::update_expiration_block_delta directly.

PhilippGackstatter · 2026-06-08T11:28:12Z

+#! Finalizes a pending cancel action for the current transaction.
+#!
+#! Inputs:  [num_verified_signatures, TX_HASH]
+#! Outputs: [num_verified_signatures, TX_HASH]


Does this procedure use TX_HASH? If not, can we remove it from the inputs/outputs? I'd also pass in num_verified_signatures but not return it. Caller should dup it.

PhilippGackstatter · 2026-06-08T11:36:50Z

+#! Marks that this tx intends to execute a proposed action.
+#!
+#! Inputs:  []
+#! Outputs: []
+#!
+#! Panics if:
+#! - `PENDING_EXECUTE_SLOT` is already non-empty (`ERR_PENDING_ALREADY_SET`).
+#!
+#! Side effects:
+#!   - Writes `PENDING_EXECUTE_FLAG` to `PENDING_EXECUTE_SLOT`.
+#!
+#! Invocation: exec
+pub proc execute_proposed_transaction


Is the use of this procedure to communicate to the auth procedure that the current transaction executed a proposed action? It seems like this is intended to be called from a tx script, which is arbitrarily provided by the tx executor.

If so, can we not achieve the same by passing a flag as AUTH_ARGS? And if so, can we get rid of all the pending slots by using this pattern?

I think the same pattern needs to stay for propose/cancel, so it might be good keeping execute on the same pattern for symmetry. I'm not sure if removing all the pending slots by using the AUTH_ARGS pattern works.

PhilippGackstatter · 2026-06-08T11:37:49Z

+#! Returns the pending execute transaction summary hash, or `EMPTY_WORD` if none is set.
+#!
+#! Inputs:  []
+#! Outputs: [PENDING_EXECUTE_HASH]
+#!
+#! Where:
+#! - PENDING_EXECUTE_HASH is the pending execute transaction summary hash, or
+#!   `EMPTY_WORD` if no execute action is pending.
+#!
+#! Invocation: exec
+proc get_pending_execute


Is this procedure description accurate? In set_pending_execute we write PENDING_EXECUTE_FLAG and not a HASH, so there is a mismatch.

PhilippGackstatter · 2026-06-08T11:38:36Z

+#!   - Writes `NEW_TX_HASH` to `PENDING_PROPOSE_SLOT`.
+#!
+#! Invocation: exec
+pub proc cancel_and_propose_new_transaction


Is the functionality of this procedure not the same as calling cancel and then propose? Why do we need a single procedure for this?

Commented here now: #3043 (comment)

PhilippGackstatter · 2026-06-08T11:46:22Z

+    exec.delayed_execution::finalize_timelock_proposals
+    # => [TX_SUMMARY_COMMITMENT]


Given that we clear the pending slots as the last step, the tx summary we computed earlier contains the changes to the pending slots. This works in principle, but feels a bit unclean. Mentioning in case this was not intended.

PhilippGackstatter · 2026-06-10T07:20:08Z

+#! Panics if:
+#! - block_height_delta is not a valid `u32` (`ERR_TX_INVALID_EXPIRATION_DELTA`).
+#! - block_height_delta is zero (`ERR_TX_INVALID_EXPIRATION_DELTA`).
+#! - block_height_delta is greater than 0xFFFF (`ERR_TX_INVALID_EXPIRATION_DELTA`).


Nit: We usually don't mention the exact error variants.

PhilippGackstatter · 2026-06-10T07:54:37Z

+pub proc cancel_transaction_proposal
+    dupw
+    # => [TX_SUMMARY_COMMITMENT, TX_SUMMARY_COMMITMENT]
+
+    exec.is_tx_proposed
+    # => [is_proposed, TX_SUMMARY_COMMITMENT]
+
+    assert.err=ERR_TX_NOT_PROPOSED
+    # => [TX_SUMMARY_COMMITMENT]
+
+    exec.set_pending_cancel
+    # => []
+end


Afaict, propose_transaction and cancel_transaction_proposal are both essentially setters for their provided arguments; writing into a temporary storage slot. The arguments come from a tx script, which is constructed by a user. The main work is done in the auth procedure, which reads the slots, enforces delay constraints and updates the maps.

If we do not need these procedures to be called from a note, which I assume is not the case, we could reduce complexity by a lot by removing these procedures and setting AUTH_ARGS to the hash of the following data:

[delay_action, CANCEL_TX_SUMMARY_COMMITIMENT, PROPOSE_TX_SUMMARY_COMMITIMENT, SALT]

where delay_action is one of {execute, propose, cancel}. We then dispatch based on delay_action.

That way, we could handle all logic in one flow within the auth procedure rather than splitting it across a pre-auth and a post-auth phase, and avoid having three temporary storage slots.

Whether the user of the multisig constructs a tx script and calls these APIs or whether they construct AUTH_ARGS in the above way should be essentially equivalent.

Any thoughts? Would this work?

If we do not need these procedures to be called from a note, which I assume is not the case, we could reduce complexity by a lot by removing these procedures and setting AUTH_ARGS to the hash of the following data:

I was thinking that we might somehow extend delayed execution logic into note-based auth, however, as I explore more about this I've seen that it's not possible to use the same logic as this design requires num_signatures, and this is not the case for owner controlled and rbac.

So, although I believe the current design is easier to read, your proposed way of constructing AUTH_ARGS reduces the complexity, and API calls are easier to use. So, it seems it is better to switch to your proposed design.

Since this is a bigger refactor, I'd wait for @bobbinth or @mmagician's input before executing on this.

Any updates on the possible refactoring item? @bobbinth @mmagician

I haven't gotten into the review yet - but @onurinanc - what's the best place to get the overall design approach from? I remember we had a long discussion a while back, but I've forgotten some important aspects since then, and other aspects have probably changed. So, it may be helpful to have a summary of how the overall mechanism is supposed to work.

Agreed that monitoring is required - but I think that's the case anyways. Even if prohibit re-proposing canceled proposals, the attacker could modify the proposal slightly (e.g., use a different salt, or maybe make some other trivial change to the proposal) and make a new proposal which would have a different commitment but would be semantically the same. So, AFAICT, there isn't really a way to get away from the need to monitor.

I think proposed design doesn't work since propose_transaction would need to verify the signatures over the proposed transaction's commitment, but signature verification can only run against the current transaction.

When verify_signatures runs, it goes through the AuthRequest event, and the kernel reconstructs the transaction summary from the current transaction (from account delta, input/output notes) and rejects the message if those commitments don't match. So the signed message is always pinned to the current transaction.

This breaks the design in two ways:

The proposed transaction's delta (its future storage changes) differs from the proposing transaction's delta (just the proposals-map write), so the kernel's summary check fails, so you can't verify signatures over the proposed transaction from inside the proposing one.

The account delta is only final at the end of the transaction, in the auth procedure. Calling verify_signatures mid-transaction inside propose_transaction sees an incomplete delta. Signature verification structurally has to happen in auth, after all state changes.

So having the proposal verify the proposed transaction isn't possible by reusing the current signature verification. Since signature verification has to run in auth (where the delta is final), it ends up signing the current transaction, which is exactly why the "pending & finalizer" and "auth_args" designs sign the proposing transaction.

I think proposed design doesn't work since propose_transaction would need to verify the signatures over the proposed transaction's commitment, but signature verification can only run against the current transaction.

Ah - good point! I think this is an unfortunate limitation of the current approach - but we may be able to modify this relatively easily.

Refreshing my memory a bit, it seems like we require tx summary to be built even if the signature is found in the advice provider. This shouldn't be strictly needed: if the signature is already in the advice provider, AFAICT, there is no real need to build the tx summary.

So, the change may be as simple as modifying the TransactionEvent::AuthRequest variant to look like:

AuthRequest { pub_key_commitment: PublicKeyCommitment, tx_summary: Option<TransactionSummary>, signature: Option<Vec<Felt>>, }

Or maybe something more "strongly typed" as we really can have either tx_summary or signature - but don't really need to have both.

@PhilippGackstatter - what do you think?

Agreed, that should work.

Or maybe something more "strongly typed" as we really can have either tx_summary or signature - but don't really need to have both.

We can add the either crate so we can write this as:

AuthRequest { pub_key_commitment: PublicKeyCommitment, signature_or_summary: Either<Vec<Felt>, TransactionSummary>, }

We'd only call extract_tx_summary if the signature is None.

I've implemented this in #3157 - though, instead of using Either just created a TxSummaryOrSignature enum.

partylikeits1983

Looks great! Left two comments below

partylikeits1983 · 2026-06-24T14:32:09Z

+#! High-impact action.
+#!


Nit:

Suggested change

#! High-impact action.

#!

partylikeits1983 · 2026-06-24T15:39:42Z

+pub proc update_delayed_execution_policy
+    u32assert.err=ERR_MIN_DELAY_NOT_U32
+    dup eq.0 assertz.err=ERR_MIN_DELAY_ZERO
+    # => [min_delay, propose_expiration_delta]
+
+    swap u32assert.err=ERR_PROPOSE_EXPIRATION_DELTA_NOT_U32
+    dup eq.0 assertz.err=ERR_PROPOSE_EXPIRATION_DELTA_ZERO
+    # => [propose_expiration_delta, min_delay]


We should add an assertion here that propose_expiration_delta is a valid u16.

This procedure only checks that propose_expiration_delta is a u32 and non-zero, so it accepts any value up to 4294967295.

But the value set here is later passed into the kernel's tx::update_expiration_block_delta, which only accepts deltas in the range 1 to 65535. Every propose_transaction (and cancel_and_propose_new_transaction) calls that kernel proc, so:

It's possible to set the policy with propose_expiration_delta >= 65536; this succeeds and writes the value to storage.

From then on, every propose_transaction panics in the kernel with ERR_TX_INVALID_EXPIRATION_DELTA, because the stored delta is above 65535.

The result is that the whole propose flow would be bricked in this case until someone calls update_delayed_execution_policy again with a valid value (this proc never touches the kernel, so it's recoverable, not permanently stuck).

This isn't really an issue because the rust DelayedExecutionPolicy stores the field as a u16 (max 65535), so an out-of-range value can only get in via a direct MASM call.

partylikeits1983 · 2026-06-24T15:44:45Z

+    add
+    # => [unlock_timestamp, proposal_timestamp]
+end


We should have a check here which asserts the resulting unlock_timestamp is a u32

…sent

…ution' into onur-multisig-smart-delayed-execution

…elayed-execution

PhilippGackstatter

Looks good! Only got through the main file delayed_execution.masm but not yet the rest. Left a few small comments, but nothing too important. Will review the rest soon.

PhilippGackstatter · 2026-06-30T13:42:10Z

+proc get_tx_proposal(tx_summary_commitment: word)
+    push.TX_PROPOSALS_SLOT[0..2]
+    # => [slot_prefix, slot_suffix, TX_SUMMARY_COMMITMENT]
+
+    exec.active_account::get_map_item
+    # => [unlock_timestamp, proposal_timestamp, min_cancel_sigs, 0]
+
+    movup.3 drop
+    # => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]
+end


Would there be a downside if we used get_initial_map_item here? I suppose it's safe to leave it as-is, but might be even safer to rely on the initial state.

PhilippGackstatter · 2026-06-30T13:44:58Z

+    push.EMPTY_WORD
+    # => [EMPTY_WORD, TX_SUMMARY_COMMITMENT]
+
+    swapw
+    # => [TX_SUMMARY_COMMITMENT, EMPTY_WORD]
+
+    push.TX_PROPOSALS_SLOT[0..2]
+    # => [slot_prefix, slot_suffix, TX_SUMMARY_COMMITMENT, EMPTY_WORD]
+
+    exec.native_account::set_map_item
+    # => [OLD_PROPOSAL_WORD]
+
+    dropw
+    # => []


Nit/Optional: Should we call write_tx_proposal here with push.0.0.0?

PhilippGackstatter · 2026-06-30T13:47:28Z

+    exec.tx::get_block_timestamp
+    # => [proposal_timestamp]


Just pointing out that we usually use block numbers rather than timestamps. I generally think the latter is easier to work with for users, but we mostly use block numbers now, so may be best for consistency, cc @bobbinth.

PhilippGackstatter · 2026-06-30T13:52:48Z

+#! - `assert_unlock_reached` fails.
+#!
+#! Invocation: exec
+proc enforce_tx_timelock


Suggested change

proc enforce_tx_timelock

proc assert_tx_proposed_and_unlocked

nit: use "assert" phrasing

PhilippGackstatter · 2026-06-30T13:53:53Z

+    # => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]
+
+    dup.1 neq.0 assert.err=ERR_TX_NOT_PROPOSED
+    # => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]
+
+    swap drop
+    # => [unlock_timestamp, min_cancel_sigs]


Suggested change

# => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]

dup.1 neq.0 assert.err=ERR_TX_NOT_PROPOSED

# => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]

swap drop

# => [unlock_timestamp, min_cancel_sigs]

# => [unlock_timestamp, proposal_timestamp, min_cancel_sigs]

swap neq.0 assert.err=ERR_TX_NOT_PROPOSED

# => [unlock_timestamp, min_cancel_sigs]

PhilippGackstatter · 2026-06-30T14:05:22Z

+pub proc cancel_transaction_proposal
+    # => [TX_SUMMARY_COMMITMENT]


Suggested change

pub proc cancel_transaction_proposal

# => [TX_SUMMARY_COMMITMENT]

pub proc cancel_transaction_proposal

PhilippGackstatter · 2026-06-30T14:06:27Z

+    dup.1 neq.0 assert.err=ERR_TX_NOT_PROPOSED
+    # => [unlock_timestamp, proposal_timestamp, min_cancel_sigs, TX_SUMMARY_COMMITMENT]
+
+    drop drop movdn.4
+    # => [TX_SUMMARY_COMMITMENT, min_cancel_sigs]


Suggested change

dup.1 neq.0 assert.err=ERR_TX_NOT_PROPOSED

# => [unlock_timestamp, proposal_timestamp, min_cancel_sigs, TX_SUMMARY_COMMITMENT]

drop drop movdn.4

# => [TX_SUMMARY_COMMITMENT, min_cancel_sigs]

drop neq.0 assert.err=ERR_TX_NOT_PROPOSED

# => [min_cancel_sigs, TX_SUMMARY_COMMITMENT]

movdn.4

# => [TX_SUMMARY_COMMITMENT, min_cancel_sigs]

PhilippGackstatter · 2026-06-30T14:09:25Z

+#! Inputs:  [TX_SUMMARY_COMMITMENT]
+#! Outputs: [TX_SUMMARY_COMMITMENT]
+#!
+#! Where:
+#! - TX_SUMMARY_COMMITMENT is the current transaction summary commitment.
+#!
+#! Panics if:
+#! - no proposal exists for `TX_SUMMARY_COMMITMENT` (`ERR_TX_NOT_PROPOSED`).
+#! - the proposal unlock timestamp has not been reached (`ERR_TX_STILL_TIMELOCKED`).
+#!
+#! Invocation: exec
+pub proc handle_execute


I'd maybe call this execute_proposed_tx.

Consider not returning TX_SUMMARY_COMMITMENT as it is identical to the input and we try to avoid this pattern.

PhilippGackstatter · 2026-06-30T14:10:22Z

+    # => [TX_SUMMARY_COMMITMENT]
+    dupw exec.enforce_tx_timelock drop
+    # => [TX_SUMMARY_COMMITMENT]


This is the only caller of enforce_tx_timelock and it drops its return value, so we can probably remove the return value from the procedure itself.

PhilippGackstatter · 2026-07-01T08:45:45Z

+    push.0 exec.active_account::get_num_procedures
+    # => [num_procedures, requires_delay_acc]
+
+    dup neq.0
+    # => [should_continue, num_procedures, requires_delay_acc]


I'd use neq.1 as the loop condition so we naturally exclude the auth procedure and don't need to consider the auth procedure in the loop at all.

PhilippGackstatter · 2026-07-01T08:46:40Z

+        dup.1 exec.active_account::get_procedure_root
+        # => [PROC_ROOT, is_non_auth, proc_index, requires_delay_acc]
+
+        exec.native_account::was_procedure_called
+        # => [was_called, is_non_auth, proc_index, requires_delay_acc]
+
+        and
+        # => [should_process, proc_index, requires_delay_acc]
+
+        if.true
+            dup exec.active_account::get_procedure_root
+            # => [PROC_ROOT, proc_index, requires_delay_acc]


Nit: For efficiency, avoid calling get_procedure_root twice and keep the PROC_ROOT on the stack instead.

PhilippGackstatter · 2026-07-01T08:52:08Z

+#! Inputs:  []
+#! Outputs: [requires_delay]
+#!
+#! The auth procedure (procedure index 0) is excluded, consistent with `compute_called_proc_policy`.
+#!
+#! Invocation: exec


Nit: I'd move this to the "prose section" above the Inputs/Outputs.

PhilippGackstatter · 2026-07-01T09:08:34Z

    exec.enforce_note_restrictions
+    # => [policy_threshold, policy_requires_delay]
+
+    swap drop
    # => [policy_threshold]


We now drop the policy_requires_delay value computed by compute_proc_policy_contribution, so we should refactor that procedure so it becomes simpler.

…elayed-execution

PhilippGackstatter

Looks good to me! Left a few suggestions to make the implementation clearer, but logically I think it is good.

PhilippGackstatter · 2026-07-03T08:09:00Z

+pub proc propose_transaction
+    # => [TX_SUMMARY_COMMITMENT]
+    dupw exec.is_tx_proposed assertz.err=ERR_TX_ALREADY_PROPOSED
+    # => [TX_SUMMARY_COMMITMENT]


Afaiu, it is currently possible to propose a transaction that was already executed, but it would fail during execution due to multisig::assert_new_tx.

Not sure if it's really worth it, but I think I would add a check here that the proposed transaction is not in EXECUTED_TXS_SLOT to prevent this. Or if not, leave a comment here somewhere to mention the above.

I was also thinking that we could technically avoid the need for both EXECUTED_TXS_SLOT and TX_PROPOSALS_SLOT because we could use the latter to store a flag to indicate that a tx was executed. But, it's not clear that this provides meaningful savings (one slot saved) and the current setup is cleaner by keeping proposals separate from executed transactions (which also apply to txs executed immediately). So, basically, I wouldn't change anything about this.

PhilippGackstatter · 2026-07-03T08:15:04Z

+            # PROC_ROOT is still on the stack; reuse it for the policy lookup.
            exec.get_procedure_policy
-            # => [immediate, delayed, restr_proc, proc_index, threshold_acc, requires_delay_acc, restrictions_acc]
+            # => [immediate, delayed, restr_proc, proc_index, threshold_acc, restrictions_acc]


Suggested change

# => [immediate, delayed, restr_proc, proc_index, threshold_acc, restrictions_acc]

# => [immediate, delayed, note_restrictions, proc_index, threshold_acc, restrictions_acc]

nit: standard terminology

PhilippGackstatter · 2026-07-03T08:26:23Z

+    exec.delayed_execution::is_delay_action_only
+    not
+    # => [is_execution, TX_SUMMARY_COMMITMENT]


Suggestion: It might be a bit cleaner overall to have:

exec.delayed_execution::was_propose_or_cancel_called # => [is_propose_or_cancel, TX_SUMMARY_COMMITMENT] if.true # assert that no other procedure besides propose or cancel was called exec.tx_policy::assert_only_one_non_auth_procedure_called else # execution path # ... end

where was_propose_or_cancel_called is like is_delay_action_only now but without the assert_only_one_non_auth_procedure_calledcall.

This removes the branch from is_delay_action_only and reuses the branch that we need here anyway, effectively removing one branch. It also makes it a bit clearer that we enforce that no other procedure was called, which is currently a bit hidden.

PhilippGackstatter · 2026-07-03T08:35:31Z

+            # `execute_proposed_tx` consumes the commitment; keep a copy so both branches leave
+            # [TX_SUMMARY_COMMITMENT] on the stack.


Suggested change

# `execute_proposed_tx` consumes the commitment; keep a copy so both branches leave

# [TX_SUMMARY_COMMITMENT] on the stack.

nit

PhilippGackstatter · 2026-07-03T08:37:40Z

+        if.true
+            # `execute_proposed_tx` consumes the commitment; keep a copy so both branches leave
+            # [TX_SUMMARY_COMMITMENT] on the stack.
+            dupw exec.delayed_execution::execute_proposed_tx


nit: I suggested this name but I still don't really like it as it doesn't quite capture what the procedure does (assert timestamp reached, remove from proposals), but I don't really have a better suggestion either.

PhilippGackstatter · 2026-07-03T09:17:47Z

+    let mut tx_context_init_builder = mock_chain
+        .build_tx_context(account_id, &[], &[])?
+        .tx_script(tx_script.clone())
+        .auth_args(salt);
+
+    if let Some(tx_script_args) = tx_script_args {
+        tx_context_init_builder = tx_context_init_builder.tx_script_args(tx_script_args);
+    }
+
+    if let Some(advice_inputs) = advice_inputs.clone() {
+        tx_context_init_builder = tx_context_init_builder.extend_advice_inputs(advice_inputs);
+    }
+
+    let tx_summary = tx_context_init_builder
+        .build()?
+        .execute()
+        .await
+        .unwrap_err()
+        .unwrap_unauthorized_err();
+
+    let msg = tx_summary.as_ref().to_commitment();
+    let tx_summary = SigningInputs::TransactionSummary(tx_summary);
+
+    let mut tx_context_signed_builder = mock_chain
+        .build_tx_context(account_id, &[], &[])?
+        .tx_script(tx_script)
+        .auth_args(salt);


Here I would also build the tx just once and clone the builder to avoid the duplication.

PhilippGackstatter · 2026-07-03T09:25:50Z

+#[rstest]
+#[case::ecdsa(AuthScheme::EcdsaK256Keccak)]
+#[case::falcon(AuthScheme::Falcon512Poseidon2)]
+#[tokio::test]
+async fn test_multisig_smart_delayed_only_proc_rejects_direct_path_without_proposal(


I think the benefit of running these with two signature schemes is fairly little but it costs quite a bit in test execution time, especially the falcon version, so I'd just default to the ecdsa variant. I think the two schemes are sufficiently tested in hybrid_multisig, so I'd remove this from all tests here.

PhilippGackstatter · 2026-07-03T09:31:05Z

+/// An unauthorized dry-run of a procedure must still yield its `TX_SUMMARY_COMMITMENT` (so a caller
+/// can obtain the commitment to propose). With no proposal present the execution mode is immediate;
+/// because the procedure's policy also permits the immediate path, execution reaches the
+/// signature/threshold check and aborts with `Unauthorized` (carrying the summary) rather than
+/// panicking at the policy layer.
+#[rstest]
+#[case::ecdsa(AuthScheme::EcdsaK256Keccak)]
+#[case::falcon(AuthScheme::Falcon512Poseidon2)]
+#[tokio::test]
+async fn test_multisig_smart_unauthorized_dry_run_returns_tx_summary(


This is implicitly tested by all tests that extract a tx summary, so imo we can remove this test.

PhilippGackstatter · 2026-07-03T09:36:42Z

+    match result {
+        Err(TransactionExecutorError::TransactionProgramExecutionFailed(_)) => {},
+        Err(err) => panic!("expected transaction program failure, got: {err}"),
+        Ok(_) => panic!("bundling a delay action with another procedure must fail"),
+    }


I think we should be more precise with the assertion using assert_transaction_executor_error!.

PhilippGackstatter · 2026-07-03T10:50:55Z

+    let mut mock_chain =
+        MockChainBuilder::with_accounts([multisig_account.clone()]).unwrap().build()?;
+
+    // The execute transaction the proposal is for: in option 4 it just calls the real procedure;


nit: another reference to "option 4"

onurinanc added 9 commits June 4, 2026 12:09

add delayed execution logic

40bbb1d

fix comments

1b10a8c

add PR to changelog

70bf840

Merge branch 'next' into onur-multisig-smart-delayed-execution

d491005

fix missing comments

d1857a2

Merge remote-tracking branch 'origin/onur-multisig-smart-delayed-exec…

7e55100

…ution' into onur-multisig-smart-delayed-execution

add tests

136bea3

add more tests

d4bb726

remove optional delayed execution

216f8f4

onurinanc requested review from PhilippGackstatter and bobbinth June 4, 2026 15:33

PhilippGackstatter reviewed Jun 8, 2026

View reviewed changes

mmagician requested a review from Fumuran June 8, 2026 16:18

onurinanc added 5 commits June 9, 2026 14:03

merge next

5c3ee65

nits

4210460

remove apply_propose_expiration_delta

30787c3

update comments

58a265e

Merge branch 'next' into onur-multisig-smart-delayed-execution

eef73f2

onurinanc requested a review from PhilippGackstatter June 9, 2026 15:27

PhilippGackstatter reviewed Jun 10, 2026

View reviewed changes

partylikeits1983 reviewed Jun 24, 2026

View reviewed changes

onurinanc added 7 commits June 26, 2026 14:46

skip tx-summary reconstruction in AuthRequest when a signature is pre…

a99bb0b

…sent

refactor delayed execution proposals logic

7bb3658

fix comments

3bce0a4

fix comments

60dba7d

merge next

dd44e96

Merge remote-tracking branch 'origin/onur-multisig-smart-delayed-exec…

a611cc7

…ution' into onur-multisig-smart-delayed-execution

add timestamp assertions

79ce84f

onurinanc requested review from PhilippGackstatter and partylikeits1983 June 26, 2026 15:08

bobbinth mentioned this pull request Jun 28, 2026

Update AuthRequest event to carry either signature or TX summary #3157

Merged

onurinanc added 2 commits June 29, 2026 13:51

merge next

1739f74

Merge remote-tracking branch 'origin/next' into onur-multisig-smart-d…

7df203c

…elayed-execution

PhilippGackstatter reviewed Jun 30, 2026

View reviewed changes

PhilippGackstatter reviewed Jul 1, 2026

View reviewed changes

onurinanc added 5 commits July 2, 2026 12:44

use is_tx_proposed instead of compute_requires_delay

eefca72

apply suggestions

4473cfc

Merge remote-tracking branch 'origin/next' into onur-multisig-smart-d…

9d13778

…elayed-execution

add @account_procedure

ac19c45

clippy

602181c

onurinanc requested a review from PhilippGackstatter July 2, 2026 14:55

merge next

c176063

PhilippGackstatter approved these changes Jul 3, 2026

View reviewed changes

onurinanc added 2 commits July 3, 2026 15:54

apply suggestions

c063086

Merge branch 'next' into onur-multisig-smart-delayed-execution

efb0765

		# Map entries: [TX_HASH] -> [unlock_timestamp, proposal_timestamp, min_cancel_sigs, 1]
		const TX_PROPOSALS_SLOT = word("miden::standards::auth::multisig_smart::tx_proposals")

		exec.delayed_execution::finalize_timelock_proposals
		# => [TX_SUMMARY_COMMITMENT]

	proc enforce_tx_timelock
	proc assert_tx_proposed_and_unlocked

		pub proc cancel_transaction_proposal
		# => [TX_SUMMARY_COMMITMENT]

	# => [immediate, delayed, restr_proc, proc_index, threshold_acc, restrictions_acc]
	# => [immediate, delayed, note_restrictions, proc_index, threshold_acc, restrictions_acc]

		# `execute_proposed_tx` consumes the commitment; keep a copy so both branches leave
		# [TX_SUMMARY_COMMITMENT] on the stack.

Uh oh!

Conversation

onurinanc commented Jun 4, 2026

Uh oh!

PhilippGackstatter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PhilippGackstatter Jun 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

partylikeits1983 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PhilippGackstatter left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PhilippGackstatter Jun 10, 2026 •

edited

Loading