Should emergency switch functionality for Lelantus be extended? How should we transition from Lelantus to Lelantus Spark?

We are currently about 4 months out from our spork control expiring. This is effectively a master key for us to disable Lelantus should we notice any suspicious activity. The original proposal was to have it for 1 year. I recommend reading that thread as well.

I have no issues to have it expire. However there’s one niggling piece that’s bugging me and that’s relating to a security proof in Lelantus’ balance security.

Security proofs in cryptography are basically mathematical proofs that prove the security of a particular component. The lack of a proof doesn’t mean that the system is insecure and it may be practically secure; however there is no guarantee that it is.

Due to the way Lelantus v1 combines certain elements together for efficiency, proving one part of its security (namely balance security) is challenging. We had an existing security proof and another way to write the proof which addressed some concerns, but it didn’t prove it sufficiently and it’s unclear what’s the best way to proceed with this. Again this doesn’t mean that a flaw exists, just we can’t prove its security either.

This was also a reason why we also embarked on research with Lelantus Spark that separates these elements, making it much easier to prove security and doesn’t inherit the same problems with Lelantus v1.

Given the potential issues, we need to decide how we should handle this risk as to whether we should let it expire and set a good precedent as to not extending control or to get community approval to extend it as we move to Spark.

Transitioning from Lelantus to Lelantus Spark

This also has implications as to the transition from Lelantus to Lelantus Spark. There are two main ways we can transition from Lelantus to Lelantus Spark.

Lelantus > Transparent > Lelantus Spark
This was how Zcash did it and it has benefits in having a possible checkpoint on supply since amounts need to be revealed. They call this a turnstile. This hardly needs any special code to handle. However, it has deanonymization risks since amounts are revealed. It is much more likely to detect whether a flaw was found in Lelantus though not guaranteed if the attacker doesn’t drain the entire pool.
However all the anonymity sets we built up in Lelantus would need to be rebuilt again.

Lelantus > Lelantus Spark
This allows migration directly from Lelantus Mints into Lelantus Spark system. This preserves existing anonymity sets and there are much less deanonymization risks. A special transaction to do this would need to be created but it’s relatively simple still to do so.

However if there are any flaws in original Lelantus, this inflation can be carried over into Spark and would be hard to detect.

So the decisions are as follows

  • Should we extend emergency switch functionality and if so how long? Should it be until Spark is activated?
  • Should we have an emergency switch for Spark again with limited duration?
  • How should we do the transition? A turnstile migration or direct from Lelantus to Lelantus Spark?

I am in favor of the Lelantus → Lelantus Spark option. I would keep the Lelantus v1 emergency switch functionality until the change happens, and then I’d have a short fuse emergency switch on Lelantus Spark (like 4 or 6 months). After that, I would have no switch.

I don’t like the idea of a transparent phase. Privacy is Firo’s number 1 biggest selling point. It is the primary reason anyone would ever use Firo. I think we need to treat that as sacrosanct.


As much as a direct route is best for anon balances, for the long term, doing it right first time, might be best to start from scratch, I hate to say it but I’d go this way to ensure no issues or concerns further down the line.


I am for extending emergency switch. It is very useful feature and team already used it in time when needed for good of Firo.

If it will be useful for Lelantus Spark I am good with to have it in Lelantus Spark too.


Regarding way how transition to Lelantus Spark should be made I don’t have any knowledge to decide.

1 Like

I strongly support the idea of an emergency switch. Mistakes are part of life (and software development), and Lelantus makes undoing them much harder. Centralisation risk is imo pretty minor given that it’s a blanket disable for the entire system and can’t be used as an ongoing transaction censorship system. if it was used frivolously, it’s not hard to fork, and if the dev team was malicious a fork would be required anyway to reallocate our portion of the block reward.

For the upgrade path, I’m in favour of the turnstile approach. A higher degree of assurance in supply is one of our selling points, and the existence of this gap undermines that. A turnstile approach is the best solution here imo. I think if we cajole people into converting funds early on in the process, we can get a large anonymity set fairly quickly, so it shouldn’t be much of an issue there. Amounts are trickier as that can reveal more than desired. I’d probably recommend that every decimal digits of FIRO be sent in a different transaction (e.g for a balance of 10182.3, 10000 FIRO, 100 FIRO, 80 FIRO, 2 FIRO, and 0.3 FIRO transactions, similar to Sigma.) (The issue this is trying to avoid is someone having 10000 FIRO, someone sending them 182 FIRO, and noticing that 10182 FIRO come out and inferring that the user they sent to had 10000 FIRO balance.)


I think emergency switch should be kept for sometime until the activation of Lelantus Spark for fail safe.

For the mechanism of upgrade of Lelantus to Lelantus Spark, I favour the transparent way as this is our only chance to fully audit our supply. As Firo is still quite small, this method serves as a good foundation for our way forward. Revealing transaction amount doesn’t actually compromise anonymity very much since Firo previously also used zerocoin and sigma protocols for a few years which didnt also hide the amounts. Lelantus was only started this year. I think that number anonymity sets that are revealed is still quite small.


We should extend emergency switch functionality until Spark is activated.
We should have an emergency switch for Spark for 6 months.
I would like direct from Lelantus to Lelantus Spark.


I totally agree with the first paragraph … the centralisation risk is minimal at this time due to the well known honest actors involved. So keep the switch for this iteration of lelantus and have a switch on Spark that can be reviewed after a minimum of say 1 year.

For the upgrade transfer of funds, have we thought enough if it is possible to assure the supply is correct - the code (on github) being the prover - yet at the same time have a non-transparent transfer transaction.

Old --------> Spark
supply count


I like the idea of a transparent phase .
i think in short term we need this .
All the prominent blockchains have faced or are facing this kind of transition period.
you can see cardano or polkadot or cosmos for example.
We need to make sure the system is working properly .
It may seem painful, but we need it .
Accuracy of performance is of paramount importance .


I favour the idea of keeping the emergency switch available for another year. Despite all the hard work of the team there is a chance that a human error has crept into the code. Firo is still a relatively small project in terms of market cap and on chain transactions, so I think that we can consider it still to be in the development phase. Tightrope walkers don’t do their rehearsals without a safety net; if they did they might not be around for the main act!

For the transistion to Lelantus spark going via the turnstile, showing everyone’s hands so to speak, would be my preference. Anyone who is at risk of de-anonymisation will have enough time to make the necessary arrangements to cover themselves - swapping via a DEX to BTC for example. As above, best to build the project on solid foundations than to leave a hidden problem to clear up when the structure is much higher/bigger.


As privacy currency, the most important is credit. There has been a history of inflation by hackers,through this function switch, thoroughly make clear the exact amount of inflation.
The total amount can be checked, eliminating inflation is our core competitiveness,is the key to rebuilding credit,then Whales can safely put big money into FIRO


I totally agree with you

1 Like

I am in favour of extending the emergency switch functionality.

Like Lelantus before it, Lelantus Spark is treading new ground. Such exploration can be hazardous and fraught with danger. Having an emergency switch allows for a better response in cases of emergency as it reduces the amount of things that the team needs to monitor during such emergencies, allowing a much better response and concentration to fix the problem.

I am also in favour of having another time-limited emergency switch for Spark itself.

As for the transition method, I have no strong opinions for both the methods proposed. I can see the merit of both methods but am unable to choose one at this time.


We should completely eliminate the fear of inflation,We should clear to the public that we have zero tolerance for inflation,total audit,Don’t bring any possible inflation into Spark,agree with Lelantus > Transparent > Lelantus Spark

Firo’s investors (holders) have tens of thousands or hundreds of thousands of investors, Most of investors don’t understand technology, What they care about is:
1、Is it safe to deposit money in Firo for a long time? Will they suffer major losses due to code-bugs leading to ‘Infinite Counterfeit’ inflation?
2、Is it safe to hide money in Firo? Will they suffer major losses when Firo be hacked?
3、Is it enough anonymous to use Firo to avoid being attacked by Authoritarian government?
Investors(holders) need the technical team to give a deterministic answer.
whether this technology is advanced in the field of privacy,
whether this technology is impeccable in mathematical theory,
whether this technology is safe enough in code.
Very few people knew the cryptography well enough to make a right choice than Firo core technical team.Trust the core technical team Professional handles professional affairs