# Proposal: Implementing a Protocol-Level "No Vacancy" Logic for New Delegations
**URL:** https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085
**Category:** Research and Development
**Created:** [May 30, 2026, 9:08pm UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085 "2026-05-30T21:08:41Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@SilverFoxy34534](https://forum.tezosagora.org/u/SilverFoxy34534)
#### Post date: [May 30, 2026, 9:08pm UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085/1 "2026-05-30T21:08:41Z")
**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.
---
### Author:  [@RichAyotte](https://forum.tezosagora.org/u/RichAyotte)
#### Post date: [May 31, 2026, 11:13am UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085/2 "2026-05-31T11:13:03Z")
What happens when the balance of a delegator increases?
---
### Author:  [@SilverFoxy34534](https://forum.tezosagora.org/u/SilverFoxy34534)
#### Post date: [June 4, 2026, 11:19am UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085/3 "2026-06-04T11:19:11Z")
Same as current, but that isn’t the problem this proposal is aiming to address. This is for new delegations.
---
### Author:  [@cardsfan7189](https://forum.tezosagora.org/u/cardsfan7189)
#### Post date: [June 6, 2026, 12:59am UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085/4 "2026-06-06T00:59:19Z")
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?
---
### Author:  [@SilverFoxy34534](https://forum.tezosagora.org/u/SilverFoxy34534)
#### Post date: [June 6, 2026, 8:45am UTC](https://forum.tezosagora.org/t/proposal-implementing-a-protocol-level-no-vacancy-logic-for-new-delegations/7085/5 "2026-06-06T08:45:49Z")
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.