Starknet’s second vote is coming - Starknet Alpha v0.12.0

Starknet Alpha v0.12.0 timeline

We are excited to share that the next vote on Starknet protocol upgrade is just around the corner. Starknet Alpha v0.12.0 is planned to be deployed on integration in mid-June, which will lead us to Goerli deployment and voting in the second half of June!

Starknet Alpha v0.12.0 details

Starknet Alpha v0.12.0 brings a range of exciting enhancements focused on performance and user experience. Among the notable improvements is the introduction of a new Rust implementation for the sequencer. This version is expected to have a significant impact on the network - increased throughput and lower transaction latency.

In addition, this version will include the removal of the PENDING transaction status, which means that the transaction status will progress directly from RECEIVED to ACCEPTED_ON_L2, and the addition of a block hash syscall.

You can find more information here. Expect an additional post diving into all the proposed changes as we approach the integration period.

Starknet Alpha v0.11.0 Reflection

Starknet Alpha v0.11.0 was the first version that was voted on by the community. We learned alot from it and from the community feedback posted in the v0.11.0 proposal forum thread. Read the conclusions and lessons from this vote posted here.

Proposed time frames for Starknet Alpha v0.12.0 vote

Among the lessons learned from the previous vote is that when proposing a new version, certain parameters should be taken into account with regards to its characteristics (i.e. the level of complexity, changes required among various tools, etc.)

  1. Integration period - The amount of time for a stable version on integration
  2. Testnet period - The amount of time for a stable version on a public testnet, before the vote start
  3. Voting period - The vote duration
  4. Freezing period - the amount of time between the vote conclusion and applying the decision on Mainnet

Note that the time durations are relatively short since the current version of v0.12.0 is significantly more simple than Starknet Alpha v0.11.0 in terms of tools adaption, testing needed, etc.

We appreciate feedback on the suggested upgrade period timeframes for v0.12.0.

New delegation agreement (Optional)

In order to promote delegate neutrality and enable informed decision-making by Starknet token holders, we have created a customized template delegation agreement which delegates are free to adopt. It’s important to note that this recommendation is optional. Delegation remains a completely permissionless process with no requirement to adopt any legal agreements. This is simply a tool for both delegates and token holders to define their relationship in permissionless delegation.

To adopt the template delegation agreement, visit your profile by clicking ‘Delegate Login’ on delegate.starknet.io and edit the ‘Delegation Agreement’ section to include your name in the template. Do not make any additional changes if you choose to adopt the recommended agreement posted.

If delegates choose not to adopt the specific terms proposed, we encourage them to clearly define their own terms and decision-making processes they adhere to both in their delegate profile and delegate agreement. While our template agreement serves as a helpful starting point, delegates should explore a variety of approaches and are free to express their own terms.

The delegation agreement TL;DR

  • The agreement is unilateral and if a token holder or a delegate choose to adopt it, both parties will be bound by the terms of the delegation agreement by executing a delegation.
  • Token holders will not exercise influence or control over the delegated tokens, allowing the delegate to exercise independent judgment in voting.
  • Delegates agree to:
    • Participate in governance in the best interest of the Starknet protocol.
    • Conduct due diligence, monitor community discussions, and review proposed changes to the protocol.
    • Not accept any payment or value that could influence their voting.

The ability to adopt a delegate agreement allows each delegate to define their relationship with those who chose to delegate to them. It also gives token holders clarity on the relationship between themselves and a selected delegate. Again, this is an additional tool available to delegates and is not a requirement for being a delegate for Starknet governance.

Call to action

  • We would be happy to hear feedback in the discussion following this thread.
  • If you are interested in becoming a delegate, now is a great time to step forward!
  • Stay tuned for further updates, including the specific timeline and details regarding the vote on Starknet Alpha v0.12.0.
  • Join the Starknet Snapshot space and turn on notificiations to stay up to date with future votes on network upgrades

Cheers,
Deven Matthews
Starknet Governance Committee