I’m considering making this topic a separate thread so as not to distract from the Symmetric team. Again I’d like to reiterate that this is not directed at Symmetric, rather the Friendly Fork process in general.
First of all, I’m not anon. Am I yelling my identify from the mountaintops? No. But anyone who tries can figure out who I am pretty easily. I’m not anti-anon either, I’m pro-trustlessness. To that end, how would I approach the issue? I’d have a list of clear requirements that are required to be considered.
To be honest, I don’t think that my original request for verified contracts is even “increasing the number of requirements” as much as actually following what was originally outlined. From the Friendly Fork Proposal:
I’m guessing someone will be eager to jump on the “ideally” in that bullet point and say it’s not a precondition. I would argue that the “ideally” here implies that ideally the contracts are identical, and that if they’re not they need to be explained. Eager to hear what @followthechain 's intent was.
As far as anything else I think should be a requirement, I’d succinctly sum it up as “it should exist at the time of proposal for vote.” This process should not exist to hype unreleased projects.
What does it mean to “exist”? I’d start with this list:
- Verified contracts. List open for discussion but I’d propose at least [Vault, Authorizer, BalancerHelpers, WeightedPoolFactory, WeightedPool2TokensFactory, StablePhantomPoolFactory]
- Subgraph
- SOR
- UI (minimally swap, join, exit; more functionality preferred)