Formula 1 teams appear to broadly agree that a ‘token system’ is one of the mechanisms that will be used for controlling car development in 2020/21.
It’s certainly a workable system that would be used to limit the areas of development that aren’t frozen as part of the emergency measures introduced for the next two seasons. But exactly how you manage it is the big question.
The teams all do a lot of aerodynamic research and have a thorough understanding of the areas that produce, directly or indirectly, the downforce and drag on the car.
The FIA and F1 have done the same to understand the current car’s aerodynamic characteristics which has allowed them to come up with the new regulations for what was 2021 and is now 2022, so together they could come up with a set of figures averaged out between them all that identifies the big pay days from development.
So for the sake of argument you could say the bargeboards contribute 20%, the diffuser 25% and so on, and assign similar figures to each area that basically amount to 100% of the car’s downforce.
Then you could say each car has 100 tokens to spend on the aerodynamics. So if you change the bargeboards, that’s 20 tokens based on the 20%, or however the numbers pan out. You’d have to define exactly what constitutes a change and if you can get away with very small tweaks, but it’s an easy way to create the broad structure for the tokens.
The big problem is that each team will have multiple different rear wing specifications for different tracks. You might say you can use 100% of the frontal area for downforce at Monaco and then 30% of that at Monza. Perhaps you could allow a wildcard for changes of the rear wing across a number of agreed specifications, but that’s easily sortable if everyone works together for the common good.
Then you could have a separate pot of tokens for the mechanical side, but within that you also have to allow scope to react to reliability problems because nobody is going to object to a team changing its uprights if it’s had a wheel bearing failure or something that creates a reliability problem.
Such a mechanism is easy to put into place but the team would have to stipulate it has had a failure, or at least clear signs of a future failure to have the approval for that.
You can easily create a system that works using these tokens, but an important question is, why there isn’t just a system in place that allows you to change these parts a certain number of times – perhaps even just once a year or at a pre-determined event when everyone has an opportunity to introduce a single substantial upgrade.
