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

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"

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

bobbinth · 2026-07-11T23:26:17Z

I tried to resolve merge conflicts which resulted in some failures. I was able to fix the build issues pretty easily, but tests are still failing and I didn't look deep enough into them to try to fix them.

bobbinth · 2026-07-11T23:26:38Z

+#! Outputs: [num_verified_signatures, MSG]
+#!
+#! Invocation: exec
+pub proc verify_signatures


We could replace lines 847-854 with a call to this procedure - right?

bobbinth · 2026-07-11T23:34:21Z

+pub struct DelayedExecutionPolicy {
+    min_delay: u32,
+    propose_expiration_delta: u16,
+}


I maybe forgetting this, but why do we need propose_expiration_delta?

Also, shouldn't min_delay be in blocks?

onurinanc · 2026-08-05T14:46:49Z

Update:

Now that #3383 binds the reference block commitment and the expiration block delta into the signed transaction summary, the delayed-execution flow needs a small design change. This comment explains why and proposes a change in the design.

Before #3383, the transaction summary commitment was:

TX_SUMMARY_COMMITMENT = hash(account_delta, input_notes, output_notes, user_params)

It was independent of the reference block. After #3383 it also binds the block and expiration:

TX_SUMMARY_COMMITMENT = hash(account_delta, input_notes, output_notes, BLOCK_COMMITMENT, expiration_delta, user_params)

A delayed transaction is proposed at one block and executed later, at a different block, and the delayed-execution flow currently keys a proposal on the transaction summary commitment and recomputes that same commitment at execute time to look the proposal.

With the change binding block into the commitment, the value computed at propose time, never equals the value computed at execute time, so the lookup fails and the timelock and consume step never runs.

Proposed design:

We can keep the TX_SUMMARY_COMMITMENT exactly as #3383 defines it for signature verification, and introduce a second, block-independent commitment that identifies what the transaction does, used only as the proposal key:

ACTION_COMMITMENT = hash(account_delta, input_notes, output_notes, user_params)
                    # i.e. the tx summary with BLOCK_COMMITMENT and expiration_delta are zero

The reference block and expiration are execution context, not part of the transaction's intent, so excluding them is both necessary so that propose and execute agree on the commitment. The account delta, input and output notes, and user parameters constitutes ACTION_COMMITMENT, so the action's identity is still works.

At execute time the auth procedure computes both commitments from the same summary: the full one for signature verification, and the action commitment to match the proposal. To make this happen:

Add a hash_action_commitment helper that hashes the six summary words with the block commitment and expiration delta zeroed out, so the result identifies what a transaction does, independent of when it runs.
Derive both commitments from the same summary: look up proposals by the action commitment (is_tx_proposed, assert_and_consume_proposal), and keep verifying signatures against the full tx-summary commitment.
multisig_smart/delayed_execution.masm: proposals are now stored under the action commitment, and that's what cosigners sign.
TransactionSummary::action_commitment() in miden-protocol as the Rust equivalent, so proposers and tests derive the same value as the MASM helper.

Note on signatures:

Because signature verification stays over the block bounded summary, the execute transaction verifies fresh signatures over its own summary, while the proposal is authorized by signatures over the action commitment. So the proposal and the execution are authorized independently: the proposal proves "this action was scheduled and the timelock started", the execution proves "the approvers authorize this specific run now". This is a deliberate change from the earlier "sign once, reuse the same signature at propose and execute" idea, which only worked while the summary was block-independent. It means the following:

At propose time → the action commitment is signed.
At execute time → the full transaction summary is signed.

Any feedback on this design? @bobbinth @PhilippGackstatter @mmagician

PhilippGackstatter · 2026-08-06T09:24:41Z

Thanks for the updated proposal!

A delayed transaction is proposed at one block and executed later, at a different block

Does this necessarily have to be the case, or is it even desirable?

As mentioned in #3210 (comment):

Contrary to intuition, committing to the block also doesn't force multiple in-flight multisig transactions to be executed in the same order in which they were created. That is, if tx A with ref block 5 is created before tx B with ref block 10, then it is actually allowed and possible to execute B first and then A.

So, I think there is no protocol reason why we'd need to propose at one block and execute at a different block.

Additionally, if the multisig tx involves FPI calls, then what the proposal tx against ref block X signs are the FPI calls against the account states in block X. If we later change the reference block, the foreign account states may have changed and return different values, and the signature would be stale. From this perspective, it seems desirable to use the same ref block during proposal and execution, because it guarantees the action/effects portion of the tx summary does not change.

I can also see the counterargument to this: Re-signing at execution time means we can use a newer ref block and execute against newer foreign account state. However, by its nature, delayed execution, due to the inherent delay, authorizes an action that shouldn't require the newest blockchain state, else it would be the wrong mechanism.

For completeness, there is also the fee-related concern mentioned in #3210 (comment), but I think we'll solve this separately in #3358.

At propose time → the action commitment is signed.

At execute time → the full transaction summary is signed.

In my mind, it's a UX feature that we can use the same signature for proposing and executing, as signing a proposal itself already signals the approval for its execution (at least for some timeframe - signing a block commitment + expiration delta does this directly at the signature level).

To summarize, I think the design space allows for the old and the new model. I think the main differences are:

old/curent model: uses the proposed, likely older foreign account state, but requires signing just once per approver.
new model: uses the newest foreign account state, but requires signing twice per approver.

For fee-computation purposes, a newer ref block is always preferable, but due to the signing delay for multisigs in general, I think we need a separate general mechanism here, and so I'm not sure that it should be the deciding factor.

Given the above, I still prefer the old model due to the UX benefits.

onurinanc · 2026-08-06T13:23:28Z

Does this necessarily have to be the case, or is it even desirable?

I do think it is necessary. In the same ref block model, how do we enforce that min_delay has elapsed when the execute tx references an old block? Since the timelock reads the timestamp of the ref block, execute necessarily references a newer block, this changes the full summary and makes an action commitment mandatory for matching.

Actually, a single signature per approver can be achieved without requiring the same ref block, we sign the action commitment at propose time, and at execute time we verify that same signature against the action commitment as well. The ref blocks would still differ, but since the signed message stays the same, the same signature can be reused.

The problem is that this brings #3210 back. If we only sign the action commitment, the signed message no longer binds the reference block commitment or the expiration delta .

Since the execute block isn't known at propose time, the only way to keep the block and expiration bound is to verify the full summary at execute time. For delayed txs, do you think reduced binding is acceptable?

PhilippGackstatter · 2026-08-10T06:33:22Z

Since the timelock reads the timestamp of the ref block, execute necessarily references a newer block, this changes the full summary and makes an action commitment mandatory for matching.

Ah, true. We require a newer ref block to enforce the delay.

a single signature per approver can be achieved without requiring the same ref block, we sign the action commitment at propose time, and at execute time we verify that same signature against the action commitment as well.

&

The problem is that this brings #3210 back.

I think even when we sign the "action commitment" at propose time and the tx summary at execution time, we have the "reorganization and cross-network ambiguity" described in #3210, because an action commitment doesn't bind the ref block or the chain's identity.

So, I guess the most secure option is to avoid the single signature per approver and require signing at execution time from everyone involved. That way, actual execution is bound to a specific ref block and chain identity. That's the proposal you made originally.

I think reduced binding may be acceptable, but I'm not 100% convinced, and so I would err on the side of caution. We can always ship a "multisig smart 2.0" at a later point that improves such aspects.

One note on the naming: Since the "action commitment" commits to the outcome of a tx, but doesn't care how that outcome was achieved (e.g. it doesn't bind the tx script), I think transaction effects - focussing on the effects/outcome - would be a better term than "action", which focusses on the actions that were executed in a transaction. Transaction effects is also a standard term in other chains, so I think this fits well.

Two notes regarding the implementation:

For now, I'd keep this TransactionEffects type in the multisig code rather than move it next to tx summary, mainly because a user accidentally using it can reintroduce M-08: Signed Transaction Summary Does Not Bind Expiration or Reference Block Commitment #3210.
Since native_account::compute_delta_commitment is pretty expensive, it would be good to only invoke it once (when building both the effects and summary during execution).

…ects commitmen

partylikeits1983

It looks like a merge issue has caused this PR to show a much larger diff than the feature itself. @onurinanc could you please take a look and update the branch so the diff contains only the intended changes?

…multisig base

…ch adds the delayed execution that makes delay-only policies valid

…threshold

…directions

…cution

…elayed-execution

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

merge next

c176063

PhilippGackstatter approved these changes Jul 3, 2026

View reviewed changes

onurinanc and others added 6 commits July 3, 2026 15:54

apply suggestions

c063086

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

efb0765

resolve conflicts

6923e98

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

690ad7f

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

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

1492e5e

chore: fix build

5cc248f

bobbinth reviewed Jul 11, 2026

View reviewed changes

This was referenced Aug 3, 2026

AuthRequest guard blocks signature verification outside the auth procedure #3466

Closed

fix(tx): gate only signature production outside the auth procedure #3471

Merged

onurinanc added 2 commits August 11, 2026 15:05

merge next: key multisig-smart delayed execution on a transaction-eff…

0fb7111

…ects commitmen

merge

d26a377

partylikeits1983 requested changes Aug 27, 2026

View reviewed changes

onurinanc mentioned this pull request Sep 2, 2026

fix(standards): reject delay-only multisig procedure policies #3781

Merged

onurinanc added 6 commits September 9, 2026 10:55

merge next: rebase multisig-smart delayed execution onto the audited …

29b99e0

…multisig base

merge next: revert #3781 delay-only policy rejection, since this bran…

79f8fdb

…ch adds the delayed execution that makes delay-only policies valid

feat(standards): let the smart multisig timelock lower its signature …

8e099ff

…threshold

feat(standards): make smart multisig thresholds configurable in both …

2249fbd

…directions

feat(standards): require an expiration for smart multisig delayed exe…

4ff2eae

…cution

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

41b21cd

…elayed-execution

onurinanc requested review from bobbinth, mmagician and partylikeits1983 September 9, 2026 14:21

		# 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]

	# => [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

PhilippGackstatter commented Aug 6, 2026 •

edited

Loading