Multisig for miden-lib

[Dominik1999]

Feature description

Add a multi-sig contract to miden-lib

One of Miden's core use cases will be private, compliant DeFi. For example, VCs or whales could anonymously hold and trade their assets on Miden OTC. For most DeFi use cases, especially for VCs, whales, and institutional use cases, we need a good multisig. We should have a standard implementation of a basic multi-sig that can be used to build prototypes or even as a blueprint for teams like Gnosis Safe to start.

The Design is not clear yet

It is not clear what the best design would be. I have some ideas of how this could work, but I want to use this issue to align on a design. Assume we want to create a multi-sig contract (as an account component) that requires n/m signatures.

Storing the public keys in a StorageMap

Today, the auth smart contract assumes a public key on slot 0 (see https://github.com/0xPolygonMiden/miden-base/blob/cf708732f17b2c62b744dc37edd3dd028bf21435/crates/miden-lib/asm/miden/contracts/auth/basic.masm#L9). For multi-sigs, instead of a single public key, we can store a StorageMap and add several keys to it.

Signing the account delta

Next, one initiator could create a message M that reflects the account delta after the proposed change. I think @PhilippGackstatter already knows how this could be created and signed outside the Miden VM.

This message, M, could now be stored on-chain in another StorageSlot or even passed around off-chain. If we choose to store the message M on-chain, we need to allow storage of the message even with only one signature. There might be potential attack vectors here.

Next, other signers could obtain that message M either on-chain or off-chain and sign it with their key locally. This process can be repeated until n out of m is achieved.

Execute the transaction

The last signer would inject M that is signed with n different signatures into the transaction and the multi-sig contract needs to check the signature against the stored public keys in slot 0 similarly to how we do it in our basic auth contract.

Ideally, the transacting account would inject which signing parties signed as TransactionArgs to make the contract more efficient.

Next steps: start discussing different designs

• collect ideas how the multi-sig could work end-to-end
• research how Gnosis Safe works on Ethereum (is there also a signed message?, how is it passed around?, ...)
• create a PoC in MASM (that can also be inefficient)
• ...

Why is this feature needed?

No response

[partylikeits1983]

A few questions:

1. Are there any tests in miden-base that demonstrate how to sign a hash of some data using Falcon and then verify the signature in MASM?
2. What is the size of a Falcon512 signature—666 bytes? Falcon Signature Documentation

The approach of signing data off-chain makes more sense to me, although there might be use cases where posting signed data on-chain is beneficial.

Multi-signature Account Wallet Rough Draft Outline

This is a rough outline of how a Miden multisig account could be created:

• The multisig account stores owner public keys in a mapping.
• Owners sign the hash of a note they want to create. The note includes the following fields:
  • RECIPIENT
  • note_execution_hint
  • note_type
  • aux
  • tag
  • expiration_time (an additional element for extra security so that signatures eventually expire)

Each owner could sign the hash of the note they want to create or consume. The JSON structure would look like this:

{
  "proposed_note": {
    "RECIPIENT": "0x123",
    "note_execution_hint": "0",
    "note_type": "1",
    "tag": "0x123",
    "expiration_time": "1741883656"
  },
  "proposed_tx": [
    "note_hash"
  ],
  "owner_signature": [
    "sig1",
    "sig2",
    "sigN"
  ]
}

Owners would circulate this JSON, each signing the note_hash (which is the RPO hash of the proposed_note to consume or create). Each owner appends their signature to the owner_signature field.

Once n out of m signatures are collected, anyone can create a transaction script that calls the submit_tx procedure in the multisig account.

The submit_tx procedure in the multisig might look something like this (this is pseudo MASM code):

use.miden::contracts::wallets::basic->wallet

# Stack: [expiration_time, tag, aux, note_type, execution_hint, RECIPIENT, SIG_1, SIG_2, SIG_N]
export.submit_tx

    # Assert that expiration_time > current_block_timestamp

    # Store [expiration_time, tag, aux, note_type, execution_hint, RECIPIENT] in memory at mem_addr 0

    # Hash the note fields
    push.9.0
    exec.note::compute_inputs_hash
    # => [NOTE_HASH]

    # Repeat
    while.true
        # Assert each signature signed the NOTE_HASH
        # For each signature, check if the pub_key is contained in the owner mapping; if not, panic
        # Increment a counter in this loop (used to count the valid signatures)
        # If everything is valid, push 1 to continue the loop
    end

    # Get the minimum number of signatures for quorum
    # => [quorum]

    # Assert that the signature count (number of iterations in the while loop) >= quorum

    # Load note details onto the stack from memory
    call.wallet::create_note
end

A similar approach would be taken for a procedure that would consume notes. Or the logic could be combined into a single state transition function that would take in input and output notes.

With this approach, the multisig can be a private account, and any owner (or even someone who is not an owner) can submit a transaction to the multisig. With this method the multisig could create P2ID, P2IDR, and SWAP notes. This approach is currently feasable, as long as it is relatively straight forward to get the public key of a signature in the MidenVM.

Signing the account delta of the multisig

Another idea which @bobbinth and @Dominik1999 mentioned which would add a very strong security feature would be for the owners to sign the account delta of the multisig in addition to the hash of all the notes that are created / consumed. This would assure that for any state change the owners of the multisig would have to explicitly sign the account delta of the multisig. However, currently it is not possible to get the account delta hash of an account at the end of a transaction.

The only thing that signing the account delta hash doesn't secure against (and why signing it may be redundant) is that it doesn't check to whom an asset was sent by the multisig. Say Alice & Bob sign the account delta hash of their multisig, if Alice & Bob agree to send 1 BTC to Charlie, theoretically the account delta hash wouldn't be able to prevent Bob swapping out the output note to send 1 BTC to Eve (in a simple example where only the hash of the acccount delta is used).

This is why I think maybe it might be redundant to sign the hash of the account delta since signing the hash of the input / output notes of the multisig is sufficient to prove that quorum was reached for a state transition of the multisig.

[bobbinth]

Assuming we are talking about a basic multisig here (e.g., m-of-n), I think the construction could be quite simple and it would involve some elements from the above comments. Specifically:

We'd need to create a new account authentication method - e.g., something like RpoFalcon512Multisig. This would be similar to the current RpoFalcon512 but with support for multi-sig capabilities. To enable these, we'd need to:

• Store basic parameters of the multi-sig (i.e., values of m and n) in account storage.
• Store all n public keys in account storage. An ideal data structure for this would be a StorageArray but since we don't have this implemented yet, we could use StorageMap - though, we'd need to figure out how to store public keys in the map.

We's also need to create a new account component which would contain the authentication procedure - something like auth_tx_rpo_falcon512_multisig. This procedure would read the public keys from storage and verify that we have at least n signatures for them.

Another thing we'd need is to have a way to execute a transaction up to the point when the signatures need to be verified. This is needed to generate a message for the signers to sign. The message itself could be a combination of input/output note hashes and initial/final account state hashes (kind of what we do for the simple RpoFalcon512 scheme) and in the future we could change this to work with account deltas.

Executing transactions in such a way is kind of possible now, but it would be super clunky. So, we should think how to add this functionality to the TransactionExecutor to make this more straight forward.

Once we have a message to sign, we could send it around as a part of the structure described by @partylikeits1983. Basically, the coordinator would send this structure to the signers, collect the signatures from them, and then execute the transaction from start to finish (which would also verify the signatures).

[PhilippGackstatter]

A similar approach would be taken for a procedure that would consume notes. Or the logic could be combined into a single state transition function that would take in input and output notes.

Nice approach overall. We should be able to generalize this to sign a message consisting of the input notes, output notes and account delta. This is discussed in #1198 and the message structure is summarized in task 2 of #1198 (comment). Then we should be able to generalize your approach to sign a generic transaction instead of creating a specific note, but maybe that was your intention anyway.

For simplicity, I think adding an off-chain multi sig like this first is best.

Weighted Multisig

As an idea, instead of implementing a k of n scheme, we could go with a weight/threshold approach. The basic idea is that a multisig consists of some signers A and B each of which have an assigned weight. The signature is valid only if the sum of the weights meets or exceeds the threshold. So for example, if we have signers A: weight 1, B: weight 1 and threshold 1 then it is equivalent to a 1 of 2 scheme. The advantage over a k of n scheme is that it can can express mandatory and optional signers while not being significantly more complex.

Examples:

• A: weight 1, B: weight 1, C: weight 1 and threshold 2.
  • This is equivalent to a 2 of 3 scheme (or generally k of n).
• A: weight 1, B: weight 1, C: weight 1 and D: weight 3 and threshold 4.
  • Signer D must always sign ("mandatory signer"), but one additional signature from A, B or C is sufficient ("optional signers").
  • Note how signatures from all of A, B and C together would be insufficient.
  • This cannot be replicated with a regular k of n signature scheme.
• A: weight 3, B: weight 3, C: weight 1 and threshold 4.
  • At least a signature from A or B (or both) is required ("mandatory signers").
  • A + C and B + C is also sufficient, while C alone is not.

This is just an idea. Whether it warrants the slightly higher complexity depends on the use cases and we could also start with a simpler scheme.

Here are some resources on this:

• https://docs.sui.io/guides/developer/cryptography/multisig
• https://github.com/iotaledger/tips/blob/tip52/tips/TIP-0052/tip-0052.md

In-Account multi sig

What I mean by "in-account" is to coordinate the multi sig over an account on-chain (presumably a public one). That would not require off-chain communication channels. One possible approach is, following Dominik's suggestion, to create an account with a storage layout like this:

[
	{
		"0": 2, // the threshold of the multi sig
		"public_key1": 1, // the public key of the first signer with weight 1
		"public_key2": 1, // the public key of the second signer with weight 1
	},
	{
		"tx_message_hash1": 0, // A tx hash and its current approval weight
		"tx_message_hash2": 0, // A tx hash and its current approval weight
	}
]

• Storage slot 0 contains a storage map containing the public keys and their weights (assuming the above approach) as well as the threshold.
• Storage slot 1 contains a storage map of tx message hashes (i.e. eventually h(ACCOUNT_DELTA_HASH, h(INPUT_NOTES_HASH, OUTPUT_NOTES_HASH))) and the approval weight from signers that have signed that message.

For this example, assume two signers with weight 1 and threshold 2. That account now has two exported procedures for authentication:

• One procedure auth_tx_single_rpo_falcon512_multisig takes a tx_message_hash and verifies that the transaction creator's public key is in the slot 0 map and if so, uses it to verify the signature of the tx. If it passes, its weight is added to the tx_message_hash entry in the slot 1 map. Note that the tx doesn't sign tx_message_hash, but itself. It essentially just expresses its approval for the transaction with hash tx_message_hash which should be as good.
• The other procedure implements the actual multisig. The tx creator creates a transaction whose tx_message_hash has already been approved by one signer using add_multisig, and the approval weight is therefore 1. The tx creator is now the second signer and calls auth_tx_rpo_falcon512_multisig which verifies that the tx creator has signed tx_message_hash (the tx itself) as well and that its public key is in the storage map too. The cumulative weight is 2 and meets the threshold and so the procedure passes and the tx is authenticated. The entry for tx_message_hash is removed from the slot 1 storage map mostly to ensure that transaction can only be executed once, but also for cleanup.

This is essentially access control to ensure that individual signers can only modify the account by expressing their approval to certain transactions. Anything else requires a multi-sig, including updating the threshold or the public keys.

An alternative to implementing this access control in one account is to split this up into two accounts. One "signature aggregator account" aggregate the signatures using a similar approach as auth_tx_single_rpo_falcon512_multisig. The other account still has auth_tx_rpo_falcon512_multisig but uses FPI to query the aggregator account to check if enough signatures were aggregated. This is really just a high-level idea though, there are a lot of things to think through, especially with FPI where older states could be used and we may not be able to prevent executing the same transaction twice with this approach as easily.

What is the size of a Falcon512 signature—666 bytes?

The Vec<Felt> returned by get_falcon_signature is of length 2056, but serialized the signature is 666 bytes (https://docs.rs/miden-crypto/latest/miden_crypto/dsa/rpo_falcon512/struct.Signature.html).

[bobbinth]

As an idea, instead of implementing a k of n scheme, we could go with a weight/threshold approach.

I like this - and I think this may be simple enough to implement in a PoC.

In-Account multi sig

I think this is interesting too - but this would require the account to be public, right? Otherwise, we'd still need side-channels between signers to communicate account state updates (though, i guess, a more generic mechanism could probably be used here for private accounts).

Another potential approach is to use notes in place of signatures. For example, let's say there are accounts a, b, and c which are simple accounts (e.g., basic wallet) and there is a multisig account m. The individual accounts could send notes to m containing the hash of the transaction they want to authenticate. Once there are enough such notes (e.g., 2) anyone could create a transaction against m. The code in m would check if the notes come from relevant parties (i.e., via the sender field) and if they authenticate the expected transaction. One potential challenge here is not to run into "circular references" - not sure if it is possible.

The Vec<Felt> returned by get_falcon_signature is of length 2056, but serialized the signature is 666 bytes (https://docs.rs/miden-crypto/latest/miden_crypto/dsa/rpo_falcon512/struct.Signature.html).

In our signature struct we serialize both the public key and the signature - so, the actual serialized size is 1563 bytes.

[VAIBHAVJINDAL3012]

Another potential approach is to use notes in place of signatures. For example, let's say there are accounts a, b, and c which are simple accounts (e.g., basic wallet) and there is a multisig account m. The individual accounts could send notes to m containing the hash of the transaction they want to authenticate. Once there are enough such notes (e.g., 2) anyone could create a transaction against m. The code in m would check if the notes come from relevant parties (i.e., via the sender field) and if they authenticate the expected transaction. One potential challenge here is not to run into "circular references" - not sure if it is possible.

As per my understanding, if the parties sends note for a particular transaction hash before it get authenticated, then based on the number of notes, state might be different for same transaction hash. In this way malicious user can hide the state of private account

[Dominik1999]

@VAIBHAVJINDAL3012 thanks for today's call. As discussed, as a first step, we should create a table of features that Safe has on the EVM in one column and features that we will support in the other. We will also add some features, like privacy, that do not exist on the EVM yet. Another feature we could add is rate limiting.

We can use that for our initial design.

The goal is to create a PoC (including a frontend) until end of July.

[partylikeits1983]

For visibility here are the latest comments to this multi-sig conversation: #1330

[VAIBHAVJINDAL3012]

Proposal: Threshold-Based Multisig Account (Private, Off-Chain Coordination)
Scope & Assumptions
This proposal describes a design for a threshold-based multisignature (multisig) account that is compatible with the current Miden VM architecture.
It does not rely on upcoming features such as account_delta, though such additions could further improve composability in the future.

The design is guided by the following assumptions:

• Private Multisig State
  The account’s internal state (e.g., signers, threshold) is not stored or published on-chain. Instead, it is maintained off-chain and
  shared among multisig participants.

• Equal Authority for All Signers
  Each signer has equal weight—there is no hierarchy or weighted voting.

• No Pre-Approval Mechanism
  All actions must be explicitly authorized at the time of the transaction. There is no mechanism for pre-authorizing operations.

💡 Design Summary
All actions affecting the multisig account are modeled in terms of note consumption and note creation. Signature collection and coordination are handled off-chain, with threshold validation enforced during execution through pre_execution and post_execution hooks.

• All Actions as Note Consumption or Creation

  The multisig account logic treats each operation as either consuming an input note or producing an output note.

  Note Consumption (IN):

  • Spending a P2ID note to transfer funds.
  • Consuming a configuration note to change the internal state, such as threshold or signer set.

  Example:
  Changing the signature threshold is done by consuming a special "threshold update note." This note can be created by a dummy
  account and, once consumed by the multisig, updates the threshold value in the private state.

  Note Creation (OUT):

  • Creating a PRID note to send assets to an external recipient.

  This approach is note-type agnostic, making the design consistent and extensible regardless of the operation type.

• Signature Collection via advice_map

  Signature validation is performed off-chain and passed into the transaction through the advice_map.

  During transaction preparation, a coordinator collects signatures from participants over the canonical hash of each note (both
  consumed and created).

  These signatures are stored in an advice_map, which is provided to the transaction during execution.

  The account logic uses this map to verify whether the threshold of required signatures has been met.

  Key properties of this model:

  • Signatures are not stored in account state, preserving privacy.

  • Threshold enforcement is stateless and dynamic, allowing signatures to vary per transaction.

  Coordination is decentralized—any party can prepare and submit the transaction, regardless of whether they are a signer.

• Signature Scheme

  We are planning to use the Falcon signature scheme, as it is already supported in Miden.

  In the future, once an ECDSA secp256k1 precompile becomes available, we intend to support it as well. This would enable
  compatibility with tools like MetaMask and other EVM-native wallets.

• Execution Hooks: Signature Verification

  Threshold checks are embedded in the multisig account logic using execution hooks:

  pre_execution — For Note Consumption

  • Called before consuming each input note.

  • Verifies that at least threshold valid signatures exist in the advice_map for that note's hash.

  • If the condition is not satisfied, execution is aborted.

  post_execution — For Note Creation

  • Called after creating each output note.

  • Verifies that at least threshold valid signatures exist in the advice_map for that created note's hash.

[PhilippGackstatter]

Thank you for the proposal!

I have a couple of comments/questions:

Each signer has equal weight—there is no hierarchy or weighted voting.

I think the weighted approach mentioned earlier in this discussion could be nice for more flexibility, but your approach is still fine. I guess it could be extended later if needed.

During transaction preparation, a coordinator collects signatures from participants over the canonical hash of each note (both
consumed and created).

Does it not suffice to sign basically hash(INPUT_NOTES_COMMITMENT || OUTPUT_NOTES_COMMITMENT) for your approach? That way you wouldn't need a custom hashing scheme (which is how I understand the proposal).

All Actions as Note Consumption or Creation

What is the rationale for this limitation, i.e. why can the multisig not authenticate changes to the account state? Having to create a configuration note first in order to change the signer set seems unnecessary if the signer set could also be updated from a transaction (via the transaction script) directly. Is this because you're not relying on the account delta and are just working with input and output notes commitments?

If you actually do end up using the hash scheme above, then it should be easy to extend this to hash(ACCOUNT_DELTA_COMMITMENT || hash(INPUT_NOTES_COMMITMENT || OUTPUT_NOTES_COMMITMENT)) once the delta is available (all PRs for this are in the review stage) which should allow authenticating account state changes.

Threshold checks are embedded in the multisig account logic using execution hooks

Maybe I don't fully understand the proposal, but as far as I can tell there is currently no way to hook into "pre/post note execution". With #1470 the only way to authenticate a transaction will be via an authentication procedure that is automatically called by the transaction kernel in the epilogue. Here you can inspect the transaction (check if notes were created or consumed) and in the future more capabilities (such as account delta). That should allow you to run the same logic, just differently than with hooks.

[VAIBHAVJINDAL3012]

I think the weighted approach mentioned earlier in this discussion could be nice for more flexibility, but your approach is still fine. I guess it could be extended later if needed.

Yes, for the first iteration to keep the approach simple, we thought of this.

Does it not suffice to sign basically hash(INPUT_NOTES_COMMITMENT || OUTPUT_NOTES_COMMITMENT) for your approach? That way you wouldn't need a custom hashing scheme (which is how I understand the proposal).

We need to check whether we can access the INPUT_NOTES_COMMITMENT inside the smart contract (component). If we can access it there, then INPUT_NOTE_COMMITMENT can work fine.

What is the rationale for this limitation, i.e. why can the multisig not authenticate changes to the account state? Having to create a configuration note first in order to change the signer set seems unnecessary if the signer set could also be updated from a transaction (via the transaction script) directly. Is this because you're not relying on the account delta and are just working with input and output notes commitments?

When we thought of this design, when there was no account_delta feature so we couldn't authenticate the changes to the state.I see note as a set of action, which get executed when consumed. There is also one rationale behind creating the note(action) and just signing it offchain is that parties can just read the note(action) and sign it, without running the simulation at their end.In this way all the parties may not require to keep the state, they can just store the notes and use it to create state later in if required.
Is creating the note a costly process?

Maybe I don't fully understand the proposal, but as far as I can tell there is currently no way to hook into "pre/post note execution". With #1470 the only way to authenticate a transaction will be via an authentication procedure that is automatically called by the transaction kernel in the epilogue. Here you can inspect the transaction (check if notes were created or consumed) and in the future more capabilities (such as account delta). That should allow you to run the same logic, just differently than with hooks.

I can see that in issue 1470, there has been talks around the authentication in Epilogue. We were of the view that prelogue and epilogue are protocol level changes, as developer we can just build the component( analogous to the smart contract in Ethereum).
When I said pre/post hook, I meant that we need to write the validation procedure, which we will be called in the beginning or at the end, every time any interface is called of the multi-sig component. Does this make sense?

[PhilippGackstatter]

Please excuse the late reply.

We need to check whether we can access the INPUT_NOTES_COMMITMENT inside the smart contract (component). If we can access it there, then INPUT_NOTE_COMMITMENT can work fine.

There are kernel procedures tx_get_input_notes_commitment and tx_get_output_notes_commitment which can be used to fetch these values.

I see note as a set of action, which get executed when consumed.

I think that's a great way of looking at it!

parties can just read the note(action) and sign it

I agree that is a nice property. It does presume that the note is easily shared between all parties which I'm assuming means it is a public note.

Is creating the note a costly process?

Someone needs to create a transaction, prove it, pay the fees for the note (fees are not yet implemented, but eventually this will be the case) and if the note is public, the fees will be significantly higher than if the note is private. It's not that this will be a prohibitive cost, but if the note can be avoided, then I think that could be worthwhile to look into to make the whole process cheaper (both in terms of computation costs and monetary costs).

If there is a way to share these notes privately (e.g. with something like #1388) then I think that would definitely work.

On the other hand, with the account delta, adding a signer could be represented as an "add new signer's public key to allowed_signers_storage_map" action. Conceptually, that is similar to how you described notes as a set of action which is executed when consumed. This delta could be passed around between all current signers, and each of them could sign off on it. That wouldn't require any on-chain interaction, and so would be cheaper than the note-based approach.

When I said pre/post hook, I meant that we need to write the validation procedure, which we will be called in the beginning or at the end, every time any interface is called of the multi-sig component. Does this make sense?

Yes it does make sense. It depends on the exact design whether such pre- / post-hooks are necessary, or if everything could be done in the auth procedure directly.

[VAIBHAVJINDAL3012]

I agree that is a nice property. It does presume that the note is easily shared between all parties which I'm assuming means it is a public note.

No, I am talking about the private notes, which are shared to all the parties off chain through some offchain mechanism.

Someone needs to create a transaction, prove it, pay the fees for the note (fees are not yet implemented, but eventually this will be the case) and if the note is public, the fees will be significantly higher than if the note is private. It's not that this will be a prohibitive cost, but if the note can be avoided, then I think that could be worthwhile to look into to make the whole process cheaper (both in terms of computation costs and monetary costs).

Yes, Agree with your point. I was of the assumption that note creation cost will be very less, as proving is done by the client itself. So I didn't think of the note cost.

If there is a way to share these notes privately (e.g. with something like #1388) then I think that would definitely work.

I was thinking of using the gmail rail, as it is the most used, so very less friction for users.

Yes it does make sense. It depends on the exact design whether such pre- / post-hooks are necessary, or if everything could be done in the auth procedure directly.

I have written the masm file for this. Putting it in modified auth component will work, but I agree we need account_delta.
I have one question, why can't we have tx_script_commitment, similar to input_note_commitement, it might have made things simpler.
https://github.com/inicio-labs/miden-multi-sig/blob/main/masm/multisig/multisig_verifier.masm

[PhilippGackstatter]

No, I am talking about the private notes, which are shared to all the parties off chain through some offchain mechanism.

I see. So if there is an off chain mechanism anyway, then I guess it doesn't matter whether a note is shared or an account delta.

I have one question, why can't we have tx_script_commitment, similar to input_note_commitement, it might have made things simpler.

By tx_script_commitment you essentially mean a commitment to the transaction script and so a commitment to the APIs that the transaction script will call, e.g. call.multi_sig_account::add_signer? And what would the signing message consist of? A hash of tx_script_commitment, input_notes_commitment and output_notes_commitment? If so, then that would technically be sufficient from a security standpoint, but transaction scripts are not really standardized but are usually generated dynamically.

So you'd have two cases to consider:

If you generate the tx script dynamically, then it'll look something like

# public key of the signer
push.1.2.3.4
call.multi_sig_account::add_signer

The public key will be different each time and so the signers would have to re-review the tx script code manually as far as I can tell.

The other option is to standardize the script and use transaction script arguments:

begin
    # => [TX_SCRIPT_ARG]
    # load TX_SCRIPT_ARG from advice map which contains the public key
    call.multi_sig_account::add_signer
end

But here you'd have to also commit to TX_SCRIPT_ARG as part of the signing message so the public key cannot be swapped out. But I'm not sure if you can securely commit to this value.

I think that's why we don't have the notion of a tx script commitment.

So overall the account delta should be easier to share and review for signers, since it is a direct representation of what changes, i.e. just data instead of code. So for example, a public key being added to the signer set could just be:

{
    "signer_array": {
        "add": "0xfb5ca..."
    }
}

[VAIBHAVJINDAL3012]

I see. So if there is an off chain mechanism anyway, then I guess it doesn't matter whether a note is shared or an account delta.

Yes, Make sense

So overall the account delta should be easier to share and review for signers, since it is a direct representation of what changes, i.e. just data instead of code. So for example, a public key being added to the signer set could just be:

Yes, account_delta would cover all the edge cases which we might have with other approaches.