[SNIP] STRK fee token

[Ohad-StarkWare]

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

[ilia]

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).

2. 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.

3. 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.

4. 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.

5. 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.

6. 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!

[casperBGD]

@ilia

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.

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

[matteo]

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/

[A-E-R-R-B-R]

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?

[matteo]

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.

[xf0707]

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.

[emlaga001]

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.

[matteo]

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

[matteo]

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.

[sendmoodz]

I would like to suggest including an on-chain backup oracle for liveness based on Ekubo extensions. It would be beneficial to the long term goal of decentralizing the sequencer role to have available a reliable on-chain data source for querying the price of STRK. If this is of interest, we will develop and deploy the necessary extension. Of course, it depends on STRK becoming transferrable to work, since the price would be based on trading activity.

We have an example Oracle contract written in the docs for creating a pool that is useful for calculating the time-weighted average price. The time weighting is not ideal given the variable time between Starknet blocks, as implemented today. In addition, a specific pool would need to be created to measure the TWAP, and ideally Starknet would lock up liquidity in the pool to make it manipulation resistant.

However, we can also write an oracle contract that allows computing a volume weighted average price in the same way our API computes VWAPs to show in app.ekubo.org. This volume weighted average price oracle extension can even be used to across pools to increase its manipulation resistance.

Once the data source is created in Ekubo, it is up to the sequencer to determine the period over which it measures the average price. Then, it can snapshot the accumulator of the oracle every so often (e.g. every 15 minutes) and compare snapshots to compute the average price over the period.

[DevenMat]

Generally excited about the changes introduces in v0.13, but feel as if the conversation around the ETH<>STRK price oracle (which is not part of this upgrade) is solving for a problem which has not yet been created.

Using an oracle assumes the primary source of liquidity for ETH<>STRK is Binance, Kraken, etc. which I presume only becomes the case if ‘sophisticated actors’ are given a large amount of tokens to market-make on centralized exchanges upon launch. There is no need to reference offchain data if a majority of STRK liquidity remaining onchain. I would argue this is a distinctly better future for Starknet: STRK trading directly increases Starknet volume/activity, price action is completely transparent and not manipulable by select firms making the market on opaque systems, and there is no bridging infrastructure subject to liveliness failure. Pricing happens onchain, therefore price is always available onchain.

I think @sendmoodz suggestions above are valuable. Ekubo as a ‘backup oracle’ is a no-brainer, but perhaps a public fork of Ekubo not attatched to it’s protocol factory as a ‘primary oracle’ has merit. I argue for using a public-good fork to maintain neutrality at a protocol level.

I tend to disagree with this comment

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.

I don’t think anything needs to be invented here. AMMs are designed for allowing assets to discover price onchain.

Having a deeply liquid venue to convert ETH ↔ STRK onchain should be considered a public good that lifts the whole ecosystem beyond it’s usefulness as a decentralized price oracle.

Overall I understand the current Pragma Oracle solution is an interim solution, but wanted to mention that we can shift our thinking here if we plan around liquidity remaining onchain. Really excited for v3 transactions.

[imrgoyal]

It feels like STRK is only useful when there is more than one sequencer live.

To my understanding so far(feel free to correct me if I am wrong), the sequencer is always quoting the cost in one token (WEI), and we are trying to make users pay using STRK. And it is because, as of now, STRK is not adding any utility to the network as there is no network.

When Starknet is decentralized (anyone can be a sequencer in a certain set of rules), STRK plays as the security layer to enable that. Only then could the sequencer’s cost be calculated in STRK instead of just WEI. When quoting the cost in STRK users just pay using STRK and it is the different sequencer’s responsibility to liquidate the STRK and we don’t need to do that on protocol level.

It looks like STRK-WEI could have much complicated consequences than we are able to justify now. While there is no need for pay with STRK today.

[matteo]

@DevenMat

Using an oracle assumes the primary source of liquidity for ETH<>STRK is Binance, Kraken, etc. which I presume only becomes the case if ‘sophisticated actors’ are given a large amount of tokens to market-make on centralized exchanges upon launch.

I will have to disagree here, the role of the Oracle is not to aggregate offchain prices and provide it to the sequencer, but to provide a fair price at which the token is trading. Happy to elaborate more on how we compute the fair price, but in fact, it is not computed only from offchain sources with Market makers and centralized exchanges, but also using onchain liquidity, and especially with solvers (Avnu, Propeller Heads and others).

@DevenMat

Pricing happens onchain, therefore price is always available onchain.

This is a bit naive, for two main reasons:

• Pricing today for tokens on Starknet doesn’t happen onchain, but through aggregators (that run solvers offchain). It’s hard to get the exact numbers to prove this point, but we would have to sort volume only for short tail assets (ETH/WBTC/DAI/USDC/WSTETH/USDT on mainnet), with 1k minimum trade to remove wash trading from airdrop farmers. But let’s take the overall volume, there’s 1,3b total volume through aggregators, for around 2.1b$ total volume on DEXs, so more than 50% of the total volume.
• If you take a look at other L2s tokens, OP has around 2% of the volume traded onchain, Arbitrum 20%, Polygon less than 1%, and Mantle 4%. Even Metis which has their token as gas token has around 20% of the total volume onchain. Thinking that we can have all the volume on Starknet at launch is idealistic. We can just take a look at slippage on mainnet for the most traded volatile pair ETH/USDC, you have a 0.50% slippage for a 100,000$ trade, and 4.5% for a 1m$ (and this is the most liquid pair on Starknet, I encourage you to take a look at the slippage on less liquid volatile pairs, it’ll be closer to what we can expect for the STRK at launch for the first months). It’s not possible to trade million dollars efficiently only onchain. I’d love to have price discovery onchain, but it’s just not something we can have with the efficiency of AMMs on mainnet, so unfortunately (or not actually because it means that people will have liquid access to STRK) we’ll need CEXs and Market making because of the nature of CLOBs.

@DevenMat

Ekubo as a ‘backup oracle’ is a no-brainer

I agree on this, to have 100% uptime regardless of Pragma’s state, and from my understanding, it was already part of the design of the fallback mechanism.

@DevenMat

maintain neutrality at a protocol level.

Our code is open-source, if the foundation or anyone thinks they can run it and maintain it in a more safe, stable and neutral way, they may proceed. I already argued about why it didn’t make sense to use only one onchain source, but I have no problem with the community or anyone taking the code and running it, it just has costs and that’s why oracles exist.

For the rest of the comment, I think I already gave my point of view, but I’ll just add that having one price source, onchain already proved its limits and manipulability (https://www.chainalysis.com/blog/oracle-manipulation-attacks-rising/)

I think you have a very idealistic vision, and I hope that we’ll be able to trade a bigger proportion of assets and especially the STRK onchain. But there’s still a long road ahead in terms of efficiency improvements to be able to do it. In the meantime, I hope Pragma can provide the best alternative for Starknet feeds, and if you think we can improve anything, feel free to DM me.

[matteo]

@ilia might give a more complete answer, and overall I agree with your point, especially that STRK will be used at full potential with the decentralized network setup.

But I think using STRK as gas token even before enables a few things, that are worth contemplating:

• Giving users things to use their tokens for: STRK will certainly be available to use in different protocols, but letting users use it for gas fees is useful.

• Empowering the foundation to start no-gas onboarding: It’s a secret to no one, the foundation has tokens to allocate for subsidizing gas fees, if STRK is enabled as gas fees the foundation could start sponsoring part of the gas fees to drive more adoption, for onboarding or using dapps.

• Starting to decentralize the governance through devonomics: The foundation has announced the devonomics, rewarding dev teams with ETH. If the sequencer collects STRK, it can enable the foundation to distribute and decentralize the network across core devs and app builders in an efficient way, using the devconomics framework.

• Get an idea about the appetite for users to pay in STRK rather than ETH: The network will fully quote the gas in STRK as it decentralizes, it would be good to have an initial idea about the appetite of users to pay in STRK while they still can pay in ETH. So that we’ll be able to know if we need paymasters before decentralization and what to prioritize in terms of UX/decentralization tradeoff.

So we get all of this, and again just to make things clear, the only complicated consequence introduced by the STRK payment is possible bad debt for the sequencer operator (no user fund touched), capped by a maximum of (gas fees required to settle one L2 block on L1) * (number of blocks on Starknet misquoted) or potential too high STRK gas price, but users can still pay in ETH in that case.

[zkcyborg]

Interesting proposal indeed, Could you please clarify if the intention is to exclusively utilize Pragma 60 for this purpose? Additionally, are there any alternative price feed providers under consideration to ensure diversity and reliability in the price feed sources?

[sendmoodz]

@DevenMat

I think @sendmoodz suggestions above are valuable. Ekubo as a ‘backup oracle’ is a no-brainer, but perhaps a public fork of Ekubo not attatched to it’s protocol factory as a ‘primary oracle’ has merit. I argue for using a public-good fork to maintain neutrality at a protocol level.

Ekubo is closed source today, so there is no possibility to fork it. That said, the code is permissionless: anyone can create a pool with any tokens and any extension. In the future, we plan to decentralize, including open sourcing the protocol, so it could still make sense in the future to enshrine Ekubo as a core component of the Starknet network.

@matteo

So we get all of this, and again just to make things clear, the only complicated consequence introduced by the STRK payment is possible bad debt for the sequencer operator (no user fund touched), capped by a maximum of (gas fees required to settle one L2 block on L1) * (number of blocks on Starknet misquoted) or potential too high STRK gas price, but users can still pay in ETH in that case.

Since the stakes are low, it seems you don’t need to optimize for maximum manipulation resistance, versus for example liveness. The sequencer takes on the price risk, and it’s to the tune of a few hundred dollars per Starknet block.

The worst case I can imagine for a price manipulation is that the attacker increases the price of gas to DOS the network. Increased gas prices decrease manipulation resistance of on-chain oracles since the fixed cost to arbitrage is greater. That would be a point in favor of the Ekubo TWAP oracle over the VWAP oracle, since the manipulator would have to maintain the higher gas price for longer to create a DOS, whereas the attacker could simply sell (since manipulating price of token down increases price denominated in STARK) a large volume of Starknet token all at once if utilizing a VWAP. With both types of average prices, the period over which the price is measured can be increased to increase manipulation resistance.

[matteo]

@sendmoodz

Since the stakes are low, it seems you don’t need to optimize for maximum manipulation resistance, versus for example liveness.

Well, I’m not sure I agree here, the stakes are low yes (at least in terms of $ at stake), but a liveness failure only impacts the sequencer operator (who will potentially have bad debt) whereas a price manipulation impacts both the sequencer operator and the user, who may suffer from gas fees too high.

@sendmoodz

Increased gas prices decrease manipulation resistance of on-chain oracles since the fixed cost to arbitrage is greater. That would be a point in favor of the Ekubo TWAP oracle

I’m not sure I understand the implication here, increased gas price increases the cost to arbitrage, so how is it in favor of an onchain TWAP oracle if manipulating the price onchain (price that is used to quote the gas) further discourages arbitragers to arbitrage it, and thus makes the attack even less expensive?

I think using Ekubo as a backup for liveness failure can be useful, but for normal conditions of usage, an oracle providing the latest price (and not a lagging TWAP indicator) is better for the UX, especially given the fact that both Eth and Strk tx will be enabled at the same time on the network.

[sendmoodz]

@matteo

Well, I’m not sure I agree here, the stakes are low yes (at least in terms of $ at stake), but a liveness failure only impacts the sequencer operator (who will potentially have bad debt) whereas a price manipulation impacts both the sequencer operator and the user, who may suffer from gas fees too high.

I agree with this. Sorry, when I said “liveness,” I was thinking of availability. But I believe the pragma oracle will be read from on-chain, so there is no difference in availability.

@matteo

I’m not sure I understand the implication here, increased gas price increases the cost to arbitrage, so how is it in favor of an onchain TWAP oracle if manipulating the price onchain (price that is used to quote the gas) further discourages arbitragers to arbitrage it, and thus makes the attack even less expensive?

To clarify, in favor of TWAP oracle over VWAP oracle, not over Pragma/off-chain oracle. The manipulation would be harder to achieve with a TWAP oracle because you would have to maintain the manipulated price for a period of time, paying arbitrage costs, whereas the volume weighted oracle manipulation would likely be much cheaper. I think both versions of on-chain oracle are less manipulation resistant than they seem due to the effect of higher fixed arbitrage costs.

[Jommi]

has there been talks of doing something akin to what Terra did with the CosmosSDK oracle module?

GitHub - relevant-community/oracle: Cosmos Oracle Module

Validators are pushed to run certain oracles that are deemed “integral” for the chain to function. This could be one of those cases.