# BEEFY Issue - `mmr_generateProof` returns previous blocks validator set information for mandatory blocks.

Here is an update on the beefy issue so far after yesterdays meeting with W3F.

## The Issue with `mmr_generateProof`

There is a bug with generating mmr proofs for mandatory blocks which needs to be patched by Parity. The bug is that there is no way to generate an MMR proof with the correct next validator set information for the first commitment (mandatory commitment) of a session. The `mmr_generateProof` RPC returns the current validator set as the next validator set for the first commitment in the session. This has always been a bug that was introduced [substrate issue #11797](https://github.com/paritytech/substrate/issues/11797), but only surfaced because of [polkadot-sdk issue #3003](https://github.com/paritytech/polkadot-sdk/issues/3003) where the beefy validators restarted and did not produce any commitments between mandatory commitments. Under normal operating conditions our relayer would pick up any other commitment after the mandatory commitment and process correctly, hiding this issue.

## Recovering the Rococo-Sepolia Bridge

The bridge is bricked in the Rococo to Sepolia direction. This leaves us with 2 options for recovery described below. We have decided to try option `2` and if that takes too long revert to option `1`.
1. Re-initializing the bridge. This will require an update to the Rococo BridgeHub runtime to allow nonces to be reset to zero(an extra storage key in the safe call filter). This will also optionally require us to clear any assets in AssetHub. We can then redeploy our contracts with a newly initialized BeefyClient.
2. Recovery by crafting a signed commitment for any block after the first mandatory commitment(block `8810808`) and before the next mandatory commitment(block `8810707`). This requires us getting 2/3rds of validators from that session (validator set id `15086`) to sign an MMR root for any block in that period. We can then write a script or a relayer sub-command to submit this commitment to unblock the light client. This depends on waiting for validators to come to the party and sign a MMR root for us which is not fully in our control. Parity will need to assist with this.

## Escape hatch to recover from this in production

We discussed an escape hatch for the beefy light client. This still needs to be researched a bit.
1. The validations in our light client around checking that validator set ids increment can be relaxed. W3F believes this is not buying us any extra layers of security as it is safe to trust the validators known to the light client as they can be slashed. This will allow us import any MMR root into our light client provided it is signed by the currently known validator set.
2. We only need to validate that block numbers increase(move forward in time). This will restrict the light client to not accepting MMR roots from the past, i.e. old MMR roots.
3. If a majority of the validators from the light clients currently known validator set are in the relaychains current validator set then we can reconstruct validator proofs in the relayer, allowing us to accept a recent MMR proof from a different validator set id.