I want to boost this idea from @murbard to add a “virtual baker” to the protocol that contracts can point at and be allocated rewards, either directly or by holding a token. It’s an alternative to my idea where bakers bid on pools of tez, which I’ve come to call “conventioning”, as a solution to opportunity cost from baking in DeFi contracts. This is an issue for building strong anonymity sets with Sapling, for Dexter where (unlike on Ethereum) fees paid to liquidity providers compete with baking rewards, and in systems involving delegated SNARK proving (e.g. Coda’s “snarketplace” — this is technically possible with Sapling, although the feature won’t be exposed in Tezos).

I’ve come to believe the virtual baker is the better solution because it takes the burden off of contract developers and because it doesn’t require security proofs like conventioning. However, it’s not without its own challenges, including developing an efficient implementation and the fact that it requires a protocol upgrade.

Also note there’s a lot of crossover between the ctez approach described below and Trustless Staking Tokens or “TST”.

There is a potential way to address the problem of making tez easily available in defi applications without deploying complex machinery to provide it with a baker. It is a somewhat ugly and hackish though. The idea would be to create a “virtual baker” inside the protocol, that automatically pays rewards every cycle to its delegates. The question becomes: how much reward exactly? The virtual baker by itself has no clue about the typical amount of rewards retained by bakers. If it only matches inflation, there’s a chance it will be too stingy given that not everyone delegates. If it matches the rate of solo baking, it’s likely to undercut bakers and attract all delegation, thus killing the incentive to carefully pick bakers. The solution is to target a fraction of the rolls, say between 15 and 25%. If 15% of the rolls or less are delegated to the virtual baker, the virtual baker pays the reward from solo-baking. If 25% of the rolls or more are delegated to the virtual baker, the virtual baker pays nothing. The reward is adjusted linearly between 15% and 25%. This ensures that the system reaches some sort of equilibrium with the rest of the bakers. The virtual baker cannot aggressively undercut bakers (or it would attract more than 25% of delegation) but it cannot leave too much on the table either (or it would attract a lot less). There are important drawbacks to this technique. the 15%-25% figure is pulled out nowhere. If it turns out to be too low, then the problem of dealing with the baking rights of tez collateral in smart-contracts will remain. If it turns out to be too high, then it will disrupt baking by magnifying the impact of delegation on governance and block creation rights. A naïve implementation would spend time O(n) adjusting balances which might work today but would not be future proof. This would require a careful implementation with lazy balance updates which is not trivial to do. The main benefit is that this is minimally disruptive to the chain. All smart-contracts would have to do is point to the virtual baker and receive decent block rewards, but not as attractive as baking directly or even delegating directly.