I have already been extremely clear about this. The hard constraint is that no entity receives funds from the protocol without their consent, at any point in time. Just that.
We could, in principle, support almost anything else. But how can we answer what options we will actively support without even seeing a draft of them that meets the above hard constraint? It’s a preposterous question.
When it does not include Bootstrap/ECC receiving funds at a hard-coded address (that is, other than via a sufficiently decentralized mechanism with community consensus) more than one year after the 2024 halving.
When it’s reasonably implementable, secure, the design is audited, it has community consensus, and it meets the above hard constraint on recipient consent.
That said, I’m not going to commit ECC to support anything sight-unseen.
This isn’t supposed to be an adversarial process. It would obviously be possible to gerrymander proposals that could be argued to meet these criteria but somehow be unreasonable in other ways. I am not trying to avoid your questions, but I don’t know why your posts are always so fraught, as if you think ECC must be trying to “pull a fast one” or something. It’s just odd.
I don’t know. What’s the suggested proportion? 100% is trivially unreasonable, 1% would probably also be unreasonable because it’s not worth the hassle. There will be some value that both ECC and the community think is too high — but I’m not going to commit to a range, because I don’t have the authority to do that on behalf of ECC (and I don’t see why it is necessary).
No. That condition applies only to Bootstrap/ECC receiving funds via a hard-coded address (or equivalent) built in to the protocol, as I and @joshs have repeatedly said. Receiving funds via a sufficiently decentralized mechanism after (or before) that point is completely fine, and welcome. Josh’s post describes the kind of thing we mean by a decentralized mechanism (but it’s the goals that matter more than the technical detail, as long as the detail is consistent with the goals).
We’ve also argued for dev funding of other entities to be via a decentralized mechanism. For clarity, that is not a condition on our willingness to implement a proposal in zcashd, if it had community consensus and was reasonably implementable, etc.
Speaking for myself, I do think that hard-coding addresses in the protocol poses a significant regulatory risk, given recent legal decisions. (My reasoning here may be different to Josh’s, even though our conclusions are consistent.)