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:28:16Z

+#! Inputs:  [min_delay, propose_expiration_delta]
+#! Outputs: []
+#!
+#! Side effects:
+#!   - Writes DELAYED_EXECUTION_SLOT with word
+#!     `[min_delay, propose_expiration_delta, 0, 0]` (see `get_delayed_execution`).
+#!


Nit: I think we should rather add a Where: clause explaining the inputs rather than the side effect which can be checked by looking at the code.

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.

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

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

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!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

PhilippGackstatter Jun 10, 2026 •

edited

Loading