I didn’t think you were proposing the pools be equal in size. This is indeed a lot simpler than what I had in mind. But I think probably best to start with a single baker and then hopefully use programmable staking when demand makes that problematic.
I just realized a missing piece of analysis.
Suppose there’s a pool with 1M tez. Roughly speaking, those who hold claims on the pool want to receive about 500 tez for 1 cycle. A baker wins the bid by offering 500 tez, but then immediately deposits 9M tez for a period of 1 cycle. In doing so, they reclaim 450 out of the 500 tez they bid and they still get to bake for the full 10M. If the baker doesn’t have 9M lying around, they can partner with someone.
The defense against this is that baking rewards should not accrue to deposit made after the bid is won. This somewhat complicates matters and maybe that was the source of @cwgoes’ earlier concern.
One option would be to require deposits to be held for one cycle before being added to the pool but that considerably impacts usability.
1 Like
What if bids include amounts and when won are transferred to separate contracts? This would also remove bias against smaller bakers. Downside would be the need to fix delegation time in order to avoid increasingly fragmenting the pool.
I’m not sure it helps. I think at this point we need to formalize it and take care of the exact timing of the auction, etc. There is also the issue of people withdrawing and depositing right around the 16 possible snapshot times.
One arrow in the quiver is charging about 2.5 bps for deposits and for withdrawals, enough to make it unappealing to try and grab one cycle’s worth of baking reward.
Perhaps…
Say there’s 1M tez in the pool and 900k ztez oustanding*. Baker bids 500 tez, there’s now 1,000,500 tez and 900k ztez. Baker then deposits 9M tez, there is 10,000,500 tez in the pool and he receives 900,000 / 1,000,500 * 9,000,000 = 8,095,952 ztez. There are now 10,000,500 tez in the pool and 8,995,952 ztez outstanding.
Before the next baker bids, the 8,095,952 ztez are withdrawn, but at this point, the pool is treated as having only 10,000,000 tez and not 10,000,500. Thus, 8,095,952 * 10,000,000 / 8,995,952 = 8999550 tez are withdrawn, that’s the original 9 million minus 450 tez.
The 500 tez bid only counts towards withdrawals after the next bid happens. In essence, this is the same as charging one cycle’s worth of baking rights for withdrawals, as the contract will always be one cycle late. Currently this is around 0.05%, a very modest amount, and it subsidizes not jumping in and out of the pool which is generally desirable for privacy.
I think this works… but at this point this needs a formal proof or at least a proof in LaTeX.
To succinctly formulate the proposition: an ascending bid auction takes place during a cycle and ends on the last block of the cycle. The baker’s bid accrues to the pool at the conclusion of the following auction. So if a baker bids during cycle n, the bid accrues to the pool at the end of the last block of cycle n+1.
(*) 1,000,000/900,000 ~ 1.065^(20/12), that’s how the peg might move over roughly 20 months assuming bakers pay about 6.5% annually to the pool.
