Summary
A proposal to introduce an automated boundary check for new Delegation operations to prevent Bakers from being forced into over-capacity by external actors.
The Problem
Bakers are currently manual “valves” for protocol overflow. When a large wallet or smart contract initiates a new delegation to a Baker near capacity, the protocol accepts it instantly, forcing rewards dilution and requiring the Baker to manually raise fees to correct the state.
Proposed Logic
Implement a simple logic gate for new delegation operations:
If (Current_Baker_Balance + Incoming_Balance) > 9x_Capacity: Reject_Operation
Benefit
- Protects the Community: Existing delegates aren’t penalised by a single large newcomer.
- Reduces Baker Friction: Bakers shouldn’t have to choose between “kicking a client while they’re down” (raising fees) or letting rewards collapse.
1 Like
What happens when the balance of a delegator increases?
3 Likes
Same as current, but that isn’t the problem this proposal is aiming to address. This is for new delegations.
1 Like
How about the same check for staking? I had considered throwing a similar proposal out there a couple of years ago regarding delegation, but didn’t think it would gain traction. At least with delegation, I have some control over that. Using tezpay config, I reduce or completely zero out over-delegators’ balances.I don’t like to raise fees on existing delegators. If I can’t notify the over-delegators through conventional means, I send them an NFT. Obviously with staking, no such control over the rewards. If a total reject of a delegation or staking is not possible, at least a warning?
1 Like
This proposal can, and probably should, be adjusted to suit other needs, it’s moreso just the general idea/underlying principle issue of stop letting NEW delegates/stakers put a Baker over-capacity I was wanting to bring to light.
Yes there’s issues about “what if someone tops up their current staking/delegating balance etc."
But one problem at a time.
