Thanks for putting all of this together @drnick, very thoughtful and detailed!
How many TPPs do we expect to have running throughout the year? Trying to figure out how much work will there be for delegates with 5-10 TPPs with 2 2-week evaluation period for each. Delegate participation starts off enthusiastically in new DAOs but it drastically slows down after some time. It is a real problem for all DAOs and if we solely rely on Delegates for most of the operational decisions that could put us in a tough spot.
STOP action can indicate a contract to self-terminate (autonomous), and PAUSE action can happen autonomously too, but when it comes to ITERATE and CONTINUE, those will involve Delegate involvement when something needs to be iterated and continued, correct?
Yes. Fully support this. Great idea.
I love this. This is how I understood TPPs. Wasn’t this how they are already intended (designed) to work? 
This sounds fantastic in theory and I cannot wait to have the first couple of TPPs active to see how it will all look like in practice.
Thoughts, questions, concerns
- Are we putting the complexity of the innovative token distribution mechanism over accessibility? ZKsync is getting in the arena (a year late) with OP, ARB, etc. and reducing the friction to building onchain would be desirable.
- TPPs are designed to only retroactively fund projects for their achievements/milestones measured by predefined onchain metrics. Will we have grants specifically oriented toward certain things like apps, governance tooling, dev tooling on ZKsync, defi innovations, ifra, etc.?
- Who will be in charge of designing these detailed contracts for TPPs? Devs submitting them, or will they have a designated place to go if they are not developers?
- Will anyone other than devs be comfortable, willing, and capable of building them (artists, creators, etc.)?
- Is it worth considering having a “working group” (for the lack of a better word) that would conduct, oversee, and help with TPPs, from brainstorming to launch?
- Protecting against gaming the contract’s logic, exploiting the benefits by manipulating visible onchain metrics for its success, and fail-safe mechanism to protect ourselves against those?
- I love TPPs in the context of competitions!!! This in my opinion is one perfect use case for them that could spark a lot of interest, onchain activity, and build communities around competitions we build TPPs for. (competition example: social apps with most users with some onchain identity verification to sybil protect, and minimum user activity requirements to be eligible for reward etc. all to protect against people gaming the system. Very random and not clearly defined idea but you get the point.)
- How do we fund initiatives that don’t have an onchain component to track, measure, and automate through contract logic? (creating educational content for example, or R&D, or building a custom ZKsync library for some programing language, etc.)
- Maybe we should start a discussion about TPPs that focuses on actionable steps on how we put them to work.
I know we’re trying to be automated and involve people as little as possible, but is it worth considering creating a working group (for the lack of a better word) that would at least for the first year or two make sure TPPs are fully understood by everyone, help with the design, coordination, gathering info, data, learnings, and improving them, etc.
I see TPPs as an experimental DAO product designed to do a thing. And like with any other product, to ensure its success, I think it’d be best if we have a dedicated team around it. For now, we rely on the Ecosystem and Delegates to figure them out and put them to work. There are no guarantees they will work effectively without proper management.
Since TPPs are ‘in charge’ of providing the financing for the entire ecosystem, I wonder who’s in charge of conducting and creating that ecosystem around ZKsync. That said, I think it’s equally important to have Ecosystem Leads just like we have Governance Leads. Without someone proactively enforcing TPPs, helping people with creating them, etc., I see a lot of unanswered questions like how do we create the developer, artist, creator, builder culture in ZKsync? This is usually done through sponsoring program grants of what we want people to build (applications, defi, social apps, dev tooling, governance tooling, etc.). It’s also done through Hackathons IRL where people get to meet and connect and build something of value. And many other ways that require more hands-on involvement which, correct me if I’m wrong, we don’t have at the moment. I doubt culture will emerge through an automated process and no human touch, because it mostly relies on emotions. ENS has been doing this quite well with their 3 working groups and now I see Arbitrum is going towards something similar but even bigger in scope (link to the post).
–
In principle, I agree with everything you said. It’s like reading a semi-scientific explanation of an innovative, futuristic, and creative token distribution model with a cypherpunk overtone, and I love it. 
If we look at TPPs for what they are, they are 1) Product and 2) Experimental token distribution mechanism. And if there’s something we all undeniably agree on, it’s that TPP design is absolutely fantastic and I personally see it as the ‘end game’ of how DAOs should work. But I don’t think 1) we can start with it and neglect proven methods that simply worked for other DAOs, and 2) let it launch itself on the market without a dedicated team for it and the entire ecosystem.
–
@daniel-ospina I share your thoughts + concerns, and enthusiasm + optimism about TPPs. +1 for your comment.