I am aware it is stated in the proposal and I understand that the TA can’t really do anything about this decision. I actually agree with it and believe it’s the a good decision. @Benido
Happy to hear you agree it was the right decision! And of course, the TA could have also ended the program at any time (not just at the end of the season as per the DSC responsibilities.)
At the same time I believe it is okay to ask if the decision was made purely by the DSC or if delegates were involved. I see that it’s not easy to involve all delegates, because a public discussion might lead uncertainty of some Ignite participants and hence to outflows. Still I think it is worth discussing if involving the TA could make sense, since outflows will now likely happen anyway…
- The decision was made by the DSC as per outlined in the proposal. I’ve been told they spoke with various delegates as well as industry experts before making their decision. Just 1-2 weeks ago there was a major delegate meetup at ETH Denver, where the ZKF + ML + TA went over their plans for the future and discussed current programs such as ignite. You can read the new post made by Marco of the ZKF here: ZKsync Foundation Proposals Priorities
- In this instance, it did not make sense to hold a vote in the TA about whether to continue or dissolve the program, since this exact situation is why this provision was added to the proposal. In the Fall when this program was being designed, delegates wanted the DSC to have the ability to end the program at the end of the season instead of only being able to cancel it via a voting process if they felt it was not living up to its goals in order to save the TA’s funds for future programs. One of the major concerns prior to Ignite was to not create an Arbitrum STIPP 2.0 situation.
Also there are three reasons stated by Karthik, and two of these are imo at least questionable (“Focus on the Elastic Network” and “Native Interop Timing”). I appreciate the transparency, but the at the same time I am surprised these come up now mentioned not even 3 months into the execution of the proposal when in Nov/ Dec when we discussed the proposal (before voting) the whole argument was that “zksync needs this and we need it now”. I understand that adapting is necessary, hence the third reason is absolutely valid in my eyes. I also believe it is necessary to commit to a strategy and the first reason seems to be a pivot.
- As was announced in December 2024, the roadmap for ZKsync for 2025 is focused on the Elastic Network (primiarly EVM equivalance, Native Interop, & decentralized sequencing/proving.) A shift of focus towards the Elastic Network has been the game plan since the Fall.
- The main purpose of Ignite was to “establish a liquidity hub” on ZKsync Era for the Elastic Chain. This directly relates to 1. A focus on the Elastic Network & 2. Native Interop timing. Since the DSC judged that continuing this program would not benefit the elastic network, then that’s a direct violation of the goals of this proposal. Furthermore, while the date has not been set for Native Interop, when this program was created in the Fall there was a hope that native interop would be ready by the end of seaon 1. That turned out to not be the case. Again, since the program is reliant on native interop to achieve it’s goal (becoming a liquidity hub requires native interop to tap into that liquidity), it not being ready is also another strike against continuing the program.
Also if the TA had sent one or two reps to the DSC like I and some other had suggested this would be less of an issue, because then the TA would technically be involved. Back then I didn’t think of this scenario, but now this makes it even more important for any similar proposal to include some delegates.
I believe 2 of the 5 members of the DSC are large delegates in ZKsync. But I agree with your point. It was the first TPP, and I think it would be helpful to have more delegates/community voices on future TPP committees. (I agreed with you back then too btw ^^)
- Once everything is wrapped up, will there be a report on key metrics, costs, and other details? @Tekr0x.eth
Yes! As outlined in the announcement above, “As we close out Ignite, we’re committed to learning from it. By the conclusion of Season 1 (March 30th, 2025), our partners at OBL will share a detailed Season 1 recap—packed with insights from the program’s run—this will include but is not limited to the results achieved, how much was spent, lessons learned, etc. Alongside OBL, the DSC and Merkl will also add their takeaways from the program to help shape smarter, future-focused incentive programs for ZKsync.”
- The main reason for canceling is the focus on Elastic Networks, which has been clear for a while. Why wasn’t this discussed earlier?
I’m not sure I understand the question? The main reason for not continuing the program is that after running the program the DSC realized that it is not serving the needs of the Elastic Network as was originally planned/envisioned. The DSC also only has the ability to cancel the program within ~2 weeks of the end of the program. The TA is the body that has the ability to cancel the program at any time.
ZKNation, like any DAO, values transparency. But this news came as a surprise to many. Why? Why are so many discussions still happening in closed groups? We’re all in this together. This can be improved.
Everything about Ignite has been posted bi-weekly since the program began on the forums. It was also clearly outlined in the proposal that the DSC will make a decision towards the end of each season about whether or not to continue the program. Of course, the plan is never to keep delegates in the dark about any governance program, however there are 1,000+ moving pieces and day-to-day operations/decisions that cannot possibly be discussed live. Moving forward, I think it will be beneficial to setup a reoccurring call with delegates updating them about everything regarding future programs. (Note: Ignite did have this one set up as monthly, but perhaps bi-weekly would be more ideal?)
This is why the Assembly should have its own ‘steering committee’ (in the form of a BORG) that oversees all these different proposals and is directly accountable to the Assembly, rather than each TPP recipient appointing its own ‘steering commitee’ on a centralized basis. @lex_node
I don’t know if this would be feasible as each TPP committee requires different experts, specialized knowledge, and lack of conflicts-of-interest to operate effectively. If you had one centralized body overseeing every TPP I don’t think they would be effective. I am in favor of creating a list of community members that can potentially serve on future committee’s with their qualifications & experience listed out. Also, every committee of any TPP is ultimately directly accountable tot he Assembly. In the case of the DSC, they made monthly reports to the TA as per set forth in the Ignite proposal. The Assembly always has the power to pause, cancel, modify, etc any TPP.