A Grand Compromise/Synthesis ZIP Proposal

[acityinohio]

EDIT: I made a significant rewrite to this proposal, adding a framework for deciding on ZF Grants funding, removing the shielded adoption metric, but keeping this version here and making the rewrite available below and updated the GitHub PR appropriately.

Before diving in, I want to make it abundantly clear that this is my personal proposal and in no way, shape, or form an official Zcash Foundation ZIP suggestion.

TL;DR: I try to put the best pieces of various proposals together. It sidesteps code complexity in implementation, funds the ECC/ZF, ECC stays a for-profit with restrictions, funds external parties through ZF Grants, ties some of the payouts to shielded adoption, all while carving out a limited-scoped opportunity for extending governance to more groups than the ECC/ZF.

During these past months, I’ve done my best to maintain neutrality during this discussion, and I hope readers view this post as I earnestly intend: A bridge between proposals, a compromise greater than the sum of its individual parts. One that keeps the ECC, the Foundation, and the community aligned on Zcash — not just Zcash today, but the ideal future of Zcash.

Despite the risk of wielding my “influence” or “power” to unduly change the course of the community’s discourse, I consider it a greater risk to stay silent. I hope this proposal is met in that spirit, and offers a viable path for the ECC, Zcash Foundation, and Zcash users at large.

Assumptions

Everyone makes assumptions when crafting a proposal. My assumptions are based on what I’ve teased out from the discussion on the community forums, Twitter, and private conversations, undoubtedly sprinkled with my own personal bias. I suspect they could form the basis of broad community consensus, but I won’t know until they’ve been posted, discussed, polled, and ultimately included (or not included) in software being developed by the Zcash Foundation and ECC and run by individuals in the community.

The fundamental assumption is that Zcash won’t thrive without a dev fund. I wish this wasn’t true (I really do), and for the longest time I was against the idea. But I’ve come to fear the alternative without one; I fear the privacy technology pioneered by Zcash may never reach its true potential — not just for our community, but for others interested in novel approaches to private money.

With that fundamental assumption out of the way, here are the others:

• The ECC and Zcash Foundation shouldn’t get a blank check; accountability is a prerequisite for any disbursement, based on the Foundation’s statement and other proposals being suggested.

• It’s possible for the ECC to remain a for-profit, but with (legally enforced) restrictions that ensure accountability and add teeth to their claim that no early investors are enriched by a new dev fund / no new investors are beneficiaries.

• Based on the ideas brought forward by Eran Tromer, a portion of the funds directed to the ECC / Zcash Foundation should be based on shielded adoption, which is the most pressing issue facing Zcash today and unlike many other metrics is both easily measurable and less likely to be gamed. (compared to a miner-signaling proposal for example)

• A nontrivial portion of the funds should be directed to users/orgs outside of the ECC/Zcash Foundation, and the ECC/Zcash Foundation should be in the minority in deciding how these funds are disbursed (e.g. through some process with broader input beyond ECC/Zcash Foundation employees, like a more constrained version of Placeholder or Blocktower’s “third party” proposal).

• The actual code changes for NU4 should be minimal and the “governance complexity” should be offloaded to legal agreements, not engineering hours. The dev fund would be deposited into a single address for the fund (ideally shielded with a viewing key) controlled through a trust (originally Andrew Miller’s idea), disbursed quarterly based on the accountability requirements and shielded adoption metrics described below. Trustees will be mutually agreed upon by the ECC and Zcash Foundation.

• The gross amount of the dev fund should still be 20% of the block reward, and it should end in 4 years. (Unless we go through another process like this one to extend it, though I personally hope we don’t)

A word on the enigmatic “third party” floating around

With all due respect to the proposers behind some variant of a “2-of-3 multisig” decision-making process for all disbursement decisions: I think this is a bad idea. To quote a previous forum post of mine:

…2-of-3 multisig [is] better if we find the right third party. That in and of itself requires an additional process/mutual agreement between the three parties (which is much more difficult than a bilateral agreement), and as I’ve mentioned before in presentations in the past, 2-of-2 with known entities dedicated to Zcash is better than jumping straight to 2-of-3 with a third party hastily decided or staying with 1-of-1 entity trademarks and software development processes.

As for why 2-of-2 is still strictly better than 1-of-1: in the case of cryptocurrency governance, I believe that inaction in the case of disagreement is a better outcome than one party unilaterally exercising power.

More to the point, I worry that the “third party” in question is being idolized into some Platonic ideal, and in reality either the ECC or the Zcash Foundation would spend a great deal of their time currying favor in either the process or selection of the party in question in the limited time between now and that party’s selection. Given that the Zcash Foundation is charged with representing community interests, I’m not sure why another community-focused representative would really make sense from the ECC’s perspective — they’d be constantly outvoted if interests clashed, so from a balance of power perspective I’m not sure why the ECC finds would find that tenable. And I’m not sure the community would want the “third party” to be another profit-generating enterprise, like a VC or another startup, which would tip power another way.

The crux of this proposal still centers around the idea that the Zcash Foundation and ECC share responsibility for protocol development, and assumes an eventual 2-of-2 agreement on the trademark and that both continue developing consensus-compatible node software that interacts with the Zcash network. But it mandates accountability for disbursement of funds to the ECC/Zcash Foundation, and expands outside stakeholder input on funds that wouldn’t be earmarked for the ECC/Zcash Foundation (similar to Placeholder’s earlier version of their proposal), while it doesn’t preclude the possibility of migrating to broader “2-of-3” later on.

Why a trust?

The main reason: reducing complexity creep in consensus code so the ECC and Zcash Foundation can budget for other features in NU4. Rather than try to incorporate some complex mechanism for dev fund disbursements on-chain, we can meet the NU4 deadline with the simplest possible code-change and spend more time ironing out the details of the trust “off-chain.” Since both the ECC and the Zcash Foundation are based in the US, using a trust with well-specified criteria for disbursements is a reasonable path. This also fits in nicely with lex-node’s proposal for legal covenants on funding.

The details

Upon NU4 activation, 20% of the mining reward (post-Blossom/post-halvening = 0.625 ZEC per block) would go to a single shielded address with a view key widely distributed and known to the community and controlled by a trust established by the ECC and Zcash Foundation. Every 105,000 blocks (a quarter of the year) until 1,680,000 blocks after activation (the next halvening), the trust would disburse funds the following way, requiring a public report with every disbursement:

• 4% to the ECC, assuming they meet the accountability requirements set by the trust/described below

• 4% to the Zcash Foundation, assuming they meet the accountability requirements set by the trust/described below

• Up to an additional 4% to the ECC proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply over the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

• Up to an additional 4% to the Zcash Foundation proportionally based on average amount of shielded value (scaled to 80% shielded as “fully shielded”) over total supply for the last 105,000 blocks, with the remainder held in escrow until Zcash is “fully shielded” for at least a month

• 4% to the Zcash Foundation as a RESTRICTED donation (Nonprofit Restricted Funds) purely for disbursement through ZF Grants, with additional restrictions and stipulations described below

Might be easier to see how this shakes out with actual numbers: 0.625ZEC * 105000 = 65625 ZEC accrued in the trust every quarter. For the first quarter/simplicity’s sake, let’s assume that 20% of the total value was shielded on average and that both the ECC and Zcash Foundation met the accountability requirements set by the trust. Then disbursements would look like this:

• 13125 ZEC to the ECC for meeting accountability requirements

• 13125 ZEC to the Zcash Foundation for meeting accountability requirements

• 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the ECC for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the ECC.

• 13125 * minimum(0.2,0.8)/0.8 (80% considered “fully shielded”) shielded adoption = 3281.25 additional ZEC to the Zcash Foundation for shielded adoption. 9843.75 ZEC would be held in escrow by the trust until Zcash is “fully shielded” whereupon the balance will be disbursed to the Zcash Foundation.

• 13125 ZEC to ZF Grants to be disbursed to external individuals and organizations (via the Zcash Foundation as a restricted donation)

The trust’s accountability requirements

Here I’m borrowing from the Foundation’s guidance but adding some stipulations to cement the Foundation’s independence, prevent the Foundation from hoarding its endowment, and handle the ECC as a for-profit. Before disbursing funds each quarter, the trust would need to validate that both the ECC and Zcash Foundation:

• Published a quarterly tech roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand

• (if beginning of calendar year) Published a yearly review of organization performance, along the lines of our “State of the Zcash Foundation” report

For the Zcash Foundation, the trust would further require:

• No board member may have an interest in the ECC (current board members with an interest would need to divest of their ECC holdings prior to the beginning of this dev fund)

• Excluding money restricted for ZF Grants, the Foundation’s total assets must stay below $100mm (if its assets ever exceeded this amount from a disbursement, the trust could direct the funds toward an additional restricted ZF Grants donation) [Edit: added this to prevent the Foundation from excessively hoarding its endowment and ensure funds are circulated to other parties…I seriously cannot imagine a world where the Foundation would need more than that]

Additionally, for the ECC, the trust would need to validate the following before each disbursement:

• (if the beginning of fiscal year) Published yearly audited financial statements at the same level of detail as a public company (to mirror the Foundation’s Form 990 requirement as 501(c)(3))

• No outside investment was received while they are obligatory recipients of this dev fund

• No portion of the dev fund went to dividends, profit-sharing, or share/equity buybacks while they are obligatory recipients of this dev fund

• No portion of the dev fund went into speculative investments in other companies while they are obligatory recipients of this dev fund

• No dilution of ECC’s equity except in the case of options/RSUs for new/existing employees while they are obligatory recipients of this dev fund

• There’s no change-of-control (majority control changes) at the ECC while they are obligatory recipients of this dev fund

The ECC must share necessary information with the trust to ascertain no violations of the above, but the information itself (i.e. cap table and detailed financials) should remain private between the ECC and the trustees unless there is a violation that is not cured.

The shielded adoption metric

I applaud @tromer’s suggestion for tying some portion of the dev fund to shielded adoption. It’s a great tool for adding a protocol-verified accountability metric and I hope it’s considered in many of the other proposals as well. My particular adaptation of it provides for some floor of funding for both the ECC and Zcash Foundation, while providing a variable payout based on shielded uptake (scaled to 80% as “fully shielded” to incorporate the possibility of lost value in transparent balances and protect against a single entity holding veto power against shielded uptake). Rather than reward the remaining ZEC to miners — which could cause perverse behavior where miners might censor shielded transactions — the trust would hold the remaining ZEC in escrow, to be paid out to both organizations in lump sum upon reaching a “fully shielded” world during the next quarterly disbursement.

I define the “fully shielded” condition as follows: we have 35,000 sequential blocks where the shielded value pool is 80%+ shielded for that same time period. The bonus can be held until after the dev fund expires, though I certainly hope we’ll reach that condition before then.

What happens in the case of a violation

The violating party has 30 days to attempt to cure the violation (if it’s possible). If they cannot, future funds are forfeit and will be provably burned by the trust (this inspired by @amiller’s miner burn proposal). [Edit: removed burn per @mistfpga’s suggestion] If they cannot, future funds are redirected to ZF Grants via a restricted donation to the Zcash Foundation.

The ZF Grants portion

I was disappointed to see the Placeholder proposal migrate away from a separate fund with their suggested 2-of-3 structure — I think it’s an appropriate step to broadening stakeholder input and spreading more funding beyond the Foundation and ECC without risking our more conservative governance structure. And we already have a model in place to distribute those funds: the ZF Grants platform.

Another advantage (or disadvantage, depending on your perspective) of a 501(c)(3) is that donations can have restrictions placed on them by donors. I suggest that a portion of the dev fund goes to the Foundation but with the express (and restricted) purpose of being distributed via ZF Grants. The Foundation would continue to administer ZF Grants and distribute funds, but it wouldn’t be in charge of deciding where those funds go; instead, the trust can demand that the ZF Grants process expand its decision-making process and include broader input. In the discussions around the various “third party” proposals, some have suggested a 3-of-5 approach where the ECC and Zcash Foundation are in the minority; I think that structure would work well for these funds. It’s not the full dev fund so we are limiting the downside risk of selecting the “wrong” third parties, which also means we can give those third parties more voice (by making them outnumber the ECC/Zcash Foundation).

In terms of selecting those third parties, I don’t have a silver bullet…which is very much the issue with “third party” selection in general. However, I think the Foundation’s Board election last year was a pretty good model. One possibility is to have a more open community advisory panel next year and follow the same steps for those three seats, and rotate them yearly — perhaps eventually changing the vote to originate from the shielded pool instead of an advisory panel. Those grant reviewers would be charged with judging new grants and selecting RFPs on a weekly basis, and the Foundation would be charged with administering their decisions. The Foundation could also chose to fund ZF Grants beyond the restricted donations from the trust, but doing so would be at their discretion.

An attempt at compromise

I don’t know if this is at all appealing to anyone else but me, but I’d be remiss if I didn’t suggest it. There are scores of great ideas on the forums, and I took the (subjective, mind you) best parts of each into a proposal that hopefully meets the standards of the ECC, the Zcash Foundation, and the broader community. I sincerely hope you agree, but if not, I hope it opens other avenues for discussion that may bridge the gap.

If there is any interest in this proposal, I will convert it into a formal ZIP and open a PR by August 31st. Thanks to everyone for their consideration.

[tromer]

I really like the “diversified portfolio” approach of this proposal. It breaks the Dev Fund into 5 different portions, each with a different recipient or mechanism, that complement each other. In particular, the first 2 fifths ensure a stable baseline, while the last 3 create specific incentives and reduce centralization.

The Trust approach is promising. Indeed, if we cam make the disbursement rules simple, requiring little discretion and expertise, then it becomes easier to find a legal entity that can be trusted to execute them. A couple of notes, here:

• Some fixed USD amount should be reserved to compensate this entity.
• The funds earmarked for each funded entity can be locked under 2-out-of-2 multisig between that entity and the Trust, to mitigate the risk of the Trust absconding with the funds.

Regarding the two fifths tied to shielded adoption: I think the calibration of the parameters (making this be just 40% of the Dev Fund and defining 80% shielded as the target) is reasonable. It is fortunate that a major goal, shielded adoption, happens to have a simple and difficult-to-game metric… Some drawbacks are mentioned in my proposal and the later discussion, but this being just part of the Dev Fund mitigates those.

The release of a (potentially very large) lump sum of delayed funds, in the momen that “fully shielded” level has been sustained for a month, worries me a bit. I don’t immediately see how this can be gamed, but in general, large non-continuous payments tend to cause incentive distortions and tax issues.

More generally, tax issues need to be carefully considered. Receipt of dev fund ZEC, or its sale in order to create a USD reserve (matching USD liabilities), may be taxed – both at the level of the Trust or of the funded entities.

The Grants fifth is the most complex one, and may require the Trust to exercise considerable discretion, taking us partially back towards the “enigmatic” (dare I say “mythological”?) third-party. But at least it’s just a fifth of the total dev fund, so imperfection is less consequential. In any case this needs more fleshing out.

Using the “restricted donation” mechanism is a neat hack. It invokes a well-established legal mechanism, enforced by the Internal Revenue Service, to ensure proper custody of these funds by the Zcash Foundation, while relieving the Trust of the need to be cognizant of the technical particulars of individual grants.

As discussed elsewhere, I suggest to specify 2-out-of-2 control of the Zcash trademark as a condition for funding.

[tromer]

By the way, implementing “disburse according to shielded adoption” rules within the consensus mechanism is pretty straightforward; I believe we already have most of the requisite accounting infrastructure, as part of the turnstile implementation. But yes, if a Trust is needed anyway, for the other accountability aspects, then might as well use it for this too, and keep things simple for the protocol consensus layer.

[Anton1]

I am for this offer! I believe that this is exactly what you need to do from the very beginning, from the proposal, for my part, maybe there are 2 more proposals from the community that I can vote for, the percentage of deduction is important (here it is 20% which I don’t really like), but taking into account the current price per month there will already be not enough to develop even this deduction, in the future, if you accumulate funds, if it becomes possible, with the consent of all parties, it will be possible to revise the percentage of deductions, but first you need to decide the areas of costs and funds management, along with the parties’ responsibility for you Op wrong path.

[dlubarov]

How do you anticipate that the shielded adoption bonus might affect the ECC’s or ZF’s work? It seems like there could be some adverse effects, like

• It might lead to an aggressive plan to deprecate t-addresses, such as quickly dropping support for [un]shielded → unshielded transactions. Arguably that would be a good thing, but it’s possible to be too aggressive, and ideally financial incentives shouldn’t be part of the equation.
• It might encourage the use of SNARK-friendly hashes and PRFs, which would make shielded transactions more practical, particularly on mobile. Again there’s a clear benefit, but it needs to be weighed against the risks of using newer primitives.
• It might discourage projects like CODA-style succinct verification, since that would make shielded transactions much more expensive to generate (at least if using MNT curves like CODA).
• It might discourage projects like proof of stake and sharding, since they’re neutral with respect to shielding. Maybe that’s intentional, but to me scalability seems as important as shielded adoption.

I’m being cynical here by assuming that the ECC’s and ZF’s behavior would be driven by their financial incentives. But if that wasn’t the case, then it seems like the bonus wouldn’t have much effect one way or the other.

[mistfpga]

Hi,

Thanks for putting this forward. Please do create a zip out of it.

Just some thoughts.

20% over the next halving

This grants an extra 10% of the total supply to these organisations. I am not very well versed in inflation and I am not 100% sure I can even defend this argument, but I see a lot of people saying that the initial FR caused massive inflation and sell pressure issues. Wont this make the situation worse?

no early investors are enriched by a new dev fund

Doesnt the whole concept of burn do this? I know this isnt your direct intent with this statement, however it could do with some clarification.

Published a quarterly tech roadmap reports and financial reports, detailing spending levels/burn rate and cash/ZEC on hand

I know I have yet to define it properly but couldnt burn, just be rolling burn? especially with it being a single trust, that at the block height for the next halvening, any funds “burnt” are redistributed as block rewards, giving a second chance at donation. However this doesnt really work with fixed number percentages or without a true opt-out mechanism. it only works with sliding burn amounts.

In the case you have stated could “burn” mean that if the ECC dont meet their obligations then the ‘initial contract’ is enforced for those zec rather than taking them out of circulation forever? so they get redistributed via mining.

This type of system would be much harder for miners to game. because it relies on the ECC’s performance.

No outside investment was received while they are obligatory recipients of this dev fund

Could you please expand on what you mean by this? it seems overly restrictive and I cant really see a reason why. Wouldn’t it make more sense to make sure the funds are spent on development whilst letting the company expand into new verticals. This would hopefully alleviate the need to have this conversation again in 4 years.

cheers,

[mika]

I’m actually shocked by this proposal.

@acityinohio

The gross amount of the dev fund should still be 20% of the block reward

The overall amount of the dev fund is the most controversial discussed subject. The proposed amounts range from 0% to 20%. Setting it to 20% is clearly not a compromise.

Furthermore, the proposal secures 60% of the overall dev fund for the Zfnd, which is a huge redistribution of funds from ECC towards Zfnd compared to the current situation. This will most likely slow down the development considerably.

The shielded adoption part, like it’s described in this proposal, encourages miners to censor shielded transactions in order to reduce inflation. This might lead to a situation where shielded transaction won’t be processed at all.

[boxalex]

@mika

I’m actually shocked by this proposal.

Me too for several more resons and not only these you mentioned, to which i personally fully agree of course.

It’s amazing to see what the head of ECC comes up with (no trademark multisig) and the head of the ZF (this proposal).
It’s sad to see how far you guys are away from the community but pretend to represent the community…

[mika]

@boxalex

Me too for several more resons and not only these you mentioned, to which i personally fully agree of course.

It’s amazing to see what the head of ECC comes up with (no trademark multisig) and the head of the ZF (this proposal).
It’s sad to see how far you guys are away from the community but pretend to represent the community…

Well, Zookos reaction is quite understandable.
Just look at the aggressive expansion strategy of the Zfnd. It’s all visible and written down in this proposal. Furthermore, all this is getting really frightening if you look at the carefully chosen title of this proposal, with a clearly visible intention and the timing at which this proposal was published. Finally, given this, it makes perfectly sense why the Zfnd is taking a position against the introduction of a 3rd party in the decision making process.

[zooko]

Thank you for writing this! What a thoughtful proposal. I hope the community will consider it carefully.

[secparam]

I think the amount of the dev fund is open to discussion. We should view these things as a template for what the dev fund would look like. IMHO, this proposal specifies a number of useful and concrete mechanisms that are viable even if the amount is changed.

Also, note Josh intended this as a synthesis of the proposals. It is the case that most of the proposals go for 20%. So picking that number (if only for illustrative purposes) makes sense.

[secparam]

I don’t think power grab is remotely accurate. Decentralization necessarily means some power moves away from the incumbent. That was why Zooko was on board with creating ZFND. Moreover, ZFND has intentionally and explicitly discouraged themselves from being the sole dev fund recipient. It’s not trying to replace ECC. In a world where there are currently only two credible orgs, a two way split is the only thing you can do.

I agree we should be careful. If there was a credible and trusted third entity that ZFND was arguing shouldn’t be given power, then you would certainly have a point. But there isn’t a third entity nor a plan for creating them. And that’s all Josh is saying.

Speaking purely for myself, if at some point such an entity does come to exist or even there’s a specific credible plan for it, it is worth restarting the idea. We all want this to be as decentralized as reasonable.

[sgp]

While I like the shielded incentive in some ways, it would also reward behaviors that could be irrelevant to the agency’s actions. For example, suppose Coinbase independently decides to change its policy and stores all funds in the fully-shielded pool. While this is good for the ecosystem, it may not reflect the ECC or ZF’s efforts directly. It’s important that any incentives are based on actions that are 1) good for the ecosystem, and 2) clearly tied to the entity’s efforts.

[tromer]

@secparam

Decentralization necessarily means some power moves away from the incumbent. That was why Zooko was on board with creating ZFND.

To be fair, it’s even more than that: Zooko strongly advocated for creation of Zfnd, and he personally pledged and made a huge irrevocable donation to Zfnd. He also raised many of the ideas for sharing/transferring power to Zfnd, some of which (like the ZIP process) are already in place. Zooko and ECC have consistently strived for decentralization and power-sharing from the get go, and acted on this goal in very substantial ways.

[secparam]

Actually @sgp that would be good for zcash
Hear me out. For Coinbase to do that, ECC, ZFND, or someone would have to support custody solutions for shielded. Threshold signatures, etc. Thats meaningful progress. Though not as start as say shielded by default ubiquitous mobile wallets. It is a positive consequence of the incentive.

[tromer]

@sgp

While I like the shielded incentive in some ways, it would also reward behaviors that could be irrelevant to the agency’s actions. For example, suppose Coinbase independently decides to change its policy and stores all funds in the fully-shielded pool.

We are at a point where it would take significant development for such third-party migrations to happen: adding shielded multisignatures to the protocol, developing shielded hardware wallets, solving zcashd performance bottlenecks, etc.

So yes, major exchanges moving their reserves to z-addresses would be a huge win that points to important work having been completed by ECC and/or Zfnd, and it’s worthwhile to incentivize.

[mika]

I really encourage the community to pay attention to this comment.

@secparam

I don’t think power grab is remotely accurate.

If you do some calculations you’ll see that this proposal secures the Zfnd 60% of the dev fund. In the case where the shielded value pool is below 20% - the effective income split between the ECC and Zfnd amounts to 35.8% for ECC and 64,2% for Zfnd.

@secparam

Decentralization necessarily means some power moves away from the incumbent.

Given the numbers above it becomes obvious what decentralization/some power moves actually means for the Zfnd.

[Shawn]

@mika Ian is on the board of the Zcash Foundation so this statement is important:

@secparam

I think the amount of the dev fund is open to discussion. We should view these things as a template for what the dev fund would look like. IMHO, this proposal specifies a number of useful and concrete mechanisms that are viable even if the amount is changed.

[tromer]

@mika

this proposal secures the Zfnd 60% of the dev fund

This is inaccurate. Only 20% of the dev fund is “secured” to Zfnd (and even that is subject to the accountability requirements). Another 20% is conditioned on shielded adoption, which is likely to happen in the long term, so let’s make it 40% total earmarked for Zfnd for its own discretionary expenses (subject to its legal charter and accountability, of course).

The other 20% is constrained by the “restricted donation” mechanism and, while disbursed via the Zfnd-administered grants system (because this is what we have in place), explicitly cannot be used by Zfnd for its own expenses.

There’s some gray area here, in that Zfnd may encourage some activities to happen as external grants rather than undertaking them as in-house work. But I think this is exactly the kind of decentralization we are trying to encourage.

[mika]

Right, that’s how the 60% are set up.
Especially given your own description of the grey area.