[Tour de SOL] Stage 1 - Details

Tour de SOL Restructure

Link to TdS Registration


We are revising Tour de SOL (TdS) from 3 events into an ongoing series of incentivised and scheduled events that will run continuously throughout the remainder of 2020. These events will generally run for a month at a time, and will be tied to the Solana protocol release schedule. In this way, we will have a process by which network vulnerabilities and adversarial strategies can be consistently tested and addressed, before being implemented into our Global Cluster (GC). We firmly believe that this new format will be much more aligned with not only the short term, but also the longer term growth of the network.

Each stage will be based on a particular version of our software release, and will not be implemented into the GC network until it has reached a satisfactory level of security and stability.

Stage 1*

  • Start Date/Time: February 4th at 8:00am PST
  • Estimated Duration: 4 weeks
  • On-boarding Period: 24 hours, starting from February 4th at 8:00am PST
  • Malicious behaviour will be incentivised
  • We will not be running Ramp TPS (pushing transactions through the network) in this stage. With recent performance metrics with 20 to 40 3rd party nodes we managed to achieve an average of ~16,000 tx/s (peaking at ~66,000 tx/s) and ~9000 tx/s (peaking at ~60,000 tx/s) respectively, we’re relatively satisfied with that for now. So the focus for now is on network security, stability and refinement.

Stage 2 and beyond

  • Additional details will be announced progressively depending on the progress made on the previous stages
  • Within each stage the allowable attack surface will vary depending on engineering goals and any new features enabled with each new release. Similarly, metrics upon which participants will be measured against will vary to suit (i.e. performance may be enabled in future stages with Ramp TPS or some other method, and total stake accumulated would become a metric upon which compensation is tied).
  • Our intention at this point in time is for each Stage to run for up to approximately 4 weeks.
  • Future stages will not start until the previous stage is complete

*Note that we reserve the right to change the schedule/duration if required, but we’ll endeavour to provide clear and ample notification if so.

Attack Surface

  • Each Stage will be configured to behave exactly like the next-in-line upgrade for the GC network at each respective point in time. Participants can expect the attack surface to grow over time as more features are enabled. We’ll be starting with the v0.24.X release line.


We’ve reworked compensation for several reasons including some which we’ve addressed further below in this post. The categories are:

  1. Participation: This will be measured by multiple factors, including but not limited to if you’ve joined the network, are actively staked, are responsive to issues (i.e. don’t become delinquent, or actively work to resolve the issue if you become delinquent), implement patches/upgrades within a reasonable timeframe and remain so until the end of the stage.

    • Compensation Amount: 3,500 SOL per participant
  2. Attacks/Identifying Issues*: We’ll be incentivising participants for conducting network attacks, and identifying bugs within the network. Attacks/Bugs will be separated into two separate classes:

    • Critical: Attacks/Issues that take down the network or successfully execute an economic attack. Issues that simply manifest over time due to failure of our software - without deliberate exploitation - will be excluded.
      • Compensation Amount: 20,000 SOL each
    • Other: Any other attacks/issues that are identified but don’t fall within the ‘Critical’ category.
      • Compensation Amount: 3,000 SOL each
    • The successful attacker/bug-finder must file a github issue, describing the attack to be eligible (amongst registration etc.) for the compensation. The attack is off-limits and not to be attempted again until it has been resolved.

Communication Channels for the Event:

  • Primary Channel: We’ve set up a channel titled #tourdesol-announcements which you can join to stay up to date on any major updates related to the events
  • Other channels we’ll also be re-distributing any major announcements via:
    • WeChat: message Dominic#6192 on discord to for an invite
    • E-mail: Your registered email
    • Telegram


While the original format for TdS made sense at the time, the Dry Runs and our recent launch of Soft-Launch Phase 1.1 (SLP1.1) have introduced some additional factors we’ve had to consider:

Learning to Optimise Performance

During Dry Run 6 it was clear that while we’ve proven out that Solana’s technology is able to better utilise hardware and bandwidth to deliver a much more performant blockchain solution, the specifics around what hardware and bandwidth in an open decentralised network validators should optimise for is still a learning process. Most of our hardware and bandwidth recommendations to date have been based on our internal tests run in a private cluster within a private GCE cluster or in a dedicated server rack.

Therefore it doesn’t make sense to have Validators compete to outperform each other, when it isn’t clear what will and won’t improve performance right now. Solving for this is critical, and we believe ongoing TdS stages will be a perfect playground for experimentation to help identify optimal baseline hardware, bandwidth and configurations. It’ll also provide opportunities for Validators and ourselves to develop better tools for analysis on what does and doesn’t have real impact on performance.

Maintaining a Robust Infrastructure

Since the initial announcement of TdS we’ve also introduced a parallel network, SLP1.1, separate to TdS. Which is designed to be a persistent network that will be iterated on over time together. A network which we’ll be looking to upgrade it to what we’re calling the Global Cluster (GC) with ongoing software releases leading and functioning as the primary Solana development network.

While each upgrade to the GC network will represent a significant milestone, development will still be ongoing. As a result, there’ll be a significant amount of testing that will be necessary at each step of the way both internally and externally. Trying to squeeze all of that into a once off campaign (i.e. the original TdS format) would have allowed us to responsibly deploy a particular version of software for a specific point in time. But didn’t provide ongoing coverage as the software continues evolves over time.

Final Words

If anyone has any questions, please do feel free to reach out to me or others from the team. Alternatively we’ll be available during our Bi-Weekly Validator Roundtables to answer any questions via video call as well. If you don’t have the invitation for that, please contact me on discord.

Link to TdS Registration


@dominic To clarify, it seems like malicious behavior in this context is malicious toward the network, not toward other validators, i.e. attack the network, not other validators. Is this the correct interpretation?

Great question @cjremus. Yes you’re correct, and to be specific about what behaviour is not acceptable:

  • Any attacks against nodes that violate cloud providers policies
  • Social engineering attacks against other validators. This includes but is not limited to activities like phishing, cloud account credential compromise, malware distribution, and physical security attacks on data centres are out of bounds for this competition.
  • Attacking any networks outside of the TdS - Stage 1 network
  • Causing long-term harm to a validator setup