# Renew GateSeal for the Withdrawal Queue and Validator Exit Bus Oracle **URL:** \ **Category:** Proposals\ **Created:** [April 4, 2024, 9:01am UTC](https://research.lido.fi/t/renew-gateseal-for-the-withdrawal-queue-and-validator-exit-bus-oracle/7081 "2024-04-04T09:01:03Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![TheDZhon](https://dub1.discourse-cdn.com/flex013/user_avatar/research.lido.fi/thedzhon/32/800_2.png) [@TheDZhon](https://research.lido.fi/u/TheDZhon)\ **Post date:** [April 4, 2024, 1:18pm UTC](https://research.lido.fi/t/renew-gateseal-for-the-withdrawal-queue-and-validator-exit-bus-oracle/7081/3 "2024-04-04T13:18:29Z")
Thank you for kicking off the process of the GateSeal renewal. Having such a power-limited but important one-time panic button is good to mitigate highly hypothetical still should be considered catastrophic events. > [@zuzu\_eeka](#): > > In that case, leaving the protocol the option to react faster-than-governance-flow seem to be a good call. In the future, committee-driven safety mechanics could be changed to a permissionless zk-proof system. Still, that future is quite far away: it requires both the maturing of production-level zk-based tech and the ossification of withdrawals part of the Lido on Ethereum. I expect that for this to happen, it would require having not only a zk-proof system, but its complete formal verification on the level of bytecode and no more changes, e.g., for EVM itself, which is hard to guess when happens. Therefore, to me, prolonging the GateSeal protection would be wise and prudent. --- _[View the full topic](https://research.lido.fi/t/renew-gateseal-for-the-withdrawal-queue-and-validator-exit-bus-oracle/7081)._