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.