[SNIP] STRK fee token

đź“ś Development Proposals
1

Simple Summary

This SNIP outlines the semantics of transaction V3, and the protocol and API changes required to facilitate STRK as a fee token. Older transaction versions will continue to be supported, thus maintaining ETH as a fee token. It also specifies the first STRK <> ETH price feed to be used, a trusted off-chain oracle provided by Pragma.

Motivation

One of the primary purposes of STRK, the native token of Starknet, is to serve as the fee payment token on Starknet.

Specification and full details

https://github.com/ob1337/SNIPs/blob/snip-10/SNIPS/snip-10.md

2

I’d like to record and address some concerns about this SNIP raised on TG. Although we have carefully considered them before working on v0.13, they are not explicitly addressed in writing. Starting this discussion here would benefit the community and allow everyone interested to chime in.

Before diving in, I want to make the high-level clear:

  • The STRK token’s intended utility is for using, managing, and securing Starknet (see this post for more details). We want to allow STRK fee payment as another step toward these goals.
  • The Starknet operator has inescapable ETH expenses for L1 data and L1 state updates. The operator will allow STRK fee payment and will take on the risk of undercharging users.
  • ETH→STRK oracles are a tool for the operator to mitigate risk by minimizing losses.

RS | YAS Starknet:

I’m checking out the upgrades for 0.13. Wouldn’t the use of strk and eth for gas introduce some MEV opportunities?

(The concerns is that price of STRK may change before sequencer can sell it for ETH to cover L1 costs.)

The sequencer does indeed take on this risk. However, since the ETH expenses are inescapable, we consider the risk as an acceptable price for allowing the utility of STRK tokens.

RS | YAS Starknet:

These are some of the questions I have:

  1. Where can we read more about how will the oracle work? From the SNIP it says that it will be only off-chain. Are there any benchmarks on how is Pragma performing for this task (not the on-chain work they have done so far)?

The oracle will indeed be off-chain. As far as benchmarks and specifics, the lovely Matteo Georges from Pragma mentioned he’s working on some expository material, so I’ll leave that to him (and refer to his post when I have a link).

  1. How often wil the price be updated? Is it per block?

The exchange rate will be sampled every few seconds. Each block will use the latest rate throughout. In particular, the rate will be uniform throughout each block.

  1. Isn’t this adding unnecessary complexity? It’s weird that the sequencer resources can be paid directly with a token that needs an oracle to measure against the native resources. This means there will always be an arbitrage opportunity between the asset priced in Starknet and the gas cost.

Depends what you consider as “necessary”, right? We know we want to facilitate STRK fee payments, and we know the operator expenses are in ETH. We could invent our own method of converting ETH→STRK, but I would say that is unnecessary complexity and it’s best to use experts. As far as arbitrage, I agree: there is indeed an inherent opening for it. However, it also affords us a continuity in UX: concurrent support for old tx versions alongside v3 doesn’t require users to own STRK.

  1. How will this play out with the txs that are confirmed instantly in L2 before going into a block?

I am not sure I understand the question. Currently, one can query about the pending block (the one under construction). For now, once a transaction is included in the pending block, it will remain there. Is this what you mean by “instant confirmation”? If so, there is no threat for UX here: the confirmed transaction will move forward in the flow until L1 finality, possibly at the expense of the sequencer. The risk taken by the sequencer explicitly protects the UX in this flow.

  1. Will the oracle be run completely by Pragma?

Pragma will provide its oracle service. Switchboard is another oracle provider that we will employ for the same purpose. It will provide a fallback.

  1. What happens if the off-chain service goes down? Does the whole chain stop or is it only going to affect the v3 txs?

Even in case of both oracles failing, there are fallbacks which will maintain liveness for v3 transactions as well. In particular, oracle faults will not cause the chain to stop.

Oak:

I agree with RJ take on allowing more than one token for tx fee payment. It’s only adding unnecessary complexity on lower levels of the protocol without any clear benefit, and with a high potential for exploiting

Firstly, I disagree with the assertion “without any clear benefit”. The reasons for STRK support are mentioned above and appear in detail e.g here. Concurrent support for ETH and STRK seems to me like a very reasonable way to onboard STRK without ruining UX. What would you propose as a less complex way? As far as exploiting - I don’t follow: the sequencer is taking on the risk, so what sort of exploitation do you have in mind?

lambda_0x:

iiuc once old transaction type is deprecated native way to pay for gas would be STRK if you want to pay with any other token like ETH or USDC that would be done with paymaster?

also would STRK be just another SRC20 token or will there be special rules for it on protocol layer?

Good questions. If I understand the first one correctly, then yes - we definitely want to add support for a paymaster. I think it would do great things for the network. For the second question, even with paymaster, STRK will be still distinguished at least in the decentralized setting because block rewards will be issued in STRK. Thus the security of the network will be intimately coupled to the market for STRK.

RS | YAS Starknet:

I understand the need for the oracle with the two tokens to make that work for the time being. But adding the strk token as a fee mechanism now doesn’t seem to add too much and the risk to making it work seems quite high.
But in general I want to understand more how it will work to re-evaluate my opinion.

I think I addressed these concerns above, but please correct me otherwise!

3

agree that this should be considered as risk for sequencer, but that should be acceptable by sequencer
after all, running a sequencer for Starknet should be a sign of believe in Starknet, and consequently in STARK token

4

Thanks a lot, Ilia and Ohad for taking on the discussion on the forum.

I’ll add my thoughts to the answer of Ilia, and some documents to provide more context in the discussion.

I wrote an article that, I feel, answers a bunch of the questions asked here (about the need for the conversion mechanism, and the model), it’s not publicly posted yet, but here is the draft: Quoting conversion rate for Starknet sequencer — mattegoat.eth

Now, for the question that is unanswered by the document:

RJ | YAS Starknet:

These are some of the questions I have:

  1. Where can we read more about how will the oracle work? From the SNIP it says that it will be only off-chain. Are there any benchmarks on how is Pragma performing for this task (not the on-chain work they have done so far)?

For more details about the model and its functionality, please refer to the document I’ve linked. Here is the documentation for the off-chain service we have: PragmApi Documentation.

Regarding the data, it draws upon the same network of data providers and publishers. If you require benchmarks for the data, it’s available on-chain. We conducted some benchmarks on specific occasions, as showcased here: Oracle Benchmark on GitHub. We can assist in setting up more specific publicly accessible benchmarks if you can provide further details. Specifically, whether it involves the initial data points or focuses more on the final aggregation.

If you seek benchmarks related to the API’s status, uptime, and similar metrics, we just made this public: https://status.pragma.build/

5

It seems good to me that the STRK token is used as a fee token, it just seems strange to me to have a payment duality (ETH & STRK), it is extremely important that the oracle has the most up-to-date data possible, since it can cause losses for the users. network participants, as you may see occasions where there is a price mismatch between ETH and STRK.

Personally, there should be a mechanism that benefits the use of STRK more, there may be duality, but what prevents me from only using ETH and thus not giving value (as a token fee) to STRK?

6

It’s a valid point, and my understanding, as described in the post I linked in my previous reply, is that the decentralized setup will strongly encourage the network to support only STRK as a payment fee, at least at the protocol level. I think the path proposed here is the best transition in terms of UX, with both ETH and STRK gas fees payment for now, and when the paymaster and wallets are ready to make the gas fee abstraction at the application level, Starknet will transition to only STRK gas fees only without impacting UX.

As for the Oracle price, the price will be the most up-to-date, but there’s no (hard) guarantee that the gas fees in STRK will be inferior to the fees in ETH, as the model accounts for volatility to price it in order to reduce directional risks. Since I expect the dual gas token to last only for a short/medium period of time, I think offering the possibility to pay in STRK is already providing value, but it is a good discussion to have.

7

When the starknet network is upgraded to support STRK as a payment fee, it is said that the gas fee will be reduced by 90%, which sounds great, and if that’s the case I think there will be a new chapter for the starknet network. When there is a big reduction in gas fees, users will stay and not move to another network, the current transaction gas fees are really a little high，I hope it comes sooner rather than later.

8

From my understanding, if STRK used as a fee token, would the supply of STRK reduce by gas burning? I could not say anything without the official tokenomic.

9

If you can link me where you read/heard that it would be helpful - while I agree that a big reduction in gas fees is necessary, I don’t think that the upgrade we’re discussing is going to reduce the gas fees

10

I don’t have more information about this, and I don’t think that the upgrade we’re discussing will enable it. There are a bunch of posts linked to this subject, especially “Starknet decentralized protocol” (there’s 7 parts) or the fee market discussed in a few posts, feel free to create a dedicated post if you feel that more eyes should be brought on this.