##### 1. Regarding `it really, really, really looks like they decided to completely deprioritize the gossamer`
Work on Gossamer never stopped. In fact, over the past year it became even more productive, with a clear [roadmap](https://github.com/orgs/ChainSafe/projects/58/views/7) and [well-defined issues](https://github.com/ChainSafe/gossamer/tree/development/docs/docs/design) for all the major remaining modules. We would be very happy to continue working on Gossamer, but as the last proposal showed, it is not something the community or Parity is willing to pursue further.

All of our resources have been dedicated to Gossamer. Eclesio occasionally contributed to PVM, Karan, as a junior engineer, was assigned to JAM since it is the least context-heavy task, and Jimmy has been primarily focused on JAM from the very beginning, though he continued to contribute to Gossamer as well.
##### 2. Regarding: `using the treasury funds to fund the JAM implementation`
As soon as the JAM paper was released, we were surprised - as was pretty much everyone else. The situation of not fully understanding its implications continues to this day. Naturally, once JAM was announced, we all conducted a deep review of the paper to better understand it.
Jimmy was tasked to dedicate most of his time to JAM after November and our JAM meetup in Bangkok, when it became clearer that JAM is, in some sense, inevitable. Meanwhile, the rest of the team continued focusing about 95% of their time on Gossamer, contributing to JAM only occasionally - typically once their main tasks were completed.
I don’t think it is realistic to completely ignore JAM or avoid working on it altogether in any case.
##### 3. Regarding `It is obvious that at least 2 of the 8 developers mentioned in the proposal (Karan and Jimmy) are currently working on the JAM client exclusively. Also, I'm pretty sure that Haiko is also mostly working on the JAM client.`
It is only partly true, mainly because Karan has been working on JAM full time. There are several reasons for this. First, as mentioned earlier, he had just joined the team and we didn’t expect him to meaningfully contribute to these new polkadot-sdk tasks in the initial phase (although he is actually a Rust developer). We just saw JAM as a perfect bootcamp for a newly coming engineer. And becouse of the high level of uncertainty around the current proposal and the future in general he stayd there for now.

Meanwhile, Jimmy was helping to shape the specification for all the tasks included in the current proposal before leaving for vacation.

Haiko, has been fully dedicated to this new proposal from the start and was NOT involved in JAM. He worked on Speculative Availability, Cargo optimisation, and, given his prior involvement with infrastructure during the Gossamer phase, is now focused on setting up a TestNet from Parity nodes along with Zombinet testing environments. Those are very needed to test our work for Approval Rewards and Speculative availability. These are critical for validating nearly any change we implement, even if they are not explicitly reflected in the proposal. Here is [his PR regarding infra](https://github.com/ChainSafe/gossamer-parity/pull/27/files). This is not mentioning general participation in specing the tasks.

##### 4. Regarding WebRTC speicifically.
I guess I am not going to repeat after [Tim's coment](https://discord.com/channels/961984944656236574/1403418752904724622/1405946610332209197) when it comes to WebRTC, he is the assigned person there and I beleive did a great job working on it and describing you the situation.

##### 5. Regarding: `it's not like Parity has come up saying that they will monitor your work and provide reports about your performance to ensure that you guys are delivering.` + `And what guarantees do we have that if you guys don't deliver that you will stop getting paid?`
Those are good questions, I cant answer them myself since they are mostly should be addresssed by Parity. But currently we pretty much working as a Parity team with me as a manager of 8 engineers. We have syncs all together we have syncs wiht Parity devs. independently, etc. Idea was that if we won't be delivering that would be pretty obvious to them so they will Kill/Cancel the referenda.

##### 6. Regarding proposed scope of issues
The SoW was not proposed by us; on the contrary, all the issues came directly from Parity. Initially, these were essentially just a single sentence in each direction and a couple of calls with Parity. This partly explains why we spent the first three weeks defining the scope - it came to us completely out of the blue. We are strong protocol engineers, but you can’t switch context with the snap of a finger. At times, it required significant effort just to fully understand the problem.
With respect, the set of proposed issues appears to reflect an individual perspective. Confirming the scope with the broader OpenGov community would not be feasible, as this type of work requires specialized technical input and coordinated responsibility. In this case, the appropriate counterpart is Parity. The Statement of Work was not developed with input from just one or two individuals at Parity - at least 11 people contributed, many of whom are well-known Parity engineers.

##### 7. Regarding other ways of funding
Creating separate proposal for every feature delivered carries high risks, creates a heavy administrative burden, and requires a long waiting period before it is even clear whether funding will be approved or not.

I do believe there is a way to make Rust bounties work, but much of the effort involved is long-term and not limited to coding alone. That makes it very difficult to manage and wrap into a bounty structure. Still, it might serve as a last-resort option.

##### 8. Regarding: `I find it reasonble to pay a certain amount upfront, and another amount upon delivery, for sure!`
That’s essentially what the current proposal is, just with a broader scope of issues. I understand you have concerns about some of the priorities, but honestly, who should be making that decision? As I outlined before, I assumed it should be Parity.

##### 9. My general note.
I’d like to reiterate something I’ve already mentioned. For us, this entire situation carries high risk, which explains some of the decisions we made - such as keeping Karan focused on JAM.
As outlined in our previous proposal, ChainSafe has essentially been funding the team since April, with the plan to continue working on Gossamer, along with a few other promising ideas for client development. After our first referenda failed, the future became uncertain, and the team of nine faced a choice: to seek new opportunities within the ecosystem or to pursue the alternative paths outlined by ChainSafe. This is not the most motivating situation, and in addition, the whole team had to pivot to pretty much R&D in July to properly outline the scope together with Parity. This is also work—maybe not that tangible, but still very demanding and important.

As the one responsible, I felt it was my duty to make every effort to keep us within the Polkadot ecosystem. That’s why we approached Parity and ultimately agreed to the scope you see today.