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, but only surfaced because of polkadot-sdk issue #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. 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. 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.