Separate business and fee logic for network accounts

[mmagician]

Note: this is WIP

Summary

Proposal #2901 assumes that the note being consumed carries the asset that funds fee payment on behalf of the network account, and that a FeeManager component can extract that asset from the active note.

I want to explore an alternative design where we keep the "feature" note unchanged (no bundling of fee asset) and instead separate network account sponsorship into its own standard note.

To make the terminology precise, I will use:

• FeatureNote: the note that encodes the actual user intent, e.g. BURN, P2ID, CLAIM, etc.
• NetworkSponsorshipNote: a separate note whose only job is to sponsor execution against a specific network account.
• BuilderFeeNote: the builder-facing note from the batch-level fees discussion in Batch-level fees #2899. I am renaming it here from FeeNote only to avoid ambiguity.

The high-level idea is:

1. a FeatureNote remains as it is today, without bundling a fee asset into it;
2. the tx also carries a NetworkSponsorshipNote targeted to the network account;
3. the network account validates that the transaction contains sufficient sponsorship for the operation(s) being performed;
4. settlement into batch-level fee mechanism remains as per Batch-level fees #2899.

The main motivation is to avoid overloading the feature note with fee-routing semantics.

The FeatureNote expresses intent, the NetworkSponsorshipNote sponsors network-account execution, and the BuilderFeeNote compensates the batch builder for inclusion.

Background

The current FeeManager direction in #2901 works for some notes, but it also couples the feature note format to fee payment.

That creates awkward cases:

• BURN: the note is conceptually "burn this asset", but now it also needs to carry the asset that funds fee payment.
• P2ID to a network account: the note is conceptually "transfer these assets to this account", but it must also embed a fee asset to cover the tx costs.
• More generally, any future network-account flow that wants clean operation semantics now has to decide whether to become fee-aware too.

In other words, the current shape mixes two concerns:

• the note that expresses the business action; and
• the artifact (part of note logic, part of account logic) to handle funding the execution on behalf of the network account.

I think those should be separate.

Proposed mechanism

Feature notes only encode business logic

FeatureNote remains focused on the user-visible action:

• burn this asset;
• claim this bridge message;
• etc.

It does not need to carry a separate fee asset just because the consuming account happens to be a network account.

Separate network sponsorship

We introduce a standardized NetworkSponsorshipNote.

This note is explicitly about sponsoring execution against a network account. It is a "fee note", but conceptually different than the batch builder BuilderFeeNote discussed in #2899.

A NetworkSponsorshipNote should be only consumable by the network account. I think this doesn't require any special provisions outside of what the FeatureNote would mandate w.r.t. who can consume.

Account-level validation

Rather than patching every note script as IIUC, #2901 mandates, the preferred validation point is the network account itself.

Concretely, the network account validates:

• which feature notes are being consumed against it;
• whether there is sufficient matching network sponsorship in the tx;
• whether the sponsorship is targeted to this network account;

End-to-end flow

1. User constructs a FeatureNote exactly as they do today.
2. User adds a NetworkSponsorshipNote for the target network account.
3. The network account validates that sponsorship covers the consumption costs.

Limitations

nothing's for free :(

Input-note form has overhead

If the NetworkSponsorshipNote is an extra input note, then it adds an extra note / nullifier footprint.

Output-note form has timing constraints

Depending on the order of processing the notes within the transaction, we need to be careful about where validation happens.
I'm not fully convinced yet that our tx kernel can support the flow described in this proposal.

Variant pricing still needs a carrier

Issue #2901 distinguishes different variants of the same note script, e.g. via (note_script_root, variant_tag).

If the FeatureNote remains unchanged, we still need to account for different costs of different execution paths.

TBD

[bobbinth]

To add to limitations:

• The network transaction builder logic becomes more complicated because it needs to make sure it selects the right NetworkSponsorshipNote for a given FeatureNote. By itself, it shouldn't be too difficult, but there probably some edge cases/attack vectors to handle (e.g., what if there are two NetworkSponsorshipNotes for some FeatureNote).

Overall, I think the limitations are quite significant (especially the need to double the note count for network notes), but what I really like about this approach is that NetworkSponsorshipNote could be independently "transformed" during the batch building process. That is, if the network account accepts USDC, and the user has only USDT, the user could create the note with USDT and configure it so that the batch builder would exchange USDT to USDC.

If we could achieve the same property with a single-note design, that would be awesome - but I don't have a good proposal on how to do this yet.

[mmagician]

Though maybe I'm being overly harsh. I think this could already sort of happen via note recalls - though in that case at least the user needs to pay for two txs, whereas in the above they only pay for one - the actual tx they may already want.

I think that due to the presence of a proof that each tx must carry, the cost of spamming is going to be non-negligible.
So what would prevent users from spamming the ntx builder with notes that can not (no longer) be executed against their account:

• they will paying for one tx
• they still need to generate a proof for each "spammy" tx they submit

I think these are deterrent enough - but if at some point this turns out not to be enough, we could add a simple heuristic to the note selection process which goes sth like: "track the account commitment of the user that emitted a note. If I see another note created by a tx whose account commitment I've seen, reject."

[Mirko-von-Leipzig]

"track the account commitment of the user that emitted a note. If I see another note created by a tx whose account commitment I've seen, reject."

There is no such information or tracking available in the ntx builder - it only tracks network notes and network accoutns.. But I think this illustrates why we definitely should not do this - its forcing the implementation into a pretzel instead of simplicity.

[mmagician]

I naturally understand the pushback.

its forcing the implementation into a pretzel instead of simplicity.

Agreed 100% - but we will end up with a pretzel somewhere, on the protocol OR the node side. And I'd rather have a simpler protocol (because this affects the user code, and a zero-net-note design hugely simplifies user code by not mandating special statements in note scripts nor in account code*) than a simpler node (oblivious to the users).

---

*note scripts business logic is completely unaffected. Account code needs to include a component with a public procedure for handling the in-flight consumption of NetworkSponsorshipNote and output of FeeNote, respectively, but this remains independent of the account's business logic, unlike the FeeManager which AFAIU requires integrating the fee payment into different branches of logic.

[Mirko-von-Leipzig]

If it requires complexity on either side then it shouldn't really be considered a solution at all imo. This almost guarantees exploits and bugs.

[bobbinth]

But the fee logic also affects the note in other ways. Consider the P2ID note that calls miden::standards::wallets::basic::add_assets_to_account to add all of its assets to the account. This could no longer be written as-is because active_note::get_assets would also fetch the fee asset and add it to the account, but it shouldn't do that because the fee was already handled separately. Ways to solve this are:

• Make add_assets_to_account fee-aware, i.e. skip the fee asset if a NetworkAccountTarget attachment is present: Not a good idea, because this pattern would just propagate fee logic everywhere, and it wouldn't be extensible.
• Make add_assets_to_account take a list of assets instead. This avoids the fee logic in the wallet, but pushes the problem upwards. The caller now needs to make sure to split active_note::get_assets into the fee asset and the remaining assets.

There is another way to solve this: we could introduce something like active_note::remove_asset procedure. This procedure would take an asset as a parameter, find this asset in the active input note's memory region, and update the asset value accordingly (and if something goes wrong - e.g., asset is not found, asset doesn't have enough balance etc. - it would fails).

Since we already have all assets for input notes stored in kernel memory, this would be a very simple procedure to add. And it would fix the issue with get_assets and similar.

But this would be an "unsafe" procedure in that it would be very easy to miss-use. For example, calling it twice will likely lead to un-intended consequences. Also, if we first call get_assets and then call remove_asset the effect would not be the same.

If there was a way to ensure that this procedure runs right before note execution, and that it can be runs only once, that would solve the problem - but that requires much deeper protocol changes (and I'm not sure how to do it purely at the standards level).

[partylikeits1983]

Just leaving some thoughts below:

I like this idea, but I think we have a classic protocol design tension :) cleaner abstractions on one side (#2968) vs simpler implementation and stronger user guarantees on the other (#2901).

Honestly, #2968 is more elegant on paper. Fee logic isn't handled inside network notes themselves, and you get nice composability like the USDT -> USDC swap handled by the batch builder as @bobbinth mentioned. But pulling it off relies on node functionality that seems like it's being removed, not added, and it weakens the guarantee that a user's submitted transaction will actually get committed.

overloading the feature note with fee-routing semantics

This concern is fair in principle, but the actual change in #2901 is pretty minimal imho. A note script gets one extra line, call.fee_manager::pay_fee, and is told to carry a fee asset. That's it. The note's business logic is untouched. The script doesn't have to know anything about the fee policy; it just delegates to the FeeManager component on the receiving network account. The fee logic lives entirely in the network account's storage. If the bridge wants to change its fee schedule tomorrow, no note scripts change.

That's not really mixing concerns in the bad sense. It's closer to a calling convention: when you call into a network account, the first action (or last) is paying the fee. Compare it to msg.value in the EVM. Every transaction carries gas funding bundled in, and that isn't treated as a separation-of-concerns violation.

The one place #2901 does cause friction is the BURN note. Conceptually the note says "destroy this asset," and now in some cases it has to carry a second asset purely to pay the fee. The note has two vault entries with different roles, and the script reader has to understand that the first asset is being burned and the second is being paid as a fee. If the fee asset matches the burn asset, the awkwardness disappears, but in the general case there will be two assets in a BURN note.

I don't think either option is "perfect", but I think #2968 is worse in practice (sorry @mmagician 😅). It trades that mild awkwardness for substantial costs this thread already surfaced:

1. The Note count doubles on every network account interaction, unless you do the MustBeErased trick to keep the extra notes ephemeral.

2. The MustBeErased trick requires mempool-level unauthenticated note propagation, which as @Mirko-von-Leipzig pointed out, seems like this logic is actively being removed from the node because it is too complex.

3. Loss of user expressiveness. Mirko's second point is the sharpest one imho:

   this also discourages a user transaction which performs additional things outside of the network note submission. Because the user's transaction inclusion is now decided by the ntx builder and may therefore never be committed at all.

   Under the MustBeErased flow, tx1 only commits if the ntx builder picks it up. So you can't reliably bundle a network-account interaction with anything else in the same transaction.

4. NTX builder matching complexity. Pairing the right NetworkSponsorshipNote with the right FeatureNote across a mempool of pending transactions seems like it opens the door to subtle bugs.

---

TLDR: #2901 isn't perfect, but the tradeoffs feel reasonable to me. It's the more pragmatic option, and it keeps the fee logic at the protocol layer instead of pushing complexity down to the node.

[bobbinth]

For the NetworkSponsorshipNote approach, one thing I'm trying to figure out is how consumption of these notes will look like on the network account side. I think the logic will need to handle 4 cases:

• There are no sponsorship notes for the feature note we are trying to consume.
• There is exactly one sponsorship note for the feature note we are trying to consume.
• There are many sponsorship notes for the feature note we are trying to consume.
• There are sponsorship notes, but there are no related feature notes.

My understanding is that the fees will be paid when we execute the sponsorship note. So, the task of the sponsorship note script would be:

• Make sure there there is a feature not for which it needs to pay fees present in the transaction, and fail otherwise.
• Call the pay_fee procedure passing the ID of the feature not for which it needs to pay fees. If the fees are insufficient - fail.

The above would ensure that we can't consume sponsorship notes unless the feature notes are already in the transaction. But I guess there is a potential attack vector here: someone can create another sponsorship note for the same feature note with intentionally low fees, and this will block consumption of the feature note (assuming the batch builder will try to put all sponsorship notes for a given feature note into a single transaction).

A potential workaround for this is for the pay_fee procedure to sum up fees from all sponsorship notes for a given feature note in the same transaction. But to do this, we'll need to somehow have pay_fee preserve the context across multiple sponsorship notes (this could be supported via #1338). And even then, we can run into the issue that the assets in the sponsorship notes are different - and so, cannot be combined.

Overall, I think we need to analyze the issue of "someone intentionally creates a sponsorship note that makes some specific feature note un-consumable" a bit more.

[mmagician]

Separating business and fee logic for network accounts — refined proposal

This supersedes the double-note flow sketched in my earlier comments, which didn't do the idea full justice.
Settlement still plugs into the batch-level fee mechanism from #2899

Summary

Network-account developers should never have to think about fee estimation. The note that expresses business intent should avoid fee-routing logic, and the network account should not need to expose or maintain any fee-pricing logic of its own.

The mechanism here achieves that with a network account that is a pure pass-through for fees: its only fee-related job is to move the assets it was sponsored with into a builder-facing FeeNote. It does not:

• estimate a fee, or
• decide how much of the batch builder's fee to keep

Fee sufficiency is enforced implicitly — an underpaying (network) transaction is simply never included in the batch, so the user is naturally incentivized to pay enough, and the entire sponsored amount flows straight to the batch builder.

Terminology

• FeatureNote — the note encoding the actual user intent (BURN, P2ID, CLAIM, …), targeted at the network account. Unchanged from today; carries no fee asset.
• NetworkSponsorshipNote — a separate note, also targeted at the network account, whose only job is to carry the asset that sponsors execution against that network account.
• FeeNote — the builder-facing note from [#2899](Batch-level fees #2899), consumed by the batch builder.

The pass-through procedure

The network account exposes a single, simple procedure. Because it runs within the network account's context, the emitted FeeNote is authored by the network account — but the assets pass straight through and are never moved to the network account's vault.

# Network account procedure — pure pass-through.
# Moves all assets from the consumed NetworkSponsorshipNote into a
# FeeNote targeted at the batch builder. No estimation or validation of fees.
begin
    let fee_note = create_fee_note(recipient: batch builder)
    fee_note.vault += current_note.vault   # forward the full sponsored amount
end

The user is incentivized to fund the NetworkSponsorshipNote with enough to cover the batch builder's fee, because if the resulting FeeNote doesn't cover cost, the transaction is never included in the batch.

End-to-end flow

Assume the network account is already deployed.

1. Define intent. User constructs a FeatureNote (business logic) targeted at the network account, exactly as today.
2. Attach sponsorship. User attaches a NetworkSponsorshipNote, also targeted at the network account.
3. Dry run (black box for the purpose of this discussion). User dry-runs the transaction in which the network account consumes both the FeatureNote and the NetworkSponsorshipNote. Treat this as a black box that returns an estimated cost. On this first pass the sponsorship asset is a placeholder (set to e.g., fee = 1).
4. Size the fee. User updates the asset carried in the NetworkSponsorshipNote with the estimate from the dry run (imperfect, but an estimate).
5. Submit. The transaction carries three output notes: the FeatureNote, the NetworkSponsorshipNote (both → network account), and a FeeNote (→ batch builder).
6. Network account consumes. The network account consumes the FeatureNote (business logic, as today) and the NetworkSponsorshipNote, running the pass-through procedure to emit a second FeeNote for the batch builder.
7. Builder settles. The batch builder consumes the FeeNote(s) for itself.

Phasing: ship without the mempool first

The fully atomic version routes everything through the network-transaction-builder mempool using unauthenticated notes, so that note creation, network-account consumption, and builder settlement all land in the same batch with no net notes committed onchain.

That dependency is the riskiest part of the design — see Open Questions — so it is not required for v1.

Phase 1 (no ntx builder mempool): commit everything onchain. Notes commit across two blocks; we lose atomicity (the FeatureNote may commit in block_n and be consumed in block_{n+1}). But the core conceptual win is fully intact from day one: network-account developers never write fee-estimation logic. The separation of FeatureNote / NetworkSponsorshipNote / FeeNote and the pass-through procedure work identically; only the atomicity / onchain-footprint optimization is deferred.

The tricky part of splitting execution across blocks. Without the mempool, we commit the FeatureNote and NetworkSponsorshipNote onchain before we know they will ever be processed. If the user underpaid the network sponsorship, the pair can become stranded:

• the network transaction builder may decline to process them at all; or
• the ntx builder may process them, but the resulting FeeNote doesn't cover the batch builder's fee, so the consuming transaction is never included in a batch.

Either way we've committed a FeatureNote onchain that may sit unconsumed. With the atomic (Phase 2) flow this can't happen — nothing commits unless the whole thing is includable — but in Phase 1 we need to decide what the user-facing story is for a stranded FeatureNote (e.g. expiry/reclaim, or guidance that the user must re-submit a top-up NetworkSponsorshipNote against the already-committed FeatureNote).

Phase 2: add atomicity. With routing the transaction first through the ntx builder mempool, the ntx builder can take the FeatureNote and NetworkSponsorshipNote as unauthenticated inputs, apply the network-account state change, and emit the FeeNote — all as a tx that would land in one batch — yielding atomic creation+consumption and zero net onchain notes.

This gives a clean migration path: correctness and the developer-experience benefit now, the footprint/atomicity optimization later.

Anti-spam on the network transaction builder

Even in the atomic version, a user can flood the ntx builder with transactions that underpay: they will never be included (so the user never pays), yet the ntx builder still spends resources on them.

Mitigation: the ntx builder executes but does not prove first. It plainly executes the transaction, checks whether the emitted FeeNote covers the batch builder's required cost under current network conditions, and only then proves. If the fee is insufficient, it skips the (expensive) proving step. Optionally, they could mark the transaction as unprocessed for the user (TBD how, AFAIU we can't do this today).

This removes proving cost from the spam surface. Residual cost remains when the ntx builder still executes each transaction to make the decision. If we could have a way for users to pay the ntx builder even w/o their tx being included onchain, that'd be ideal. This might be achieved through a MustBeErased marker on a NTXBuilderNote in a separate tx, but I haven't thought about this too much.

[PhilippGackstatter]

I'm largely aligned with that, but am not sure about two things:

• Dry-Running network account transactions.
• The MustBeErased marker with chained transactions,

Dry-Running network account txs

This is the part I'm least sure about. It seems tricky to do this in general. The network account could have a different state against which I dry-run versus when the note is actually executed. This could affect fees quite a bit. Same for the other notes that are included in the same network transaction.

The alternative idea of letting network account authors specify fees puts the burden on them. This should result in better fee estimations, but the downside is also significant.

Pass-Through Procedure

The network account exposes a single, simple procedure.

The script you've shown doesn't need access to account APIs, afaict, so why does this need to be a procedure at account level rather than a note's script?

The procedure/script of the NetworkSponsorShip note you've shown creates a note (presumably with MustBeErased) and moves the fee asset to it. Additionally, it would ensure that its companion feature note is present in the input note set to make sure it cannot be consumed without the feature note, right? We could technically allow defining multiple companion notes, but since these notes are erased anyway, it may be simplest to have a 1:1 relationship between feature and fee notes.

but in Phase 1 we need to decide what the user-facing story is for a stranded FeatureNote

Given that we can set fees pretty arbitrarily as long as the network is centralized, a simplifying approach could be to set fees low enough such that overpaying fees by a relatively large margin would be acceptable such that stranding of feature notes would become very unlikely.

But, I think a top-up mechanism will be needed anyway in the future, so we could ship this as well.

Chained Transactions

The trickiest thing about MustBeErased seem to be chained transactions. You could have a user transaction that triggers a network transactions that triggers an arbitrary number of other network transactions. These would all potentially create sponsorship notes (to fund the next transaction) with a MustBeErased marker, which would prevent inclusion of the entire chain of transactions until the chain-ending tx is available for inclusion. For instance, a user creates a B2AGG note that is consumed by the bridge, which then creates a BURN note that is consumed by the faucet.

In more detail:

• User transaction (local) [] -> UserAccount -> [B2AGG, FEE, NETWORK_SPONSORSHIP]
• Bridge transaction (network) [B2AGG, NETWORK_SPONSORSHIP] -> Bridge -> [BURN, FEE, NETWORK_SPONSORSHIP]
• Faucet transaction (network) [BURN, NETWORK_SPONSORSHIP] -> Faucet -> [FEE]

I'm assuming that all FEE and NETWORK_SPONSORSHIP notes are created with MustBeErased. This means the first two transactions cannot be included in a batch until the third is also available. I also assume that one network sponsorship note has the ability to create another network sponsorship (like in the 2nd tx).

It seems like there could be ways for this process to become stuck. Suppose the ntx builder creates a transaction against the bridge with 3 B2AGG notes, which is within limits by itself. That however creates a dependency on 3 more faucet transactions to also be included in the same batch. Additionally, the 3 user transactions that created the B2AGG notes must necessarily be included. The point here is to show that the dependencies are unforseeable in general and each network transaction created by the ntx builder could theoretically increase the set of required transactions. This seems pretty tricky for the mempool. Right now, it only needs to fulfill dependencies on the input side, but with MustBeErased, it also needs to fulfill dependencies on the output side, that is, dependencies become bidirectional.

One notable thing in general is that network account authors need to ensure that they only create MustBeErased notes targeted at other network accounts, otherwise the network transaction can only be included when a certain user's transaction has been included, and that must be avoided. In this case, the user would have some control over the liveness of the network account.

The above contains two main points I wanted to make, so to summarize:

• If we have MustBeErased, the ntx builder and batch builder will need to fulfill dependencies on both input and output side.
• Designing chaining into the fee approach in combination with MustBeErased for network accounts may not be a good idea (or if at all, at most for a depth of ~1).

The alternatives I can think of:

• Use a chaining design for the fee approach, but without MustBeErased after depth 1. Higher fees, lower complexity. But, lower complexity only for the fee approach, not the mempool in general.
• Another approach is to avoid chaining altogether and instead require users to provide top-up transactions. To take the above B2AGG example, the tx against the bridge account would not create a NETWORK_SPONSORSHIP note. Instead, a user would need to provide a transaction to sponsor the 3rd transaction against the faucet. That tx would create a NETWORK_SPONSORSHIP note with MustBeErased.
  • This works when the incentives are aligned: If a user wants to mint something, they are incentivized to provide that transaction. In this example however, users don't benefit from executing the BURN tx against the faucet, so the burn note likely gets stuck.
  • Downside: Users need to create and sign a separate tx (bad UX).
• To avoid the downside of signing a second tx, the NETWORK_SPONSORSHIP note could also be created in the original transaction (1st tx above). The client/wallet would have to be aware that the B2AGG note spawns a BURN note that will require a sponsorship note. Not sure how easy or hard this would be.

To limit mempool complexity, we could disallow creating notes with MustBeErased when any input note already has the marker. This would enable some of the optimizations, but only allow chaining two transactions, not more.

Summary

• Network account authors need to ensure that they only create MustBeErased notes targeted at other network accounts, otherwise users have a "veto" for network account liveness. This would need to be well-documented.
• MustBeErased adds more complexity than I had originally thought (introduces forward-pointing dependencies for transactions).
• Chaining notes with MustBeErased has negative effects for liveness at the network account level, but potentially also network level.
• The simplest design is avoiding MustBeErased but it has significant other problems (higher fees, more nullifiers).

[mmagician]

To limit mempool complexity, we could disallow creating notes with MustBeErased when any input note already has the marker. This would enable some of the optimizations, but only allow chaining two transactions, not more.

That's very pragmatic, I think we can start here and then if we need to cover more use cases, we can expand the functionality.

Chaining notes with MustBeErased has negative effects for liveness at the network account level, but potentially also network level.

I think this cannot be prevented in general, but users implementing such chains outside the provided standards will experience poor inclusion metrics (which is generally the case for users doing stupid things). So as long as 1) unintended/unforeseen user actions don't crash the network; and 2) we cover the intended use case with standards; this is ok 👍🏼

---

One note on the "Dry-Running network account txs" which we covered in the call but not this post:
We'll likely need a 3rd party service, similar to the remote prover, for dry-running the transactions.
The idea is that users can dry run anything, and this may or may not become the default for most transactions against small network accounts, but there will be an offchain service that keeps the latest state of the network accounts (kind of like the db replica) and can realistically dry-run the transactions. This won't provide a perfect estimate, because the state between the estimation and actual proving might drift, but should be good enough in most scenarios.

---

Another point that was not covered explicitly in this post (nor was it raised by you @PhilippGackstatter , but I think it's important to clarify), is that it operates under the assumption of "application fees" covered under the FeatureNote. By application fees I mean things like:

• AMM charging 1% for swaps
• prediction market charging $1 per bet
• etc.

These are a separate concern from the protocol fees, and IMO the network account should not have to care about extracting the application fee from NetworkSponsorhipNote (e.g. take $1 for the application fee and forward the rest to the FeeNote output).
Instead, application fees should be processed in the FeatureNote logic (e.g. take the swap-in amount, subtract fee, calculate swap-out amount).

This lets us standardize the processing of NetworkSponsorhipNote / FeeNotes, and let each application handle their application fees separately.

[Mirko-von-Leipzig]

A bit of a tangent; but since the primary problem with having network accounts handle fees seems to be complexity for the authors, could we not create some basic standards for this instead?

We could start simple e.g. just a constant $$$, maybe add rough scaling with estimates etc. And aspiring authors could optimize this over time? I imagine network accounts could also execute some examples before they deploy to get a good feel for what could happen? Many use cases would be basic notes so costs should be fall within a narrow band fairly deterministically for those iiuc?

So we get out the starting blocks with KISS, but leave room for evolution and use case specific optimisations? Authors that dgaf can use the standards and settle for slightly suboptimal, which is what we end up with in alternate implementations regardless I think?

[mmagician]

could we not create some basic standards for this instead?

we totally should if we go down this route, but I'd argue that application developers should never have to think about protocol fees. If we set simple constant fees now, but let devs evolve them later, then we reasonably expect application developers to fiddle with protocol fees, which is exactly what we want to avoid.

Instead, devs should only care about application fees, which, as I explained in my 3rd point here, should be de-coupled from NetworkSponsorhipNote & FeeNote concerns.

[partylikeits1983]

I think the chained-transaction case @PhilippGackstatter raised is the deciding factor for which route we take; we already have this pattern with: B2AGG -> bridge -> BURN -> faucet.

Single-note version: the network sponsorship fee would be in the note and represented in the NetworkAccountTarget attachment (@bobbinth's sketch above, with the fee: FungibleAsset field). A standard pay_fee procedure reads the attachment of the active note, takes the fee asset out of the active note, and returns the remaining assets, so business logic of the note isnt modified at all to account for fees.

The ntx note chain then composes like this:

1. User creates the B2AGG note with attachment fee = fee_bridge + fee_faucet.
2. The bridge consumes it, collects the full fee via pay_fee, and when it creates the BURN note it sets that note's attachment fee to fee_faucet, funded from the budget. It keeps fee_bridge for its own tx.
3. The faucet consumes BURN, collects fee_faucet, burns the rest.

The general idea: a network account's fee for a note = its own cost + the fees of the network notes it will create (priced via FPI compute_fee on the downstream account, like the bridge -> MINT -> faucet example in #2901). Fees just flow down the chain like any other asset: no extra notes, no MustBeErased, no mempool changes.

The sponsorship-note design hits its worst case on this exact chain: every hop needs a fresh sponsorship note, which means either two extra notes per hop or the bidirectional-dependency problems Philipp described.

I'd still keep the best part of the pass-through proposal: app devs never write fee logic. FeeManager + FlatFeePolicy as standard components gets us that (set a flat fee per script root, or leave it free), and the ntx builder's execute-before-prove profitability check works the same either way.

If there are no strong objections I'd take this back to #2901 and start on the first PR so we can evaluate it against the agglayer flow in miden-testing.

[mmagician]

(set a flat fee per script root, or leave it free)

I don't think this will work in the long term, because, as described already in my comment above, we eventually expect that developers will want to optimize fees. At which point we'll need to refactor how fees work, and break all users' existing code (force them to upgrade). So this is extremely important to get directionally right. We can take a staged approach (e.g. the phase 1 <> phase 2 approach described above), but switching from account-controlled fee scheme to dry-run controlled scheme is directionally breaking, not staged.

---

The approach with dry-running can somewhat straightforwardly settle the depth=2 chain you describe.

The main challenge comes down to the following question:
Given a single NetworkSponsorshipNote, how does the network account know how to split its assets to its own tx vs. to the next network account in the chain?
There are two subquestions here, actually

How to encode the costs of the transactions in the chain?

The answer is that we need to encode the "list of costs" into the NetworkSponsorshipNote's attachments. e.g.:

attachment_0 = 10
attachment_1 = 12

(Under the, I believe reasonable, simplification that the NetworkSponsorshipNote only carries a single asset id)

Then, the re-usable component of the network account would do something like:

1. Consume the feature_note_0 + network_sponsorhip_note_0
2. Read the attachment value in the first position, and move as much funds out of network_sponsorhip_note_0 into fee_note_0
3. Read the rest of the attachment values, and create a new (non-MustBeErasable as per @PhilippGackstatter's suggestion) network_sponsorhip_note_1 with the tail of the original: attachment_1 = 12, alongside the feature_note_1 targeted at the second network account.

Then, the second network account has the same re-usable component installed, and:
4. Consumes feature_note_1 + network_sponsorhip_note_1
5. Reads the first value from network_sponsorhip_note_1's attachments, and moves this amount of the asset into fee_note_1
6. No more attachment values left, so it doesn't create any further NetworkSponsorshipNotes

So this is how we transmit the information (encoding). The remaining question is how to figure out to compute these costs.

How to compute the costs of the transactions in the chain?

Here we rely on dry-run again.

1. User dry-runs the transaction
2. The dry-run returns a cost list
3. Encode this cost into the single NetworkSponsorhsipNote as described above

The dry-run process can relatively easily see that when they simulate the consumption of feature_note_0 + network_sponsorhip_note_0, the network account outputs a further feature_note_1. So they can follow this simulation chain and compute the costs, in theory indefinitely.
But if we're providing the dry-run/estimator service off-the-shelf, I think it makes sense to cap the chain depth at 2 (which is the case for agglayer bridge -> faucet, and the deepest practical use case we have). If users want to run longer chains, they can spin up their own dry-runners (at the increasing risk of the fees drifting and some down-the-chain tx failing to get included).

[partylikeits1983]

@mmagician I don't think the network account would need upgrading when pricing changes, and that removes your concern that network accounts would "directionally break". The reason it looks breaking is the assumption that account-side pricing means custom per-account & per note fee logic that has to be rewritten when fees are dynamic. It doesn't. It's possible to make the network account fee pricing fixed like this:

fee_factor    # per-note-script weight, stored on the account: NOTE_SCRIPT_ROOT -> fee_factor
congestion_oracle     # a single network-wide value, read at consumption time
fee_asset_amount = congestion_oracle * fee_factor

The note's NetworkAccountTarget attachment would carry a max_fee. The actual fee asset would be in the note vault (the attachment would just make it more obvious what the network fee asset is for the ntx builder). The pay_fee proc would compute congestion_oracle * fee_factor, then assert it is <= max_fee, and take that amount out of the note. If congestion_oracle * fee_factor > max_fee, the note is not consumable against the account and the ntx builder skips it. Again pay_fee would be in the network account, so the business logic of the network note doesn't need to change at all aside from having this new attachment.

In a way, this is very similar to EIP-1559. fee_factor is the intrinsic cost of the operation (the "gas" a given note script costs), congestion_oracle is the base fee that moves with demand. A note that offers too little under current congestion simply doesn't get consumed against the network account.

Composability with Dynamic fees:
The congestion_oracle value would essentially be FeeParameters::verification_base_fee (already in tx kernel), the same value compute_fee uses to price the network account's own transaction.

So there's almost nothing new to build for v1 for ntx fees: the base fee is already a committed block-header value the kernel reads today, so the only addition is a small accessor to expose it to account code (like get_block_number), no new value to bind. pay_fee then reads the same base fee the kernel does, held constant for now. To be clear it's the base fee parameter, not the kernel's final computed fee, which is only known at the end of the epilogue and covers the whole tx rather than one note. fee_factor is a pre-committed (by the network account developer) per-note estimate of that note's fees, and verification_base_fee * fee_factor reconstructs the note's fee slice into the kernel's fee units (calibrated dry-run-once by the operator, bounded by max_fee).

Now back to your "optimize fees later" scenario. Going from flat to demand-based pricing just means verification_base_fee starts moving with demand instead of staying constant (this is #1686, which is itself framed as EIP-1559-style). The network fee tracks it automatically because the account reads that value live (congestion_oracle). The account code doesn't need to change, the note format doesn't change, and the compute_fee signature doesn't change, because the demand input comes from a block-header value the account reads. The operators of network accounts could tune fee_factor per script with a normal admin write (e.g. via the RBAC access-control component or AuthAcl), not a redeploy.

This also handles the usecase where you have chained network transactions. Each "hop" in the chain would set the max_fee for the next hop: when the bridge creates the BURN note, it funds that note's max_fee with an FPI fee-estimate call on the faucet (an account-level estimate_fee, not the kernel's compute_fee), which returns verification_base_fee * faucet_factor[BURN] under current conditions. So there's no attachment_0 = 10, attachment_1 = 12 snapshot that goes stale while the note sits in the mempool, and no depth cap. The fee just flows down the chain as the surplus of max_fee, priced live at every account it passes through.

Simplicity:
And this keeps the ntx builder simple, which I think is the main point. of having the fee inside the network note The fee is in the attachment the ntx builder already reads to route the note, so the underpay check is just a value comparison with no execution.

Having the fee inside the note eliminates:

1. sponsorship note to feature note matching logic on the node,
2. "two sponsorship notes for one feature note" griefing case,
3. doubling the note count per hop,
4. per-network-account mempools.

The clean version of the sponsorship design (atomic, zero net notes) needs unauthenticated note propagation through that mempool, which @Mirko-von-Leipzig mentioned is being removed from the node. And in the NetworkSponsorshipNote proposal, the Phase 1 fallback commits feature notes onchain before we know they'll be processed, so we might need some intermediate logic for reclaiming notes (business logic & fee sponsorship notes) that never get picked up by the ntx builder. Seems complex to be honest for an intermediate step

To be clear what I'm proposing above, is not mutually exclusive to your atomic ntx idea @mmagician. This single-note flow would just be the standard, and it doesn't stop a batch builder from later supporting the unauthenticated note propagation that makes the feature note + fee atomic. A custom batch builder or ntx builder (batch builders & ntx builders should be unified, but thats a separate discussion) could opt into that and pick these notes up as unauthenticated inputs, so we'd still get the atomic / zero-net-note property as an optimization layered on top. The v1 standard stays simple, and atomicity becomes a builder-level feature for whoever wants it (later on).

overloading the feature note concern:
I am still not 100% sure why you think having the fee asset inside the network note makes things more complex. For example in the EVM, msg.value rides with every EVM call, and gas-forwarding choices ride with every external call, nobody calls that mixing concerns. A note calling into a network account and paying for that call is the same pattern. The business logic of the network note is untouched, the procedure inside the account that the network note calls just gains one pay_fee line, and the only extra data it carries is an asset in the vault plus a max_fee in the attachment.

For example:

@note_script
begin
    call.ntx_account::some_proc
end

----

# ntx account

pub proc some_proc
    exec.do_some_logic
    exec.pay_fee <-this is where the fee logic for pulling the asset out of the note would live, on the account, not in the note
end

In summary, I really think having the fee asset live inside the business logic note, specifically in the case of network notes is the simplest and most robust approach and composes nicely with batch kernel fees.

[bobbinth]

I think throughout this discussion we've come looked at several dimensions "jointly" but it may make sense to spell them out separately. The dimensions are:

1. Where does the fee asset go. The options are: (1) into the note itself or (2) into a separate sponsorship note.
2. Does the user estimate the fee needed for the network note to get consumed in a future transaction. The options are: (1) dry-running (probably with assist from an off-chain services) or (2) ask the destination account to estimate the fee.
3. Do we separate the application fees and protocol fees, with options: yes and no.

@mmagician's proposal selects the following properties:

1. Separate sponsorship note.
2. Dry-running.
3. Yes.

The proposal I described selects the following properties:

1. The note itself.
2. Target account estimates.
3. No.

It is also possible to imagine other combinations (e.g., separate note, target account estimates, no).

Separately, we have the question of enforcing note erasure - but I think it is somewhat orthogonal to the above considerations as it can work with either of the combination of properties (I think).

I'm going to try to summarize one more time pros and cons of various approaches (in separate threads), but overall, my hierarchy of needs is:

1. We need to make things as easy for the user as possible. This includes making transactions fast and ensuring that they almost never fail.
2. Next, we have the developers: we want to make sure that writing smart contracts is as easy as possible, and there are no weird edge cases.
3. Next we have protocol developers (us) - we want the protocol to be simple (mostly to avoid bugs).

It is OK to make the life of the lower group on the poll more difficult if it simplifies the life of the upper group - within reason, of course.

[PhilippGackstatter]

The following explores another alternative to eliminate fee estimation from the equation, but comes with its own significant downsides. The overall conclusion is that the existing approaches probably end up being better. I'm mainly posting it so that if anyone else has an idea for improvement, this might become viable.

The core ideas are always: Avoid estimation by keeping track of the user balance somewhere and debit the fee from that first.

The dimensions are:
[...]
Does the user estimate the fee needed for the network note to get consumed in a future transaction. The options are: (1) dry-running (probably with assist from an off-chain services) or (2) ask the destination account to estimate the fee.

Another possible option here is that if a network account could estimate fees during execution and then take the fee from the user, it would avoid the need for any upfront estimation, which I think would be really good. Mainly because I think relying on 3rd party services for such a core part of the protocol is bad for self-sovereignty. We rely on services in other areas, like the remote prover or the Guardian, but you can still use the network without those, albeit less conveniently (prove locally, backup your own state, ...). A dry-run service on the other hand cannot realistically be replaced with a local run, afaict. Ideally, we'd also avoid that network account authors need to provide fee estimations.

Approach A

Core idea: Each network account holds balances of users from which the fee is debited. Users top up via notes.

Making this more concrete:

• on first interaction with a network account, use a relatively big flat fee FLAT_FEE that is definitely going to cover the execution. The network account will internally track the amount that each note sender has paid, e.g. a account ID |-> balance map.
• on all subsequent interactions, the client first checks the existing balance EXISTING_BALANCE of the network account and only adds FLAT_FEE - EXISTING_BALANCE to the note. This essentially creates a top-up mechanism.

Pros:

• Does not require dry-running network account execution.
• Does not require the network account author to estimate fees.
• Fee efficiency: The user always pays a bit more than necessary, but starting from the 2nd transaction the mechanism is self-correcting so that a user always effectively pays roughly the fee that was actually required. Some excess always remains in the network account, but this amount should be negligible over the long run.

Cons:

• Requires a lot of extra storage per network account: Every user that interacts with the network account adds an additional 64 bytes (key value words) to the internal bookkeeping map. E.g. 100_000 users means 6.4 MiB, for every network account. This is prohibitively expensive for the network.
• Assumes that the network account correctly keeps track of user balances, but there is no way to guarantee this. A network account could be written to simply drain all user balances. Though, this is pretty much the same trust assumption we have as in the option where network account authors estimate fees and users simply trust those values. A mitigating circumstance is that user balances would generally be quite small and clients/wallets could detect malicious network accounts.

So, while I love the Pros, the storage con is really bad.

Approach B

Core idea: Fee account that holds the balances like in Approach A, but shared globally to avoid the storage-per-network-account downside.

A possible fix is to have a globally shared network fee account. Users top up their balance in that account before interaction with any other network account. Users now send a feature note to a regular network account. During this network transaction NET_TX, the network account estimates the protocol fee FEE and computes each input note's part of this fee. To illustrate, if there were 3 input notes, the fee could be FEE / 3 (though we'd want something better here). NET_TX emits a MustBeErased FEE_DEBIT note per sender to the network fee account. It consumes those notes atomically in a tx FEE_TX, in the same batch and debits the FEE/3 plus the partial fee for FEE_TX itself from each user and outputs that in a fee note. The fee note is marked to let the batch builder know that this note pays for both NET_TX and FEE_TX. This requires an extra transaction to be executed against the network fee account, but assuming it is a single global one, its cost would amortize over all network transactions in the batch, which seems acceptable.

The main upsides of this approach are:

• Each user ends up paying close to what the network transaction actually cost (minus the in-transaction estimation error). No need for pre-estimation or (large) overpayment and no need for refunds.
• Chains of transactions can each debit from the network fee account individually. The challenge is to pass the debit authorization (see downsides) from the user along the chain, but this should be more easily doable than passing along a fee asset like in the single note design.
• The network fee account can handle fee conversions. Conceptually: User tops up in POL, network account requests payment in USDC, network fee account does the swap.

The main downsides of this approach are:

• With a centralized NTX builder, this should work, but with decentralized NTX building, it likely results in contention conflicts on the global network fee account. This is the point that breaks this approach in practice. The permutation of users, ntx builders and network fee account cannot be sharded cleanly, and so the potential for conflicts is very likely. If such a conflict occurs, due to MustBeErased, the network tx itself cannot be included and needs to be re-executed.
  • If we could assume that there is one fee account per ntx builder, then this might work. Users would have to interact with multiple such accounts, but the contention would no longer be an issue.
• Users need to authorize the debiting in the network fee account with a signature, otherwise anyone can drain the balances.
  • This also infects the feature note, but it could be purely part of the NetworkAccountTarget attachment and so wouldn't be as infectious as including the fee asset in the note itself in the single note design.
  • Using an actual signature though is probably prohibitively expensive.
  • We might be able to get around the signature requirement if we had note constructors. The emitted FEE_DEBIT note could check during construction that a note that originates from user X was consumed, and only then allow creation of itself with debitor = X, but this would require a more careful analysis.
• Small capital lockup required (seems acceptable).

Approach C/D

Core idea: Replace the global fee account with a per-user network fee note to avoid the contention.

There is a version of this where you replace the single global network fee account with a per-user network fee note. This note contains enough funds to cover dozens or hundreds of transactions. This note is passed along to a network transaction and it takes out the appropriate amount from the note, and moves the remainder into a new note, for the next use. This ends up having similar set of downsides as non-erased fee notes as we had them defined so far, that is, a new nullifier for every consumption and the fees for the re-creation of the note. Otherwise, this eliminates the contention issue of the global fee account approach.

Basically, with this execute-first, debit-second approach, we either get an extra transaction or an extra note.

It would be cool to use this approach with a lightning-network-like mechanism where there is a payment channel between the user and the network account. I also don't really see that working in practice, because the note would have to be bound to a single network account and not be reclaimable so the network account cannot be cheated. Its also unclear at which point in time the network account would actually consume the note - and what if the user only interacts with an account a few times?

So, in summary, I like the execute-first, debit-second approach because it avoids the need for upfront estimations, but the downsides seem too big.

[bobbinth]

Sponsorship note (dry-run, separation of fees)

The mechanism of this approach is described in #2968 (comment). It is quite elegant, but there are still some open questions about it in my mind:

Chained transactions

How exactly would "chained transactions" work? Enforcing atomic transactions across more than a single "leg" of the chain is likely not going to be practical. So, in the case of B2AGG -> BURN chain, the B2AGG will most likely be processed in one batch, and BURN will be processed in another. This creates two issues:

• Even with MustBeErased functionality, we will end up with some proportion of sponsorship notes committed to the chain (which is wasteful). What this proportion would be is difficult to say - it could be negligible or could be quite significant.
• There is no incentive for the user to pay the fee for the BURN note consumption. So, it would have to be paid by the bridge account. This means that the bridge account would somehow need to check that the fee carries by the sponsorship note can also cover the consumption of the BURN note. But if the account needs to do this, IMO, this breaks the original intent of the construction (e.g., accounts shouldn't care about protocol fees).

Currency for application fee payments

One of the goals of the fee mechanism is to make sure we can avoid the situation where the user has token X but they need to pay fees in token Y. This covers both application and protocol fees. So, for example, if the bridge account requires USDC for application fees and my account has only ETH, I should be able to bridge my ETH out.

The proposal makes payment of protocol fees in multiple tokens trivial - but since the application fees are treated separately, we still have a problem of the user not having the tokens required by some contract. This would bring us back to:

1. We put a burden of converting tokens on the network account (i.e., the bridge).
2. We put the burden on the user to obtain the tokens they need to pay applications fee in.
3. We come up with some parallel mechanism for converting application fees from one token to another.

None of these look too attractive - but maybe there is an approach I'm not thinking about.

Other potential complications

• The approach does assume there needs to be a service for dry-running network transactions that most users would be able to use. This will work, but it does add more complexity into the mix. Though, maybe having such a service in inevitable regardless.
• It does complicate the logic of the network transaction builder - but here too, we may want to implement MustBeErased functionality regardless of which fee proposal we go with.

[bobbinth]

Same note (target account estimates, single fee)

I sketched out this approach in #2968 (reply in thread) and some of the following comments, but to describe it fully:

The fess are included in the "feature" note. To indicate which asset is supposed to be the fee, we'd create a new attachment - or maybe just bundle this info into the NetworkAccountTarget attachment. Network accounts would implement the "fee manager" interface that would allow the user to call something like estimate_note_fee procedure.

To make the consumption of the notes ergonomic, we'd need to introduce the concept of note prologue/epilogue, and network accounts would be able to remove the fee from the note in the prologue (i.e., right before a note is executed). This would require a new kernel procedure (e.g., remove_asset_from_note).

The main reason for the above is that we don't need to create different versions of various notes - e.g., P2ID for local and network accounts.

The main downsides of this approach are:

Requires SPAWN note

To enable paying fees in multiple tokens, we'd need to rely on something like a SPAWN note (i.e., a note that when consumed creates another note). The concept of the SPAWN note does introduce non-trivial amount of complexity (mostly on the client/wallet side), but more importantly, it breaks some notes. For example, a P2IDE note would change the "sender" when it is generated with a SPAWN note. So, the original sender would not be able to re-claim it. Maybe there are ways to get around this, but I'm not seeing them yet.

Requires protocol changes

Here, I'm not so much concerned about note prologue/epilogue - which I think we might need to introduce anyway at some point (see #2187 (comment) for some context). But the need for remove_asset_from_note feels a bit dangerous. Maybe there is a way to put restrictions on this procedure somehow (e.g., it is only available in note prologue).

Puts fee estimation burden on contract developers

The responsibility for estimating fees would fall onto the smart contract developers. On the one hand, they should be able to do this correctly as they know the internal details of the contract they are developing. But on the other, poorly design fee estimators would lead to poor user experience.

I'm actually not too concerned about this point because, initially, our fee model is going to be pretty simple, and later on we can come up with a set of standards that would help the developers estimate fees easily/correctly.

[partylikeits1983]

Two Four points:
1.

The concept of the SPAWN note does introduce non-trivial amount of complexity (mostly on the client/wallet side), but more importantly, it breaks some notes. For example, a P2IDE note would change the "sender" when it is generated with a SPAWN note. So, the original sender would not be able to re-claim it. Maybe there are ways to get around this, but I'm not seeing them yet.

Easiest way to solve this is to put the "owner" account id as two felts in the note storage. This is how its been done in the PSWAP note for some time now.

Puts fee estimation burden on contract developers

I think this is fine as well. I think this approach is the most straight forward of the three you've outlined. Yes it creates slightly more complexity for dev who is building a ntx account, however, we can add more logic later which will improve the devex of fee estimation for network accounts.

Again as discussed, this is at the standards level and can be improved later on. I just think this approach as described above is the most pragmatic approach to unblock us for ntx fees. Yes it has its downsides such as the dev having to estimate fees, but I think when weighed against other options this approach seems like the variant with the least complexity and potential footguns.

we'd need to introduce the concept of note prologue/epilogue

This would be useful in other contexts such as in the polymorphic procedure calls issue. Although Zoro team said they may not be using this feature since their architecture design changed since then.

[bobbinth]

Sponsorship note (target account estimates, single fee)

This is a kind of combination of the two - we still have two separate notes: a feature note and a sponsorship note, but the sponsorship note carries both protocol and application fee. And the way the user gets the fee is by calling something like estimate_note_fee on the target account.

This removes some of the problems - specifically, chained transactions are not an issue, and token conversions become much simpler (e.g., the batch builder would consume a sponsorship not with token X and produce a note with token Y). But it still has some downsides:

1. It still requires one extra note per feature note - and again, it is likely that at least some of these will end up on chain.
2. It still puts the burden of fee estimation on the smart contract developer.
3. It does create some edge cases and complexity we'll need to think through (e.g., multiple sponsorship notes for the same feature note, but each sponsorship note has a different token in it).

As I mentioned in the previous comment, I'm not too worried about 2 - but I worries about 1.

On the other hand, it does also enable some new capabilities. For example, if a feature not is "stuck" in the mempool because it doesn't have a corresponding feature note with sufficient fees, the user could send another note with more fees and make the feature note consumable.

[partylikeits1983]

It still requires one extra note per feature note

I think this approach gets overly complex in the case of chained network txs. At first I liked this approach, but then when you try to draw it out step by step, it gets hard to track all the notes in a given ntx: 1. business logic note 2. fee sponsorship note 3. fee note for batch producer.

[PhilippGackstatter]

Fee network account

I thought a bit more about approach B from here. Having a single global fee account has risks in terms of contention, but in return it enables a network fee approach with very nice properties for the developers, as they don't need to think about protocol fees at all. It also commits no fee-related notes on chain and requires no dry-running or fee estimation.

This approach doesn't quite fit neatly into the properties that @bobbinth described, but to spell out the differences:

• Where does the fee asset go? Into a dedicated fee network account.
• Does the user estimate the fee? No, and neither does the network account author. The standardized AuthNetworkAccount component (written by us) would estimate and handle the fees.
• Do we separate the application fees and protocol fees? Yes, protocol fees are handled in the background, so they are separate.

Approach

Core idea:

• Users top up fees in a global fee network account. This account holds a simple user |-> balance storage map.
• A network transaction estimates what the creator of the transaction owes, then emits a FEE_DEBIT note to subtract that balance in the global fee account in one atomic step.

To illustrate, consider the B2AGG -> BURN chain of transaction. The atomic steps (= same batch) are the following, where # denotes MustBeErased notes:

• Top-Up creation transaction (local tx)
  • Bob takes a few dollars out of his account and adds it to a TOP_UP note.
  • [] -> Bob's Account -> [TOP_UP, #FEE].
• Top-Up consumption transaction (network tx)
  • The network transaction consumes the TOP_UP note which increases Bob's balance in the fee network account.
  • [TOP_UP] -> NetworkFee -> [#FEE].
• Feature transaction (local tx)
  • [] -> Bob's Account -> [B2AGG, #FEE].
• Bridge mutation (network txs)
  • [B2AGG] -> Bridge -> [BURN, #FEE_DEBIT]
  • [#FEE_DEBIT] -> NetworkFee -> [#FEE]
• Faucet mutation (network txs)
  • [BURN] -> Faucet -> [#FEE_DEBIT]
  • [#FEE_DEBIT] -> NetworkFee -> [#FEE]

A couple of notes:

• The TOP_UP transaction is needed on first interaction to increase the balance in the fee network account, and again whenever the balance is depleted. The topped up amount should ideally be chosen such that this is only necessary every 10th or 100th network tx. A user can also retrieve the remaining balance at any time, for a clean exit.
• In the top-up consumption tx, the fee is taken out of TOP_UP itself.
• FEE notes are the batch-level fee notes, nothing changed.
• The bridge and faucet mutations consist of two transactions each, which can only be committed in the same batch, due to FEE_DEBIT being marked MustBeErased.
• In the bridge and faucet mutation, the FEE pays for both the actual "feature note" transaction, as well as the "debit tx". So the FEE would need to be able to express that it pays for the tx itself, plus an optional other tx, but this should be doable.
• If there were multiple B2AGG or BURN notes from distinct originators, there'd be a dedicated FEE_DEBIT and FEE note for each originator. This proliferation is fine because these notes are all erased.
• Before a NTX builder starts execution of notes, it could check that the originator of the note has enough funds in the fee network account. This avoids creating transactions that would not be include-able due to insufficient funds. The ntx builder could simply require a certain minimum balance to be present, to avoid having to estimate the cost of the transaction.
• The execution of the network fee transaction can start when the corresponding "feature" network transactions have finished execution and go into the proving phase. Since execution is much faster than proving, this should therefore only add the fee-tx execution latency to the overall batch, which seems acceptable.
• The transaction against the NetworkFee account can consume all FEE_DEBIT notes and as such, the cost for its execution and proving amortizes over all these mutations. In other words, even if there are 5 txs against the bridge, only one additional tx against the NetworkFee account is required.

The properties of this approach that I see are the following.
Pros:

• There are no extra fee-related notes committed to chain, even in the case of chained transactions like above. The only notes committed to chain are B2AGG and BURN.
• The approach cleanly separates a chain of transactions into atomic steps. In particular, there is no MustBeErased dependency between the bridge and faucet transaction.
• Say we have 3 B2AGG notes consumed in the same transaction. Now each originator only needs to pay its fair share of 1/3, rather than the full cost of a B2AGG note.
• Users, clients, network account authors and probably even the ntx builder do not need to estimate fees. We can include the fee logic in AuthNetworkAccount (i.e. estimate fees, output fee debit notes).
• The fee network account can potentially implement or facilitate swaps. E.g. conceptually the account could allow users to top up in POL and ETH, and the account swaps it all to USDC, though how exactly that works I don't know yet. Maybe this can nicely integrate with the "in-protocol DEX".
• The FEE_DEBIT note could also just move the balance from the user to the batch builder within the fee account, avoiding the need for any FEE notes and the batch-level tx that consumes them. So, batches that purely contain network txs wouldn't need that extra tx.

Cons:

• With one NTX builder this should work really well, but when we have multiple ntx builders, they would all mutate the same account and that would cause conflicts.
• The chain from B2AGG creation all the way to the FEE_DEBIT note in the faucet mutation needs to somehow authorize that the creator of the note can legitimately be debited. At the same time, it must be impossible to illegitimately create FEE_DEBIT notes.
• Users need to top-up their balance in the fee network account before interaction. Annoying for users that just want to execute one transaction. There is no way around this and I consider it suboptimal, but acceptable.

I want to explore possible solutions to the primary cons in the rest of this post.

Multiple NTX builders

This is not a concern now, but the solution should of course work long-term.
The core problem is that, for example, the bridge tx is executed by ntx builder 1 and the faucet tx is executed by ntx builder 2, due to how we shard network accounts between different builders in the future.

The simplest solution is to say that NTX building stays as a centralized standard. Problem solved 😅. Probably not the most scalable solution.

Fee Account per NTX builder

To rule out fee-related conflicts we could assign one fee account to a ntx builder. This could work if the number of ntx builders is relatively small. The main burden is put on the user, as they need to top up their balance in all of these accounts. So, not that great.

Dedicated Fee builder

Another way is to have a dedicated ntx builder just for mutating the global fee network account. So, all regular ntx builders build their sets of transactions and directly send the set of FEE_DEBIT notes to the dedicated builder, which processes them all. This may require propagating MustBeErased to the block level, but this wouldn't be impossible.
This creates a certain centralization risk around the dedicated fee builder, but this responsibility could be rotated per block with the right incentives. In the worst case, anyone can always mutate that fee account, so there could be fallback builders. So, it is not a single point of failure.

One concern is that this builder would need to process (very) large transactions (one FEE_DEBIT note per network transaction). This could be split up. So, if there are 1000 network txs per second, we'd need to process the 1000 FEE_DEBIT notes against the fee account. But this could be split across transactions that build on top of each other.

There is also the risk of two ntx builders successfully checking the balance of a user independently, executing a transaction but then the cumulative balance of the user isn't sufficient to cover both txs. This can be addressed by requiring a large enough minimum balance before an NTX builder executes a tx for a user. Worst case, one batch of network transactions would have to be dropped to make any progress at all.

There is probably a lot more to be discussed about this, but I think directionally it could work.

Debit Authorization

We want to avoid making feature notes fee-aware, but also have them somehow carry the "fee debit authorization" through to where it's needed. The core idea is to use note attachments, which can be independently added to a note without making the feature logic itself fee-aware. However, it requires extra protocol machinery.

Specifically, it would require implementing note and attachment "finalizers". The former was previously and briefly discussed here. To summarize, the main idea is:

• Allow a note to define a read-only finalizer procedure that runs during the epilogue. Its main purpose is to validate the created note.
  • As a simple example, the P2ID note's finalizer could assert that num_assets > 0, which was the idea in the linked issue.
• Allow an attachment to define a read-only finalizer procedure that runs during the epilogue. Here, too, the main purpose is to validate the created attachment.
  • As a simple example, the NetworkAccountTarget attachment finalizer could assert that the contained account ID is valid and its account type is public.

These would be useful independently of this fee approach, but are essential for this authorization use case.

As a third feature, we'd need the tx kernel to track which note created another note, if any. This, for one, would be a pretty simple addition. Then, we define a new attachment and the FeeDebit note.

Tracking note creators

The tx kernel keeps track of this only for the duration of the transaction, and makes it accessible via output_note::get_creator_index. It returns Some(input_note_index) if the note was created by another note and None if it wasn't (e.g. from tx script). The creator note is set to the active note when output_note::create is called.

Example: B2AGG input note at input index 1 creates BURN note at output index 0. output_note::get_creator_index(0) returns Some(1). (This could be made more useful and return something like InputNote(index), TxScript, or ForeignAccount(AccountId) - for the future).

FeeAuth attachment

We define a FEE_AUTH attachment that contains the following data:

pub struct FeeAuth {
    originator: AccountId,
    remaining_budget: AssetAmount,
}

This attachment's finalizer asserts that one of the following is true:

• the originator was set to the native account ID.
• originator was copied over from the creator note's FEE_AUTH attachment and assert_fee_budget_conservation(originator) succeeds (see below).

This results in the following guarantees:

• FEE_AUTH(originator = Bob) can only be present on a note whose originator was in fact Bob, independent of the depth of that chain.
• At most remaining_budget can be taken from Bob's account through created fee debit notes, willingly or maliciously. The budget can be split freely across fee auth attachments and a fee debit note, but at most remaining_budget is spent.

FeeDebit note

We define the FeeDebit note as:

pub struct FeeDebit {
    originator: AccountId,
    amount: AssetAmount,
}

• Note Finalizer:
  • Runs assert_fee_budget_conservation(originator) (see below).
  • Asserts there exists at least one input note with a fee_auth attachment where fee_debit.originator = fee_auth.originator.
  • Asserts that no second FeeDebit note with the same originator was created, to prevent fee draining.
• Note Script:
  • Removes amount from the originator's balance in the account, if sufficient.
  • Creates a FEE note with that amount.

Budget Conservation

We need to ensure that the remaining_budget on authorizations stays the same or is strictly decreasing across all fee auths and fee debits.

Define a assert_fee_budget_conservation(originator) function that:

• Computes input_budget as the sum of all FEE_AUTH.remaining_budget attached to input notes where FEE_AUTH.originator = originator.
• Computes output_budget as the sum of:
  • amount in any FEE_DEBIT output note where FEE_DEBIT.originator = originator,
  • remaining_budget in any FEE_AUTH attachments in output notes where FEE_AUTH.originator = originator
• Asserts that output_budget <= input_budget.

AuthNetworkAccount

It estimates the fee of the current transaction using the estimate_fee kernel procedure, and then computes each input note's share of the overall fee, e.g. either dividing by num_input_notes, or weighted by cycles, etc.

For the set of unique originators across all input notes (to deduplicate multiple notes from the same creator), it creates a FEE_DEBIT note with their fair share.

It also iterates the set of output notes and adds a FEE_AUTH attachment to each one that has a NetworkAccountTarget. This will only add the authorization to network notes. The attachment finalizer validates that the note was created by one of the input notes and that the remaining budget is respected.

Applying it

To make it more concrete, let's apply this to the B2AGG/BURN transaction chain:

• In the feature transaction, B2AGG is created with FEE_AUTH(originator = Bob, remaining_budget = $REASONABLE_DEFAULT). Valid because the originator is the native account.
  • $REASONABLE_DEFAULT is more like max_fee and does not imply that we need to estimate the tx cost. This simplifies it considerably.
• In the bridge transaction:
  • AuthNetworkAccount creates FEE_DEBIT(originator = Bob, amount = $FAIR_SHARE). Valid because FEE_AUTH(originator = Bob) was present on B2AGG.
  • B2AGG creates the BURN note with a NetworkAccountTarget attachment.
  • AuthNetworkAccount adds FEE_AUTH(originator = Bob, remaining_budget = previous_remaining_budget - $FAIR_SHARE) to BURN, which is valid because the attachment was also present on its creator B2AGG.
• In the faucet transaction:
  • AuthNetworkAccount creates FEE_DEBIT(originator = Bob, amount = $FAIR_SHARE). Valid because FEE_AUTH(originator = Bob) was present on BURN.
• When FEE_DEBIT is consumed, the fee network account reads the originator from the note and debits from the account's balance.

This way, only the notes that originate from Bob are actually debited from his fee balance, and at most remaining_budget is taken out.

Note that in all cases, adding or copying the FeeAuth attachment or creating the FeeDebit note is done by AuthNetworkAccount. This means feature and fee concerns are completely separate.

A malicious network note or network account can drain Bob's balance by at most remaining_budget, which is not ideal but acceptable for such an adversarial scenario.

Conclusion

I think that this approach optimizes for this hierarchy of needs:

my hierarchy of needs is:

We need to make things as easy for the user as possible. This includes making transactions fast and ensuring that they almost never fail.
Next, we have the developers: we want to make sure that writing smart contracts is as easy as possible, and there are no weird edge cases.

For the user, it is pretty simple. Top up once. Transactions should be fast. They should basically never fail for fee-related reasons, as long as the balance in the account is large enough.
Developers do not need to care about protocol fees in the large majority of cases.

It pushes most of the hard things to the protocol/standards, which is where they should be.

I think this approach solves most of the issues of other approaches:

• no dry-run fee estimation and therefore no reliance on a third party service.
• no fee estimation by network account authors.
• chained transactions have fewer problems, but not none. A BURN note can still strand with too little remaining_budget.
• it should be possible to implement multi-currency fee payments without involving the user, though I'm least sure about that.

It selects different trade-offs to do this - nothing's for free. It comes at the main cost of additional, significant protocol changes. I deliberately didn't go into details of how this could be implemented for now. These would be useful independently, so it is a net win, from my POV. The other potential cost is the centralized fee account - but I don't see this as a major issue as discussed.

[Mirko-von-Leipzig]

iiuc this means the ntx builder must create batches itself? And its also possible to create multiple ntx transactions which will conflict e.g. by draining the user's network balance so that txs for the same user but on different network accounts won't work?

tbh I suspect the miden architecture will fight us every step of the way. We're optimised for concurrent, message passing, and we're trying to squish that to fit mutable, global, shared state. The exact opposite.

[PhilippGackstatter]

iiuc this means the ntx builder must create batches itself?

Not in the centralized setting, where everything is done by a single NTX builder.
But in a decentralized NTX building future, not all transactions from all ntx builders plus the fee-related tx will fit into a single batch, and so I suspect separate batches would become the norm.

And its also possible to create multiple ntx transactions which will conflict e.g. by draining the user's network balance so that txs for the same user but on different network accounts won't work?

Yes, but I wonder how likely this is. An account's network-tx related activity can generally be observed on-chain, so you can categorise them into low or high activity. For low activity, you require a low minimum balance. For high activity, you require a larger minimum balance, to prevent potential conflicts. I feel like this wouldn't be a major issue, but maybe that's too optimistic.

tbh I suspect the miden architecture will fight us every step of the way. We're optimised for concurrent, message passing, and we're trying to squish that to fit mutable, global, shared state. The exact opposite.

I understand your point, and conceptually I agree. Then again, network transactions already seem a lot more "centralized" than local transactions, as in, there are few entities that build them, I imagine. So, I wonder if a dedicated builder for fees makes it significantly worse.
If this actually becomes the bottleneck, you could still introduce some level of sharding, maybe 2, 4, ... fee accounts with dedicated builders? Not sure either, tbh.

[partylikeits1983]

I like this approach a lot! It’s super easy to reason about and I think it solves a lot of the problems we were grappling with in the various designs above.

It does have some tradeoffs, but I think they are pretty minor compared to the alternatives.

The biggest tradeoff I see is that anytime a user wants to interact with a network account, they need to make sure they already have assets in the global network fee account. That is a bit annoying, but I think this can mostly be abstracted away by the client. The wallet could just keep some small balance topped up automatically.

The second tradeoff is user withdrawals. You mention this here:

A user can also retrieve the remaining balance at any time, for a clean exit.

I think this needs a bit more detail, because I think there is a race condition we want to avoid.

The main thing we want to avoid is something like this:

1. User creates an ntx which does an FPI call into the global fee account.
2. The global fee account says “yes, this user has enough balance to pay for this network tx.”
3. The network tx proceeds.
4. Before the corresponding fee debit is settled, the user withdraws their whole balance from the global fee account.

So I think withdrawals probably need to be two-step.

The user should first request a withdrawal. This would put their fee balance into some kind of withdrawal state / queue. While the user is in this withdrawal state, other network accounts should not allow this user’s network notes to be consumed, because via FPI they can see that the user is no longer in an active fee-paying state.

Something like:

ACTIVE -> WITHDRAWAL_REQUESTED -> WITHDRAWN

Concretely, the user could create a FEE_WITHDRAWAL note which is consumed by the global fee network account. This note would contain the asset account id of the fee asset they want to withdraw.

On consumption, the global fee account checks something like:

hash(user_account_id, fee_asset_account_id) -> fee_balance

If the user has a balance for that asset, the account marks that fee position as being in the withdrawal queue and records the current block number.

I think the storage could look roughly like this:

mapping 1: user_network_fee_balance
hash(AccountId, AssetAccountId) -> FeeAsset

mapping 2: user_network_fee_status
hash(AccountId, AssetAccountId) -> [status, withdraw_after_block, processor_fee, 0]

The key being:

hash(AccountId, AssetAccountId)

is nice because it means the global fee account can support any asset. Network account developers could choose which asset they want to accept for fees, and the global fee account does not need to special-case anything.

So withdrawals can probably just be processed per (user, fee_asset) pair. If a user wants to withdraw multiple fee assets, they can request/process each one separately. Batching can always be added later if we need it.

So the flow would be:

1. User requests withdrawal

The user creates a FEE_WITHDRAWAL note.

It contains:

struct FeeWithdrawal {
    fee_asset_account_id: AccountId,
    processor_fee: AssetAmount,
}

The global fee account consumes this note and computes:

key = hash(note_sender_account_id, fee_asset_account_id)

Then it checks that this key maps to a real fee balance.

If yes, it marks the position as locked / withdrawing:

status = WITHDRAWAL_REQUESTED
withdraw_after_block = current_block + N
processor_fee = processor_fee

Probably N = 1 block is enough, at least in the simple version, but maybe this should just be a parameter. The real goal is just to give enough time so that any accepted fee debits either settle or stop being valid.

At this point, the user cannot use that fee balance for new network txs anymore. Any network account checking the global fee account should reject the user if:

status != ACTIVE

even if the balance is technically still there.

2. Someone processes the withdrawal

Then after N blocks, a second note can be consumed:

PROCESS_USER_FEE_WITHDRAWAL

I think this second note can probably be created by anyone. It does not need to be authorized by the user, because the user already authorized the withdrawal in step 1. This second note is really just finalizing an already-requested withdrawal.

The second note would specify:

struct ProcessUserFeeWithdrawal {
    user_account_id: AccountId,
    fee_asset_account_id: AccountId,
    processor: AccountId,
}

The global fee account checks:

key = hash(user_account_id, fee_asset_account_id)
status == WITHDRAWAL_REQUESTED
current_block >= withdraw_after_block

If valid, it creates a P2ID note back to the user with the remaining balance, clears the user’s fee balance, and optionally pays a tiny processor fee to whoever created/consumed the processing note.

So something like:

withdrawn_amount = balance - withdrawal_tx_fee - processor_fee

Then:

user gets withdrawn_amount
processor gets processor_fee
fee position is cleared

I’m not 100% sure we need the processor fee, but I think it might be nice. It means the user does not need to come back online after the lockup period. Anyone can finalize the withdrawal and earn a very small fee for doing so.

The main thing is that the processor fee should be fixed or chosen by the user in the original FEE_WITHDRAWAL note. The processor definitely should not get to choose the fee when processing the withdrawal.

There is also a small chicken-and-egg issue here. Since the global fee account is itself a network account, interacting with it via a network tx also requires fees. But I think this is solvable if top-ups and withdrawals pay their own fee from the assets being moved.

For top-up, the fee can come from the TOP_UP note itself.

For withdrawal, the fee can come out of the user’s existing balance in the global fee account.

So the global fee account basically says:

you can withdraw if your balance is large enough to pay for the withdrawal tx itself

If the remaining balance is too small, we either reject the withdrawal or define some dust behavior.

So overall, I think the clean version is:

request_withdrawal(user, fee_asset)
wait N blocks
process_withdrawal(user, fee_asset)

And the important invariant is:

Once a user requests withdrawal for a given fee asset, that fee position can no longer be used to pay for new network txs.

That prevents the user from first getting a network tx accepted using their fee balance and then immediately withdrawing the same balance before the debit settles.

So yeah, I think this is very solvable. The second note probably is needed, but it does not need to be user-authenticated. It can just be a permissionless “finalize this matured withdrawal” note, and maybe the creator gets a very small fee for doing it.

[PhilippGackstatter]

A few comments after the discussion yesterday.

Unbonding

Overall agree with @partylikeits1983's proposal that we'd need a mechanism that delays unbonding/withdrawals. Mainly to allow ntx builders to start working on transactions now and be able to rely on the fact that the user cannot withdraw their funds in the next block. So there needs to be at least a couple of blocks of unbonding.

User creates an ntx which does an FPI call into the global fee account.

Just to clarify: The approach I described doesn't rely on FPI calls. The ntx builder would inspect the fee account "directly", off-chain. They see that the user's funds are not in unbonding mode, and so it has a contractual guarantee that the user cannot withdraw the balance until at least X blocks into the future, making it very unlikely that the network tx cannot get included due to an insufficient balance. If the user's funds are being unbonded the ntx builder no longer includes the user's notes in network txs.

Remaining Budget / Max Fee

The discussion made me realize a problem. Recall that the user sets a remaining_budget on the fee authorization, but since the network account controls building fee debit notes and only needs to adhere to the "fee budget conservation", they have an incentive to drain that budget to zero. So in effect, the user can generally expect to pay the full remaining_budget that was set - except against benevolent network accounts.

In practice, it would mean that the user needs to have a good estimate of what executing a note will cost, to avoid setting the remaining budget too high. Avoiding upfront fee estimation was one of the main goals of the proposal, though.

So this makes the amount that the user effectively pays in the general case degrade to the same amount of all the other proposed approaches, that is, the user pays whatever was estimated upfront.

There may be ways to change the approach to create better guarantees. What a user actually wants to authorize is "debit the cost of executing this note to me", rather than "debit at most X to me" - which degrades to "debit exactly X to me", most of the time.

We could get there by standardizing how a note's fair share of the overall tx cost is computed. This fair share could be computed at the time the fee debit note is created - and the fee debit note finalizer validates that the amount was correctly computed. So, this could be something like weighting the total tx cost by each note's number of cycles. There could be multiple such standards and the network account could pick one of the available ones, but not compute the protocol fee completely freely. This seems like extra work at first, but I'd argue that computing this per note cost will have to be done anyway by someone - independent of the overall approach we choose. The difference is that in this approach it would have to be done in MASM - which gives the guarantees, and in the other approaches it could be done off-chain - which doesn't give any guarantees.

Application Fees

The last section concerns itself only with protocol fees, but @bobbinth brought up that application fees should also be handled by the fee approach. Similar to authorizing protocol fee debit, a user could authorize application fee debit. I'm a bit unclear on what complexity we need to support here, but a flat fee would be very easy to support, with other approaches also being standardizable.

Sponsorship

The fee auth attachment finalizer could additionally allow setting originator to an account ID X if a signature is provided that successfully validates against the public key associated with X in the global fee account. This would enable sponsorship, e.g. a guardian pays for a user's txs.

Multi-Asset Payment

We also want to support multi-asset fee payments. I think the simplest approach is for the global fee account to only hold native token balances.

• If a user has the native token, they directly create a TOP_UP note.
• If they don't, they create a TOP_UP_SWAP note with the asset they have and a swap service swaps it into the native token, creating a TOP_UP note as the output.

A wallet user would never notice the difference between those two, except for additional latency in the second case.

Scalability

My main concern is scalability. This has multiple aspects to it, but at least:

• A single global account would need to hold all user's balances, so this account would be very large.
• Inclusion of network transactions depends on inclusion of the fee-related transactions.

The first can probably be addressed by sharding the global account into multiple ones, where a user account is associated with exactly one account. The number of shards would have to be kept fairly small, at most 16 or 32 maybe. That's because the main downside of sharding is that N shards require N additional fee-transactions per batch, and so we'd want to keep N low.

To avoid conflicts with multiple ntx builders creating transaction against the same fee shard, we'd need dedicated builders for each fee shard (in case of decentralized ntx building). The second point remains the same - all fee-settlement transactions from all required shards need to succeed and be included in the batch for the overall batch to succeed. There are reasonable ways in which we can make sure that these transactions have a high chance of succeeding (high min balance per user) and fall back to a different builder if one shard builder doesn't provide the transactions in time, but it still feels like a risky architecture.

The second point above comes from the fact that we want to avoid committing fee-related notes to chain. If we are willing to commit these notes to chain, that constraint would go away, at the cost of network accounts having to output fee notes for immediate payment and at the risk of settlement failing later - which is probably a bad trade.

[Dominik1999]

First of all, thanks for the comprehensive discussion, it reads very well thought. And it sounds indeed like a very interesting problem to solve.

A couple of thoughts from the product and maybe project-perspective:

• fees will be irrelevant for the first two years. We will receive all fees and (most likely) subsidize the network quite heavily
• from the outside, it looks like you all already spent a lot of time thinking about the best fee model. I would want us to think about the opportunity costs, the smartest ppl in the company could think about "how we get the best in class cross-chain experience" :)
• users (retail or institutions) won't use Miden because of our fee model, there is only a downside risk: if its too complex they won't use it

So reading the different approaches, I really liked @PhilippGackstatter's proposal. However, in my understanding, we need to change quite a bit of things to make it work.

My 2 cents, and maybe I am oversimplifying:

Narrowing to two build-fast options

I think the design space collapses to two candidates, given our actual constraints:

(1) we launch centralized (so all protocol fees accrue to us), and
(2) we need something we can ship quickly without major node or mempool work

Both my options deliberately defer decentralization and treat it as a later migration, not a v1 requirement.

Option 1 - fee on the note itself (minimal-change single note)

This is the #2901 direction in its lightest form, closest to the EIP-1559-style sketch above.

• The feature note carries the fee asset in its vault plus a max_fee in the NetworkAccountTarget attachment. Business logic of the note is otherwise untouched.
• The network account exposes pay_fee, which prices the note as verification_base_fee * fee_factor, asserts <= max_fee, and takes the fee out of the note. fee_factor is a per-script-root value the operator can tune with an admin write (no redeploy). verification_base_fee is already a committed block-header value the kernel reads today, so going from flat to demand-based pricing later (per #1686) needs no account-code or note-format change.
• Settlement plugs into the batch-level fee mechanism from #2899. In the centralized phase pay_fee can simply leave the fee in the account we control and skip the FeeNote routing until it's needed.

Cost we accept: fee logic is mildly "infectious" at the asset level. Because the fee asset shares the note vault, any code doing get_assets (e.g. the basic wallet's add_assets_to_account) would sweep the fee asset too. The pragmatic mitigation is to make pay_fee return the remaining (non-fee) assets and document that fee-aware notes must use that output instead of get_assets directly. The cleaner fix (a note prologue plus a remove_asset_from_note kernel proc) is real protocol work and can wait.

Why it's fast: only new surface is a small accessor to expose the base fee to account code, plus the pay_fee proc. No mempool changes, no MustBeErased, no extra notes, no off-chain estimation service.

Option 2 - (might be radical) dedicated fee account with off-chain payment-channel intents

Instead of putting fees in notes, give every user a dedicated fee account holding a prepaid balance, and bill postpaid via user-signed vouchers. Fees never touch business notes at all - full separation of concerns. Instead of @PhilippGackstatter's global account, every user has its own fee account. This is, in my understanding, how institutions want to pay fees, this is how AWS, Cloudflare, etc do it. Predictable fees on a debit account.

• Top up occasionally (ideally enough for tens or hundreds of txs). The exact protocol fee is deterministic from the executed tx (compute_fee), so there is no estimation and no dry-run service.
• Each service provider (Operator, Guardian, Prover) collects via a signed cumulative intent. The user signs (fee_account_id, collector, cumulative_total, nonce, domain) off-chain - no VM, no proof, no on-chain tx. The provider renders service immediately on a valid intent.
• The intent is cumulative: the provider keeps only the latest, highest-value voucher and submits one collect tx whenever it wants to settle. The account stores collected[collector] and releases cumulative_total - collected[collector]. This means one settlement tx amortizes hundreds of fees, which keeps the account cold and sidesteps per-tx contention. The monotonic counter makes it replay-safe.
• Auth is already covered by primitives we have. AuthMultisigSmart + per-procedure policies gives immediate vs delayed (timelocked) execution and note restrictions, so withdrawals can be forced through a delayed path to protect pending collections. The only new on-chain code is a collect procedure that verifies the user signature and updates the per-collector counter.
• I (or my Claude) has built most of it in the x402 solution already

Costs we accept:

• Onboarding friction: users must fund a fee account before first use. Fine for institutions; abstractable by the wallet.
• Over-issuance / credit risk: a user can sign cumulative intents across the three collectors exceeding their balance (or withdraw early), so a valid signature is necessary but not sufficient. While centralized, the three collectors are one entity with a shared view of issued intents vs balance, so this is coordinated away. Long term it becomes the standard payment-channel collateral problem (per-collector locked sub-balances).
• Withdrawal race: handled by delayed withdrawal giving collectors a settlement window.

Why it's fast: no fee logic in any note, no estimation, no mempool work. New code is one collect proc plus an off-chain batched-settlement service we fully control.

How I'd compare them

• Option 1 keeps fees inside the existing note/batch-fee model and is the smaller conceptual step, at the cost of the get_assets infection living in our standard notes.
• Option 2 gives the cleanest separation of concerns, exact (not estimated) billing, and a predictable prepaid model that fits the institutional/treasury use case well - at the cost of a top-up step and collector-side credit risk that is moot while we're centralized.

Both are centralized-first and both avoid the unauthenticated-note mempool propagation that the node is moving away from. My lean is Option 2 for the DevEx and billing story, with Option 1 as the lower-risk fallback if we want to stay entirely within the note/batch-fee model.

[PhilippGackstatter]

• fees will be irrelevant for the first two years.

and

We should (ab)use the fact that we are still centralized and let that buy time to see how things pan out

This has a clear trade-off: IMO, the fee approach is such an integral part of the architecture that migrating away would be very painful, and you'd effectively end up supporting two fee approaches. So, I would very much favor not choosing a short-term solution.

Option 1

I see clear advantages for option 1. It is scalable, requires no protocol changes and is easy to implement at the standards level. There are also downsides:

Why it's fast: [...] no off-chain estimation service.

To be clear about that trade-off: No off-chain estimation service means we push the responsibility to every network account author.

The UX of building an account will not be pretty - author needs to build the account, estimate the cost per note with a dry-run, then mutate the account or rebuild it with the estimated values.

The feature note carries the fee asset in its vault plus a max_fee in the NetworkAccountTarget attachment. Business logic of the note is otherwise untouched.

Nit: Do we need max_fee here? A general, user-defined network account would simply charge the full fee asset as the fee, right? They have no incentive to give back to the user, afaict. Additionally, we don't have a way to refund fees. The cost of a refund note probably exceeds the refund.

The pragmatic mitigation is to make pay_fee return the remaining (non-fee) assets and

Agreed, this is a pragmatic solution. It also avoids the need for the note prologue/epilogue.
The trade-off here is that we'd split the note ecosystem into fee-aware and fee-unaware notes, but maybe this is actually fine. Maybe we're trying too hard to make things generic when we should just define new notes.

The nice alternative is to:

• make the tx kernel track input note assets statefully, such that we have an input_note::remove_asset API that mutates the input note's assets.
• add the note prologue (and maybe epilogue). The prologue for network accounts is written to take the fee asset out of the input note using input_note::remove_asset, leaving all non-fee assets. A subsequent input_note::get_assets only returns those notes.

This is nice, but I'm not fully convinced yet that we need the note prologue/epilogue more generally, and so I'm a bit hestitant to add this to the protocol as it feels premature.

Chained transactions

Chained transactions: The B2AGG note needs to create a BURN note and attach enough fee asset to it. So the B2AGG note must be fee-aware, and must carry enough fee asset to pay for 1) the current transaction and 2) to put on the BURN note. This can work with correctly estimated fees set by the network account author, since the author knows about the specifics of the B2AGG note here. They know that the B2AGG note spawns a BURN note, and so can set the fee appropriately. A generic dry-run service would not be able to correctly estimate that.

Imo, the burden this puts on network account authors is significant: I don't think we can come up with a standard to solve this generically. The B2AGG note is a good example where you need knowledge that it spawns a new note. That could be detected by some logic, but could that also detect if the spawned note (here BURN) would spawn yet another note - a chain of notes? What if a network note spawns a new note some of the time, but not always? How do you price that in? So, at the end of the day, it seems like this would have to be done mostly manually.

Split Note Ecosystem

One of the main questions I think is: Would a note ecosystem split into "network" and "local" notes be acceptable?

I think I would make pay_fee callable even when the target account does not have the fee manager component. So, we'd have two categories of notes:

• Notes strictly intended for local execution. These use active_note::get_assets like today to fetch assets.
• Notes intended for local and network execution. These always use pay_fee.
  • If the account has the fee manager component, pay fee asset and return the remaining assets.
  • If the account does not have the fee manager component, return the same as active_note::get_assets.

We also need to parameterize basic_wallet::add_assets_to_account to take assets as a parameter rather than fetch them itself.

Parameterizing over assets will require changes to B2AGG note, which is a pure network note anyway, P2ID(E) note and receive_and_burn. I'm assuming the SWAP and PSWAP note are local-only. The rest of the notes are unaffected I believe.

So, this looks doable.

The cost we accept is that note authors need to deal with fee logic, but half of the time it should just be a call to pay_fee.

Option 2

I like this a lot. This is what I was trying to explore with the lightning-network-style notes in one of the posts. Your idea is what I had hoped to come up with - pretty cool! The primary problem is that I don't see how to fix the credit risk problem when we decentralize. As mentioned above, I wouldn't want to go with a solution that doesn't work long-term.

[Mirko-von-Leipzig]

This has a clear trade-off: IMO, the fee approach is such an integral part of the architecture that migrating away would be very painful, and you'd effectively end up supporting two fee approaches. So, I would very much favor not choosing a short-term solution.

I agree; but whats currently happening is much worse imo. There is a rush; and no clear acceptably good-enough answer imo. I would rather have a good external temp solution, than a rushed internal/protocol level one which is essentially temporary (and untested).

I'm fairly confident that we won't come up with a good solution straight out the gate. This is unique, and untested so I imagine whatever we decide will be wrong and require changing in any case. imo we should be expecting a suboptimal solution no matter what we do; and design around the fact that we will have to change it.

[Dominik1999]

Thanks for the thoughtful comments!

The primary problem is that I don't see how to fix the credit risk problem when we decentralize. As mentioned above, I wouldn't want to go with a solution that doesn't work long-term.

I think we can solve that with dedicated payment channel per creditor (e.g., Node 1, Node 2, Prover 1, ...), so basically, there is one account, but Node 1 can only get assets for Node 1. This could be in the same account or you have one account per creditor.

My goal is just to have something fast that works. And we can leverage the fact that we are centralized. And this solution would be easy to use for users and institutions. They top up their credit and that's it. We could even have different models, like a MAX account, like I can have it with Anthropic. This would give us also more credibility in the beginning for investors (but that might be a different topic, not protocol fee related).

[PhilippGackstatter]

I think we can solve that with dedicated payment channel per creditor (e.g., Node 1, Node 2, Prover 1, ...), so basically, there is one account, but Node 1 can only get assets for Node 1.

I guess that should work, but I need to think a bit more about it.

Two other questions that we would need to answer:

• How does the intent get to the ntx builder?
  • For now, I agree we can assume the centralized ntx builder and so this could be a simple node API.
• How does this work for chained transactions? E.g. I submit a B2AGG note and it creates a BURN note. For one, how does the client learn about the BURN note's existence and that it requires an intent to execute. Secondly, there is no incentive to let the BURN note execute, so the user doesn't necessarily care about providing one.
  • Here too, maybe we could make the centralization assumption. Assume the B2AGG note intent contains enough to cover both itself and the BURN note. This should work if the bridge included this in its note fee estimation, like I mentioned above for Option 1.

This option is rather non-invasive, so if we need another solution later, adding a new on-chain fee standard means there is only one on-chain standard we need to maintain, rather than two. Not great, not terrible.

[Dominik1999]

How does the intent get to the ntx builder?
For now, I agree we can assume the centralized ntx builder and so this could be a simple node API.

I would agree to that, for now, its just an API. Fast and easy to build.

How does this work for chained transactions? E.g. I submit a B2AGG note and it creates a BURN note. For one, how does the client learn about the BURN note's existence and that it requires an intent to execute. Secondly, there is no incentive to let the BURN note execute, so the user doesn't necessarily care about providing one.
Here too, maybe we could make the centralization assumption. Assume the B2AGG note intent contains enough to cover both itself and the BURN note. This should work if the bridge included this in its note fee estimation, like I mentioned above for Option 1.

I need to think about it as well. Let me try to come up with a diagram on Monday. But in general, in my current understanding, the user should not need to know about the bridge intrinsics and the BURN note.

• The bridge should get a fee (set by the bridge: the application fee) and
• the node should know the protocol fees involved for the whole chain.
  -> The user will ask the Node about the total fees, creates an intent to the Node, the Node give the part to the bridge. And the node executes / integrates all related transactions to this bridging flow. In theory, the Node can bundle and keep the rest.

(Maybe again I am simplifying too much)