We've been working tirelessly with Starkware last few months to enable type 3 transactions on Starknet. This marks the first step towards empowering the Starknet token to drive the protocol, initiating Starknet's journey towards decentralization. This article will highlight the different design choices made to enable this, as we deeply considered them while building it. Let’s jump in.
For Starknet to leverage security from L1, it necessitates paying rent for data publishing and proof verification. This adds complexity to the protocol, introducing two resource types to price: L1 resources, such as the described ETH-paid rent, and L2 native resources encompassing costs like sequencer decentralization, L2 congestion, and proof generation, paid in STRK. Simplifying the user experience requires the protocol to absorb this complexity, offering a single final gas price in one currency. This unified price reflects the aggregate pricing of all these resources.
Before diving into the conversion itself, it's crucial to clarify why STRK is the token we need as the gas token. This doesn't rule out the possibility of having a paymaster and enabling gas payment in other tokens. However, at the protocol level, resources should be priced in STRK. This is because we can use STRK to cover L1 resources - albeit through a STRK/ETH conversion - as it's a finite resource. On the contrary, it's impossible to use ETH or any other non-native token to price L2 resources. L2 resources require programmable aspects and potentially even some inflation/deflation to, for example, adjust incentives for decentralization or accurately price L2 blockspace. If you're interested in delving deeper into this subject, I encourage you to read the different posts written by the master Ilia on the Starknet forum about decentralization.
Now, let's zoom in on the conversion itself. While we've extensively discussed the decentralized settings necessary for the future, this upgrade is slated for the short term and will initially operate with a centralized sequencer. This has guided the design of the current type 3 transaction proposal. Presently, when the sequencer creates a block, it quotes L1 and L2 resources in a wei amount, assuming some risk as the L1 settlement occurs later, potentially leading to gas price fluctuations. Similarly, the proposal adheres to this principle, placing the risk of the STRK/ETH conversion on the sequencer—centralized for now, yet transitioning to decentralized later. In a decentralized setup (from my personal perspective on the protocol's design), when operating a Starknet sequencer, operators will have the autonomy to choose how to manage this risk. This entails determining how to handle the conversion, selecting the oracle for price feeds, and more. For now, there’s only one sequencer, and Pragma has provided the most battle-tested feeds for the Starknet ecosystem since early 2022.
The specific feed intended for use by the Starknet sequencer has been meticulously crafted to minimize the risks for the operator. It harnesses the robust data from our partners—centralized exchanges, market makers, solvers, and brokers—ensuring the utmost accuracy in STRK data. Initially, this feed will operate offchain, with our intention set on pushing for a fully onchain mechanism. However, considering network stability challenges observed during token launches, such as on Arbitrum, where RPCs were down and blockspace was highly demanded, achieving an on-chain feed becomes unfeasible. The competition for oracle updates amidst transactions, coupled with Starknet's lack of a fee market, might prevent the oracle from doing the updates onchain.
The model utilized for the feed incorporates prices from various sources available at the launch. It has undergone testing in similar contexts to ensure its stability (such as the Arbitrum token launch). We acknowledge that simulating such events can be particularly chaotic and challenging. However, efforts have been focused on two main aspects that have proven to enhance stability and accuracy:
Treatment of the outliers: Liquidity is fickle, swiftly transitioning between different sources. Outliers frequently emerge as liquidity shifts during such events. Identifying and removing these outliers has enhanced the stability of the data feed.
Volatility: High volatility is expected, and the higher the volatility, the greater the risk taken by the sequencer. The model considers realized volatility and quotes a premium when it is high to decrease risks.
We’ll ensure monitoring of the feed and the model in real-time, in order to make sure of the robustness and accuracy of it.