It would, though I’m less enthused about a cap now considering a few things
It implies centralized fund disbursement of all MG funds by the ZF, rather than through direct payments and a network upgrade.
The ZF can adjust grants every period, so if an MG or the ECC gets too much, there’s recourse. This is less so the case with the ECC with their minimum allocation though, which is why I’d originally discriminated between the ECC and MG in ZIP 1011 [edit by @daira to correct ZIP number]
An uncapped allocation can be treated sort of like startup equity, which has a long track record of incentivizing early employees. If we get an allocation, I love the idea of being able to directly allocate parts of an MG to early contributors- it will make finding the best talent for the job easier, and keep them aligned.
I do, however, like that caps enforce a certain fiscal discipline.
It also bears mention that we’re turning the ZF into a big ol’ honeypot if it’s directly handling payments for all of these people. Op/sec will need to be high-grade exchange level.
Unclear. It seems complicated and there could be unintended consequences that we would need to think through, including accounting, operational security risks, regulatory and legal risks, tax consequences, etc., in addition to the financial planning questions about whether this structure would enable us to execute to purpose. If this is the structure that the community signals their preference for, then we’ll evaluate it to determine whether we would be able to take that role. That evaluation will take time (and money, since we are using several of the world’s best lawyers in these fields to advise us on these matters, and that is expensive).
In the meantime, my answer is that I currently don’t know if we would be able to take that role.
I’m confused. The compromise above doesn’t add any complexity to the original ZIP 1012 proposal, or ZF’s revised version. It just exempts half the coins from the Volatility Reserve terms (so you can promise fixed ZEC amounts to employees, and know that you can fulfill this obligation regardless of ZECUSD).
Are you saying that all of these “unintended consequences […] including accounting, operational security risks, regulatory and legal risks, tax consequences, etc.” exist in addition to the points you made in today’s blog post? And you haven’t evaluated or even raised these concerns in all of the time since the proposal was made and sentiments were collected?
Is the offer made exclusively for ECC? It just seems that if it’s not, it’s necessary to conduct a survey and take some form of it, but a lot can change over the coming year. Alternatively, ECC can reduce salaries by 2-4 times for the possibility of continuing to work, if the market continues to fall, this will be a good offer for a world-class team that, like many others, will be looking for work.
My compromised applies to everyone: ECC, ZF, and (indirectly) the grantees. This is discussed in more detail above.
It just seems that if it’s not, it’s necessary to conduct a survey and take some form of it,
Yes, this kind of change is substantial enough that IMO it would need to be explicitly approved by another sentiment-collection poll (which is planned anyway).
Added: This decision will apply to the whole 4-year duration of the Dev Fund.
Eran, we need time to look at this thoughtfully. I currently don’t understand how it would be implemented in terms of consensus protocol, key management, operational security, legal, and accounting, much less the knock-on consequences in terms of financial, accounting, regulatory and legal risks, etc that could make or break whether we would be able to fulfill our obligations under this plan. We have been studying the leading ZIPs ever since the community sentiment collection results, and our recent blog post contains our considered opinion, posted as fast as we could, after working on it day and night, informed by extensive legal counsel. If the community wants us to consider other ideas, we’re willing to do that, but it’ll take time.
FYI @mhluongo, the way the proposal is written the ECC and Zfnd would be self-regulating their own volatility reserves (enforced via social contract + transparency reports) so it’s not a central point of funding distribution except for the MG recipients. And I’m personally not a fan of those recipients being directly baked into the protocol, regardless of the decision-making body/process of those grants.
This doesn’t make sense to me. If the funding is capped in terms of some quantity of USD per unit time, how does an employee of the ECC, or an employee of a major grant recipient, benefit from the appreciated price of ZEC?
It seems the only way for people working on ZEC to benefit from the price of ZEC going up is to have at least some of their salary denominated in ZEC.
The goal is not to merely “connect employees with coin holders.” The goal is to align the incentives of coins holders and people working on ZEC.
We’re talking about between 25 and 40% of the dev funding, and the MG not being able to survive eg a regulatory issue tripping up the ZF. That’s a big exception.
The Network Upgrade Pipeline isn’t set in stone, and if changes are made to that schedule it would supremely complicate distribution for MG-recipients with different timelines. What do we do for MG recipients that have a 1 year grant, or 1.5 year grant, if the NUP shifts?
And that’s not even counting potential performance issues with grant recipients. Having a decision-making body decline future funding is one thing, but arranging a large-scale emergency hardfork to stop an underperforming grant is…terrible, in my view.
Ah. Variable grants. We appear to have very different mental models on how this might work. Going to re-read the ZIP.
Then don’t There are a bunch of assumptions packed in here. This is why I was so concerned with the “grant” nomenclature in the first place. In this case, we’re trading resilience to regulatory intervention for a “grant” that can be canceled at any time… assuming that’s a requirement. I don’t believe it is, and I’m not sure the grant analogy is doing us any favors this far in the discussion.
EDIT: To be clear, I’d never suggest a last-minute hard fork for something like that. The risks greatly outweigh the reward.
Concerning the type of currency, does the difference really extend beyond just a role reversal for payroll? E.g. Some Zec currently recieved is sold to pay employees USD and other ZEC to be vested VS. some USD recieved is payed to employees and some sold for ZEC to be vested?
Let me preface this by saying I’m personally borderline indifferent to the presence of a cap. In the Foundation’s original proposal a cap only existed on the Foundation’s endowment, but we had enough community pushback to scale back our changes and reintroduce the concept as it existed in Eran’s original ZIP 1012. Given that support — and the variety of other good reasons for the existence of this structure — I’m going to apply that lens to the ECC’s stated rationale for removing the cap. @joshs said the ECC’s main points could be summarized as follows:
Last point first; I routinely disagree with @secparam (as he’ll tell you) but I think this is worth highlighting:
I agree, this is not a Constitution and I find it strange (and potentially reckless) to suggest otherwise. It’s also only applicable for 4 years, so having USD feature prominently is eminently pragmatic. I’m sorry to say y’all but the Supremacy of the US Dollar will very likely continue until 2024. Probably longer. I can’t tell the future, but I can tell you that the Foundation will keep accounting for its costs in USD for the next 4 years, as I’m sure the ECC will.
I don’t intend to discount the superlative effort of the community in constructing and debating these proposals — which I’m very thankful for. But I also fear ascribing reverent-level governing lexicon to a document meant to describe a self-funding software process.
The first two points are effectively one point: ECC employees can’t ostensibly receive fixed ZEC for their efforts, and if they can’t their incentives are disconnected from coin holders.
But…can’t they, in this proposal? Why can’t the ECC incur a monthly cost for “future ZEC retention pool” that is not usable by the company, held in ZEC, then distributed to employees over their contract as part of their retention plan? According to the ECC’s most recent transparency report, roughly $375k is distributed every month for employee retention. Why can’t you earmark a similar percentage of a future dev fund, incur the cost now, then distribute fixed ZEC from that pool?
And keep in mind that the cap is not permanent either. As modified ZIP 1012 states:
The Funding Target may be changed only by unanimous agreement of ZF, ECC, and the majority vote of the Community Advisory Panel.
Can the ECC explain why that wouldn’t work @zooko?
That explanation notwithstanding, I do think it’s prudent to add a couple different Funding Target options in the Helios poll the Foundation will conduct, including an option to not have a cap at all.
Help me understand. I understand the current revised ZIP 1012 to be a strict $700k cap on ECC receipt. If the value of the aggregate amount of ZEC pledged for current (or future) allocations to employees exceeds 700k due to an increase in coin price (even for a short period of time), the company would not be able to meet its obligations because the value in excess of $700k would not be available from the company. Perhaps I’m missing your assertion.
As an aside, I believe incentive alignment is broader than financial upside which is why the first two bullets are decoupled and different.
There are a bunch of assumptions packed in here. This is why I was so concerned with the “grant” nomenclature in the first place. In this case, we’re trading resilience to regulatory intervention for a “grant” that can be canceled at any time… assuming that’s a requirement. I don’t believe it is, and I’m not sure the grant analogy is doing us any favors this far in the discussion.