Introduce mechanism for service fees

[PhilippGackstatter]

We want the delegated prover and guardian and similar services to be paid for their work and this discussion explores ideas for doing that.

Approach 1

One idea that was discussed is to let these services sign a receipt when they are called. That receipt is attached to the transaction and submitted to the node by the client. The node then allows the service to claim a part of the fee that the user paid as part of the transaction.

• Pro: Fee amount can depend on transaction fee or number of tx cycles - this may or may not be relevant for the prover (see also below).
• Con: The receipt is just attached to the proof, but is not essential for verification. So, the user can strip the receipt from the proof without consequences and prevent the service from getting paid. This is my understanding at least. If we can make the proof validation dependent on the receipt, this is fine.
• Con: The user pays a fee X for the transaction that is supposed to cover the cost of the transaction for the protocol. If services claim a part of this amount, the user has effectively paid less than it should have paid. The network subsidizes the prover and guardian cost.

These may both be acceptable for now, as we're okay with subsidizing. But it's not an ideal mid/long-term solution, and we'd be creating some technical debt for the future to switch to something else. Ideally, we have a solution that works in the long run.

Approach 2

Another approach is to make the services check that the transaction they are about to prove or sign creates a private P2ID note with a flat fee as payment for the service. If not, the service rejects the request. The "service fee notes" are added automatically by the client in a tx script to a note that uses delegated proving or the guardian.

• Pro: The user cannot strip the service fee from the transaction.
• Pro: The user still pays fee X for the transaction, but additionally pays the service it chooses to use, which is how it should work. I.e. the user pays X to the network independent of the services it uses.
• Pro: The user should only see that they pay Y amount in fees, while the client should be able to fully abstract away the details of which parts of Y go into the tx fee and the service fee. The services can technically even request to be paid in different assets than the tx fee asset.
• Con: The service fee cannot depend on the transaction fee (which itself depends on the number of tx cycles). That's because at the time the note is created, the total number of cycles of the transaction is not known yet. So, the simplest solution is to let each service choose a flat fee for its service. This is not ideal, since the prover ideally should charge its fee based on the transaction, but if the absolute fee is low enough, a flat fee would work fine.
• Con: Creates a new note for each service the user uses. Since these are private, the additional cost of these should be low and the burden on the network is low too.

Thanks to @partylikeits1983 and @Keinberger for the session to think through the second approach!

Note: This issue was discussed in the context of protocol fees, but seems most applicable to the client, since it would need to integrate most of this, afaict. If this is incorrect, we can move it to the protocol repo.

cc @Dominik1999

[Mirko-von-Leipzig]

Con: The service fee cannot depend on the transaction fee (which itself depends on the number of tx cycles). That's because at the time the note is created, the total number of cycles of the transaction is not known yet. So, the simplest solution is to let each service choose a flat fee for its service. This is not ideal, since the prover ideally should charge its fee based on the transaction, but if the absolute fee is low enough, a flat fee would work fine.

Is this not solveable by proving service specifying a price per unit, and then executing the transaction twice? Once without the note to estimate cycles, and second to add the note back in.

We could then optimise this with a partial execution - or blank space for the note asset transfer amount since that's the only missing info..

[PhilippGackstatter]

Is this not solveable by proving service specifying a price per unit, and then executing the transaction twice? Once without the note to estimate cycles, and second to add the note back in.

As mentioned in an offline discussion, to get the accurate number of cycles of a transaction, we typically need to successfully execute the auth procedure. This typically requires a valid signature from a user, but this means we'd need to ask the user for signatures twice: once for the dry-run and once for the actual execution, which results in bad UX.

---

I think another idea we discussed was a top-up or prepaid mechanism, where users top up their balance with a remote prover and the prover deducts the actually consumed fee after proving. One small downside is that it require a bit of upfront work, e.g. sending a payment (a la x402) to the prover, which itself requires a transaction that needs to be proven (but the delegated prover would surely happily subsidize that one).

[Mirko-von-Leipzig]

In starknet this was done with a dry run mode, where things like signature verification ran but with dummy values and without triggering failures. So no need for double sig request, and in this case I think even a full run should be achievable?

[PhilippGackstatter]

I guess to support such a dummy run, one would have to explicitly build an escape hatch into signature verification, and this seems dangerous, but doable in principle. You'd also have to make sure the dry run results in the same number of cycles as the real run, which I don't know how easy it is for signature verification.

[Dominik1999]

Thank you for the well-written issue.

I would go with your Approach 2. We can add a piece on fee discovery that I think is missing from the original framing.

Potential High-level design

Three components, no protocol changes required:

1. Service-fee notes. Standardize a P2ID note format that the client injects automatically when the user opts to use a paid service (Guardian cosigning, delegated proving, future services). The note pays the service's account in the service's accepted asset.

2. Service-side enforcement. The Guardian and the delegated prover both inspect the executed transaction before doing their work. They check that an output P2ID note exists, paying their account, in an accepted asset, at or above their published minimum. If the check fails, they reject the request. The user cannot strip the note because doing so means no co-signature or no proof.

3. Fee discovery via the service's own account. The service's account is public and exposes a standardized "service info" storage component: a storage map keyed by (asset_id) → minimum_fee, plus fixed slots for status (active/paused), endpoint URI, capability flags, schema version, and last-updated block. The client reads this directly from the service's account state. No registry, no off-chain API, no signatures to verify, because only the service can write to its own storage.

For discoverability of the set of services, a separate lightweight on-chain directory account (we can maintain this) lists active service account IDs. Pricing and capabilities never live in the directory, only in each service's own account.

Some Pros:

• No protocol changes. Notes, public accounts, and storage maps are all existing primitives.
• No trust assumptions. Service refuses to act without payment, the user can verify the price before paying, the protocol verifies nothing because nothing protocol-level is needed.
• No attribution machinery. The note address equals the recipient. Done.
• Anti-stripping is structural. No note, no service work, no valid tx.
• Identical for public and private accounts. P2ID notes are private either way.
• Composable. N services equals N notes, each independently checked.
• Asset-flexible. Each service publishes its own accepted asset list.
• In theory operators can compete in the future. In the beginning we can set fees to a low flat fee and subsidize it.

Addressing the cons
Con 1: Flat fee, no cycle dependency. This is real but the magnitude is small enough to accept for v1. In theory, the prover can still reject a tx if it is too much work and no fee would be paid in the end - > the P2ID fee note would never be created.
Con 2: One extra note per service. True but the cost is low and bounded. Private notes are cheap to produce and the marginal block-space cost is small.

Another new con is that we overload the client a bit. It now has to handle network fees and service fees which are being paid in different ways, maybe different assets.

[PhilippGackstatter]

Thanks for the comment. Pretty much agree with what you said.

3. No registry, no off-chain API,

I think whenever it is possible to use an off-chain API, it is preferable over putting data on-chain. The service info is purely processed off-chain, so I don't see a reason why it has to be on-chain. Usually we use on-chain storage when no side channel is available between the two entities, but here the client already has a direct connection to its services (guardian, prover), so an off-chain API should be much cheaper and faster to use than the on-chain one. Plus it reduces the burden on the network (less data stored on-chain).

For discoverability of the set of services, a separate lightweight on-chain directory account

Do we need the registry for v1? Or in other words, we can add this easily after mainnet if the need comes up. Whether it should be on-chain or off-chain should probably be discussed in more depth.

[bobbinth]

I haven't thought this through completely - so, for now just a few preliminary comments.

Overall, I like approach 2 better as well, but it does have a few more problems:

First, a fee to produce and consume a note will at the very least be comparable to most service fees, and in some cases, could be orders of magnitude higher. For example, the cost to the network of one extra private note is definitely quite a bit more than the cost of running one transaction proof (proving 1 transaction is a fraction of a cent - probably around 0.01 cent now, and in the future much lower). Now, the absolute values in both cases are low enough were may be we don't care - e.g., the service provider could charge 0.1 cent - and the user would still not notice the difference. Though, this highly depends on a specific use case.

Second, there is still a pretty significant griefing attack vector. Let's say the user runs asks for a transaction proof and includes the fee paying note into the transaction. The remote prover does the work, but then the user never submits the transaction to the network. Basically, in this scenario the service needs to do the work without knowing whether they'll get paid.

For some services, the situation may be the opposite: the user would pay before they'd know if the service would do their part. Note transport layer is one such service: the user needs to commit a transaction to the chain, and this transaction would include the fee note for the NTL. But then, NTL could refuse to take the user's note - or could take it but then never deliver it.

There are different ways to address the above issues, and they can also be addressed differently in different contexts. The simplest context is the one where the user is connected to a guardian, and where the guardian submits transactions to the network. Here is how it could work:

1. The user queries the guardian for a fee estimate. This estimate could be based on some set of parameters (e.g., I'm about to create a transaction which will create 3 P2ID notes, and I'll use ECDSA signature for authentication, and I'll need delegated proving). The guardian replies with the fee estimate. Initial implementation of this endpoint could be super simple - just return a constant value.
2. The user executes the transaction and includes the fee to the guardian in a separate note.
3. The guardian then proves the transaction and sends it to the network.
4. If the guardian builds a batch of transaction, the guardian can also consume all the fee notes in that batch - so, all fee notes become "erased" and never hit the network.

This addresses all the problems listed above:

• The guardian can present the single fee to the user for all relevant services. The user does not need to query individual services to figure out who gets paid what.
• The guardian is almost guaranteed to get paid for its services because it submits the transactions to the network. If the guardian doesn't submit the transaction, it doesn't get paid - so, incentives are fully aligned.
• There is at most 1 fee note per transaction, and even this note could be erased if the guardian batches a bunch of transactions together. This makes the fee notes nearly free.

Obviously, if there is no guardian, things get quite a bit more complex - and I don't yet have a clear picture of what's the best way to solve them.

[Dominik1999]

Thank you for thoughtful comment and pointing out the issues.

It should not be case, that we pay more to pay the fee, than the fee itself. So we need to find another approach.

Guardians proving, submitting and managing services

I am a bit skeptical of the idea though that the Guardian does everything for the user. In the current approach, the Guardian would

• co-sign transactions
• know the user state
• prove user transactions
• submit user transactions
• manage all fees

In that world, I wonder if users running clients would be merely cosmetic. If users trust their Guardians or self custody is not important to them, a simple (mobile) frontend would suffice.

Another point, and we need a different discussion for that, is, to run a Guardian that only co-signs and syncs/recovers the state costs an operator ~400$ / year (t3-medium). A Guardian that is at the same time a delegated prover is way more expensive (100,000$ / year) and complex to run. However, we might need it in the first year or so.

[Dominik1999]

Thinking about it more. One core problem that I see, is:

• having different mechanisms for our various fees is not user-focussed. We can argue that the client abstracts that away, but developers still need to think about it, new wallets that want to integrate must learn this, and it just widens the area on why and how a transaction can fail.
• unifying the fees run into serious tradeoffs:
  • One protocol fee: we could just increase the protocol fee if services are used. Then we distribute the service fee portion to the service providers. But the chain cannot prove that a prover or co-signer was used. So the user can always cheat.
  • One Guardian fee: we risk to have a network of Guardians with users attached. Users that don't want to use a Guardian can not pay or use the services and basically not use the network. And here we increase the costs of running a Guardian significantly.

A hands on approach could be: We add a field to the transaction metadata [prover(1 | 0), co-signature(1 | 0), NTL(1 | 0)]. The client sets this field according to the services used and pays more protocol fees respectively. If the services find out later that a TransactionID that they have in their records differs from what is onchain, they block the user in the future. This approach also has its problems, but might be simple to implement for now.

[Dominik1999]

Service fees: two candidate designs and a requirements-based comparison

Following up on the discussion above and a call I had with @bobbinth on Friday. Following the network fee discussion, I want to define what a service-fee mechanism actually has to achieve, and then compare the two designs that we believed were best: (a) service payment channels and (b) the Guardian as fee collector.

The fee stack problem

Miden is accumulating fee layers: protocol fees (almost live), batch-builder fees (0xMiden/protocol#2899), network-account fees (0xMiden/protocol#2901, 0xMiden/protocol#2968), service fees (this thread), and eventually application fees (a DEX will charge its own fee). Each layer with its own mechanism is quite unique and adds lots of complexity on usability. Not only for users (the client can abstract a lot away, but then the already quite heavy client, holding state and proves, gets even more complex ) but for every wallet and integration that has to learn all of them, and for debugging, since each mechanism widens the surface of "why did my transaction fail".

For service fees specifically, we can be quite honest. We will subsidize all services in the beginning anyway, so revenue is not the goal. The goals are:

1. Spam protection from day one.
2. One mechanism that survives into real pricing later: no technical debt, little migration.
3. No structural drift toward a single collection point we didn't consciously choose.

Requirements

#	Requirement
R1	Spam protection from day one
R2	Paying the fee must not cost more than the fee itself
R3	Griefing-resistant in both directions (user strips the fee / never submits the tx vs. service takes payment but never delivers)
R4	Works with and without a Guardian: no service is structurally forced to bill through one, no user is forced to use a Guardian
R5	No protocol changes: we want to reach mainnet soon
R6	One mechanism covering NTL, prover, Guardian, and future services
R7	Pricing can evolve (flat → metered) without a mechanism migration

Why the earlier options don't meet the bar

• Signed receipts claiming part of the protocol fee (Approach 1 above): the receipt is strippable (R3), it needs node-side fee routing (R5), and the NTL has no transaction to attach a receipt to (R6).
• Per-request P2ID fee notes (Approach 2 above): as @bobbinth pointed out, the cost of producing and consuming a note can exceed the service fee itself (R2), and the griefing vectors remain: the prover works without knowing the tx will be submitted, and an NTL user pays without knowing the note will be delivered (R3).
• Tx-metadata flags + blocklisting (my earlier suggestion): retiring it. The chain cannot verify whether a service was actually used, so the flags are unverifiable (R3), and it needs a new metadata field plus fee routing (R5). Ex-post blocklisting is weak enforcement.

That leaves two designs.

Proposal (a): Service payment channels

A standardized "payment channel" between a user and the services, built from existing primitives. Can be added to the standards and can serve as example payment channel for other applications.

Mechanism.

1. The user makes a one-time deposit into a channel (an account component or a note) with two spend paths:
   • Service withdrawal: service S can withdraw by presenting a user-signed receipt (service_id, cumulative_amount, nonce).
   • User reclaim: the user can reclaim the remaining balance after a timeout.
   • 1-n: In theory, many services can use the same "payment channel" if we allow slight over drafting ...
2. Per request, the client attaches a signed receipt that increments the cumulative tab. This is an off-chain message, no note, no transaction.
3. The service verifies the signature and the on-chain deposit before doing any work, then serves the request.
4. The service redeems in batches: one on-chain transaction claims the latest cumulative receipt per user, amortizing the on-chain cost over hundreds of requests.

The deposit is the API key. Channel ID = identity = spam bond. Rate limits are keyed to it. There is no separate key infrastructure to build and later throw away. Going from "subsidized spam protection" to "real fees" is a price change, not a mechanism change.

Pros

• Any client can pay any service directly. There is no structural drift toward Guardian capture (R4).
• Griefing is solved in the expensive direction: the service holds a redeemable receipt before it does work (R3). Service-side exposure is bounded to a single request's fee.
• Per-request cost is off-chain and effectively zero; on-chain cost is amortized via batched redemption (R2).
• Covers services that have no transaction to attach to — NTL delivery, storage-over-time (R6).
• Receipts carry arbitrary amounts, so flat fees can become metered fees without changing the rails (R7).

Cons

• Onboarding friction: a new user needs an on-chain deposit before their first request. This might be a chicken-and-egg problem for accounts that need the prover to transact at all. Needs faucet-funded or service-sponsored first deposits in Phase 1.
• Locked capital plus a reclaim-timeout UX.
• Over-commitment: one deposit claimable by several services can be overdrawn (the sum of signed tabs can exceed the deposit). My preference: per-service allowances inside the receipt scheme; alternatives are one channel per service, or services capping their unredeemed exposure.
• The most engineering of all options: a channel account component, a receipt standard, redemption flows, and client integration. But I have built this already with Claude for x402 and some other examples.
• Service-side non-delivery remains reputation-bounded (though exposure is one request's fee).
• The client must aggregate per-service quotes into the single fee number shown to the user.

Proposal (b): Guardian as fee collector

@bobbinth sketched this above; stating it here as a full proposal.

Mechanism.

1. The user queries the Guardian for a fee estimate covering all services involved (co-signing, proving, NTL, submission).
2. The user executes the transaction and includes a single fee note to the Guardian.
3. The Guardian co-signs, proves, and submits the transaction. If it doesn't submit, it isn't paid — incentives are aligned by construction.
4. When the Guardian batches transactions, it consumes the fee notes inside the batch, so they are erased and never hit the chain.
5. The Guardian settles with downstream services (prover, NTL) bilaterally, off-chain or on its own schedule.

Pros

• Best possible UX: one quote, one fee, one payer. The user never sees the service decomposition (and neither does the wallet developer).
• Cheapest on-chain footprint: at most one fee note per transaction, erased entirely when batched (R2, strongest of all options).
• Perfect incentive alignment on the happy path: paid iff the transaction is submitted. There is nothing to strip (R3, for the Guardian path).
• Least new machinery: the complexity moves into Guardian↔service business relationships rather than into the protocol or the client.

Cons

• Guardian-less users have no defined payment path. A fallback mechanism is needed anyway. In practice this is two mechanisms, which undermines R6.
• It concentrates yet another function in the Guardian: co-signing, state knowledge, proving, submission, and now fee collection. At that point, self-custodial clients risk becoming cosmetic.
• It raises the cost and complexity of operating a Guardian (a co-sign-only Guardian is ~$400/year; one that also proves is orders of magnitude more), which increases centralization pressure.
• Downstream services must trust Guardians to pass fees through. Bilateral contracts, and a gatekeeping risk for new or independent services (low risk in our current setup)
• The NTL fits awkwardly: it also serves recipients, who may have no relationship with the sender's Guardian.

Comparison

Mechanism	R1 spam	R2 overhead	R3 griefing	R4 no-Guardian	R5 no protocol Δ	R6 uniform	R7 evolvable
Signed receipts (App. 1)	⚠️ pay-after-work	✅ no extra notes	❌ strippable	✅	❌ node fee routing	⚠️ NTL has no tx	✅
Per-request fee notes (App. 2)	✅	❌ note cost > fee	⚠️ stripping solved, griefing remains	✅	✅	✅	⚠️ flat only
Tx-metadata flags	⚠️ ex-post	✅	❌ unverifiable	✅	❌	✅	⚠️
(a) Payment channels	✅ deposit = bond	✅ amortized	✅ receipt before work	✅	✅	✅ incl. NTL	✅
(b) Guardian collector	✅	✅ erasable note	✅ Guardian path only	❌ fallback needed	✅	⚠️ Guardian users only	✅

They compose — but we have to pick the primary rail

The two proposals are not mutually exclusive. Under (a), a Guardian can hold channels to downstream services and present one aggregated quote to its users, recovering most of (b)'s UX on top of (a)'s rails. Under (b), channels are the natural fallback for no-guardian users. The decision is which one we standardize and build first, because that choice determines where the ecosystem's fee plumbing consolidates.

Rollout in two phases (either proposal)

• Phase 1 (launch, subsidized): symbolic flat fee per request — or even zero-amount receipts, which still function as spam accounting and rate-limit identity. Deposits (or fee notes) faucet-funded. Purpose: spam protection and exercising the payment path with real traffic.
• Phase 2 (real pricing): each service publishes its price function (prover per-cycle, NTL per note-byte-epoch, Guardian per co-signature) via an off-chain quote endpoint. Triggers for the switch: subsidy budget pressure, observed spam, third-party operators joining.

My lean

I have a soft lean toward (a) payment channels, for one architectural and one empirical reason.

Architecturally: (b) makes the fee system assume Guardians. Every service that wants to get paid ends up billing through them, guardian-less users become second-class, and we quietly convert an optional convenience layer into mandatory infrastructure.

Empirically: (b) only works if there is a healthy, decentralized supply of Guardian operators. Finding teams willing to run Guardians has already proven harder than (at least I) expected. Every additional responsibility we attach to the Guardian (proving, fee collection and settlement with downstream services) raises the bar for operators further and shrinks that supply. Relying on the Guardian as the network's fee backbone means buying that operator-supply risk into the fee system itself. Channels keep the fee system's liveness independent of it.

Open questions

1. Deposit sizing and the over-commitment scheme for (a): per-service allowances vs. one channel per service?
2. Receipt format standardization, is (service_id, cumulative_amount, nonce) + account signature enough? Should it be a standardized attachment?
3. Should the NTL charge at all in Phase 1, given it's also the piece whose adoption we most need?
4. First-deposit sponsorship UX for brand-new accounts in (a).
5. For (b): what does the fallback for no-guardian-less users concretely look like, is it (a) anyway? Can we do the NTL without fees?
6. For the Guardian to collect fees, proves, and batches, we need to add quite some work to the Guardian. It is on the roadmap, but the current speed of development is not sufficient. This is solvable.

[Dominik1999]

Hey @bobbinth @PhilippGackstatter @mmagician

Any updates here? Any info or analysis that would help you to come to a conclusion?

[mmagician]

No we haven't discussed this in detail, but given that we're starting in a centralized mode and we sponsor the services in the first couple of months at least, I would rather prioritize items that are relevant for mainnet.