Execute Signed Intent (Intent/Permit) from Wallet

[partylikeits1983]

Execute Signed Intent from Wallet — Gasless + CoW-style

Summary

Add a new wallet entrypoint that accepts a signature over an Intent and executes it atomically. Any executor can submit the signed intent; the wallet verifies the signature and terms, then settles: if incoming note(s) satisfy the minimum requirements, the wallet releases the exact outgoing assets specified. This enables gasless transactions, intent-based trading, and CoW-style settlement.

Motivation

• Intent-based UX: Users sign what they want; solvers handle how to execute
• Gasless transactions: Makers sign once; executors/relayers pay fees
• CoW-style settlement: Enable efficient batch settlement and cross-user trade matching
• Bridge/AggLayer integration: Perfect for cross-chain asset transfers and multi-chain settlement scenarios where users want to move assets between chains without managing the complexity

Proposed Solution

1. New Intent Variant in SigningInputs

Add a new variant to the existing SigningInputs enum:

pub enum SigningInputs {
    TransactionSummary(Box<TransactionSummary>),
    Arbitrary(Vec<Felt>),
    Blind(Word),
    Intent(Box<Intent>), // New variant for intent-based signing
}

2. Intent Structure

Define a new Intent structure that is separate from TransactionSummary:

#[derive(Debug, Clone, PartialEq, Eq)]
pub struct Intent {
    /// Minimum assets that must be received
    min_input_assets: Vec<Asset>,
    /// Exact assets to be sent (must match exactly)
    exact_output_assets: Vec<Asset>,
    /// Maker's account ID
    maker_account: AccountId, // this may not be required
    /// Unique nonce for replay protection
    nonce: u64,
    /// Expiration timestamp
    deadline: u32,
    /// Salt for uniqueness
    salt: Word,
}

3. Wallet Integration

Create execute_intent procedure that:

• Verifies signature over intent commitment
• Checks expiration and nonce (replay protection)
• Validates incoming assets meet minimum requirements
• Executes atomic settlement: accept inputs, send exact outputs
• Emits settlement event for tracking

Key Differences from TransactionSummary

• Intent: Describes desired outcome (min inputs, exact outputs)
• TransactionSummary: Describes exact transaction execution
• Flexibility: Intents allow multiple fulfillment paths
• Third-party execution: Anyone can submit and execute
• Gasless for makers: Only executors pay transaction fees

Use Cases

Bridge Integration

• User signs intent: "I want to send 100 USDC from Miden to Ethereum"
• Bridge operator fulfills by providing USDC on Ethereum, taking USDC on Miden
• User pays no gas fees, bridge operator handles execution

AggLayer Settlement

• Cross-chain asset swaps without users managing multiple chains
• Unified liquidity across the ecosystem

CoW Trading

• Users sign complementary intents that can be matched
• Solvers find optimal execution paths
• Reduced slippage through batch settlement

Benefits

1. Enhanced UX: Users sign intents, not complex transactions
2. Gasless operations: Intent signers don't pay transaction fees
3. Cross-chain ready: Useful for bridge and AggLayer scenarios
4. Type safety: Intent as first-class citizen in SigningInputs enum
5. Composable: Works with existing Miden infrastructure

TODOs

• Add Intent variant to SigningInputs enum with proper serialization
• Implement SequentialCommit for Intent with domain separation
• Valid signature + terms met → accept assets and release exact outputs; mark nonce used
• Expired or replayed intent → reject with appropriate error
• Insufficient incoming assets → reject transaction
• Integration with existing authentication schemes
• Documentation and examples for intent creation and execution

This feature would significantly enhance Miden's capabilities for intent-based applications, cross-chain bridges, AggLayer integration, and CoW-style trading while maintaining security and composability.

[bobbinth]

This is super interesting but I'm not fully understanding the conditions under which these would work. Could you describe one of the use cases in more detail? For example: "I want to send 100 USDC from Miden to Ethereum":

• Who issues this intent? I'm assuming this would be user's wallet - but maybe it is some app?
• Who receives/routes the intent? Is this also user's wallet? Or is there a front-end for this? I'm assuming the model is flexible, but what would be the "dominant" flow.
• What does it mean to "fulfill" the intent? I'm assuming this results in something like a TransactionRequest being sent to the wallet, with the main difference that the request already has a signature required for authentication the transaction - but maybe it is something else?

[Dominik1999]

I love this idea. We could match it with the idea of having "prioritized batches". One slot in each block could be auctioned by the Miden Node. And solvers could compete in the auction to get their batch in. That way, the solvers can arbitrage and the Node can distribute the fees to a Miden Staking contract, in which every use can stake MDN and earn an interest out of it.

The intent could result just a simple SWAPp note. And solvers can either swap directly or bridge and swap to chains with more favorable prices.

This seems to do what also MegaEth and Arbitrum are doing. This will give us

[partylikeits1983]

Could you describe one of the use cases in more detail? For example: "I want to send 100 USDC from Miden to Ethereum":
Who issues this intent? I'm assuming this would be user's wallet - but maybe it is some app?
Who receives/routes the intent? Is this also user's wallet? Or is there a front-end for this? I'm assuming the model is flexible, but what would be the "dominant" flow.
What does it mean to "fulfill" the intent? I'm assuming this results in something like a TransactionRequest being sent to the wallet, with the main difference that the request already has a signature required for authentication the transaction - but maybe it is something else?

Lets take the first example: "I want to transfer 100 USDC from Miden to Ethereum"

1. User signs TransactionSummary object with the following parameters:

pub struct TransactionSummary {
    account_delta: [], // no storage change
    input_notes: vec![], // no input notes
    output_notes: vec![B2AGG, P2ID], // two output notes
    salt: Word,
}

The user signs a TransactionSummary object that specifies the creation of a B2AGG note with the details of the destination address on Ethereum. They also sign to create a P2ID note, which would be the tip for the 2nd user (bridge, or some intent filler), to actually execute the transaction and pay the tx fee.

Who issues this intent? I'm assuming this would be user's wallet - but maybe it is some app?

This would be application specific, just like with EVM applications. User goes to a dapp website. They click "bridge assets" or "swap" and instead of sending a tx that costs gas, they just sign a message. The intent is crafted under the hood by the app. The app requests the user's signature from the browser extension wallet.

What does it mean to "fulfill" the intent?

Filling the intent means crafting a transaction against the signer's account which results in the intent getting executed.

---

The TransactionSummary object works fine in simple bridging scenarios, however, its a bit limited when it comes to more complex intent types, for example swapping assets.

Take the following example:

A user wants to exchange 3500 USDC for 1 ETH. They would sign an intent that would look like this:

pub struct TransactionSummaryExt {
    account_delta: [], // no storage change 
    input_notes: vec![ONE_ETH_P2ID], // one input note 1 ETH
    output_notes: vec![3500_USDC_P2ID], // one output note 3500 USDC
    expiration_block: 10, // say current block is 5
    salt: Word,
}

The exchange app would create this TransactionSummary object on the frontend and would request the user's signature from the browser extension wallet. Then the user would see the AccountDelta summary in the browser extension, i.e. "send 3500 USDC, if 1 ETH received".

In a trading scenario, its important that these intents have expiration times, so that at some point in the future the signed intent "expires" and so that someone can't execute this intent against a user account long after the intended use of the intent. Not fully aware how this would be enforced at the kernel level since users can pick arbitrary reference blocks when executing transactions. Maybe we should enforce this at the node level, that reference blocks for locally proven transactions should be within at least 5-10 minutes of the chain tip?

[bobbinth]

So, if I understood correctly, the flow is:

1. The user goes to the Dapp's website.
2. They fill out some data and the Dapp creates the TransactionSummary.
3. The user signs this summary.
4. The Dapp builds a TransactionRequest which, when converted into a transaction, would result in the above summary.
5. The Dapp sends this transaction request to the user.
6. The user builds this transaction and submits it to the network.

A couple of things that are not clear to me in this flow:

• The user still needs to pay transaction fees - right? This is because the user is the one executing the transaction.
• Why do we need the extra steps of pre-signing the tx summary? Couldn't the Dapp just send the TransactionRequest to the user? (i.e., basically, skip steps 2 and 3 above.

In a trading scenario, its important that these intents have expiration times, so that at some point in the future the signed intent "expires" and so that someone can't execute this intent against a user account long after the intended use of the intent.

I'm still clearly missing something because I'm not seeing why this would be an issue: if the user needs to be the one who executes and submits the transaction to the network, they can just reject the transactions that they don't like - right?

[PhilippGackstatter]

I think the intent is generally not fulfilled by the user themselves. Instead, you send the intent to some service with a pool of intents from different users, where intent fulfillers discover them. They pick your intent and create a transaction against your account to "execute" it. I think the idea is that the intent fulfiller gets this second P2ID note from here output_notes: vec![B2AGG, P2ID], as a reward for this.

Intent Fulfiller Reward

A potential issue I see is that the user that creates and signs the TransactionSummary doesn't know the account ID of the intent fulfiller, and so how would they actually construct the P2ID note? I think this may require some other mechanism to reward the fulfiller than a P2ID note.

[bobbinth]

They pick your intent and create a transaction against your account to "execute" it.

If someone else is expected to execute a transaction against my account, they would need to know my full account state (or at least have all the witness data required for this - i.e., storage and vault witnesses). Basically, we have the following options:

1. The account is public, and then executing intents doesn't require any other data.
2. The account is private, and the user needs to provide account state together with the intent. If this state changes after the intent has been issued, any transaction built by the intent filler will be invalid.
3. The user has some "dynamic" way of sharing the latest state with the intent filler (e.g., potentially allowing the intent filler to "subscribe" to their "state guardian" or "PSM").

Is this how we are thinking of intents?

[PhilippGackstatter]

That's my understanding as well. I think intents with private accounts seem difficult, though if you have an intent service where you publish your intents, you could probably also publish the necessary private account state alongside it and keep it up-to-date, somehow.

[partylikeits1983]

A potential issue I see is that the user that creates and signs the TransactionSummary doesn't know the account ID of the intent fulfiller, and so how would they actually construct the P2ID note? I think this may require some other mechanism to reward the fulfiller than a P2ID note.

Yes exactly, I realized this over the weekend after I wrote this. It would not be possible to sign TransactionSummary in the asset exchange example since the user signing the exchange intent would not know the p2id details of the order filler. We would need some other structure that would be signed, instead of InputNotes / OutputNotes, something that would capture the account's asset delta, i.e. the net inflow / outflow of assets from the account.

Separately, I have not thought this through for private accounts, I think this "signed intent" idea only works well with public accounts.

[PhilippGackstatter]

I think this is a pretty cool idea, thanks for sharing and proposing this!

Intent Expiration

Relates to #2000.

Because expiration blocks are set by the transaction executor, I now understand why this mechanism by itself is insufficient for intent expirations. The intent fulfiller is the transaction executor, and so they would have to set the expiration block, but they cannot be trusted.

This also made me realize that AuthRpoFalcon512 may be unsuitable to use for signing intent transaction summaries, because its SALT is [final_nonce, ref_block_num, 0, 0], and so, as soon as the user has issued an intent and subsequently issued a transaction themselves which incremented the nonce, the intent has effectively expired. That's because the intent fulfiller can no longer execute a transaction whose final_nonce would match the one in the SALT. Depending on how you look at it, this is a feature or a bug:

• If you want to cancel all existing intents, that's a feature.
• If you have in-flight intents and you don't want to cancel them, then you shouldn't create a transaction against your account, else you cancel the intent.

I think the challenge with an intent-based auth component is primarily the same as with the multisig: If we want support for in-flight transactions, then a storage map-based replay protection instead of a nonce-based one, might be necessary (though I could be missing other approaches).

And with these two known replay protection mechanisms you have different expiration mechanisms:

• With the nonce-based approach like above, you can issue a transaction yourself to cancel all existing intents.
• With the map-based approach like in the multisig, you'd have an intent-based flavor auth component, say, AuthIntentRpoFalcon512, and you assign a unique intent ID to every intent (just like the SALT in the multisig is a random word). This intent ID is is committed to and signed. To cancel an in-flight intent, set the map entry of that intent to the value that says "already executed" in another local transaction, and it can no longer be executed.

Additionally, you can also make AuthIntentRpoFalcon512 retrieve expiration_block_num via miden::tx::get_expiration_block_delta and include it in the SALT that is signed. If the user then signs the TransactionSummary with expiration_block_num in the SALT set to their desired value, this enforces that the transaction executor (= intent fulfiller) has set the expiration block number to that value. This may be useful in case you do transactions against your account infrequently and just want the intent to expire after a day or so and not have to think about it anymore. So the SALT for this component could maybe look like [intent_id_hi, intent_id_lo, 0, expiration_block_num].

There may be even more ways to do intent expiration, but replay protection and expiration are closely linked. In any case, I think adding a protocol-level expiration mechanism doesn't solve this problem in a simpler way than what we can already do with the protocol, and instead would probably increase the complexity involved in creating correct auth components as there would be more things to think about.