I don't quite understand the issue. If the concern is that we might skip an intermediate key block and register a later one instead, this is not a problem given the system's design. We store only the latest key block, not a chain of blocks, and anyone can register new key blocks.

The contract stores the seqno of the epoch start and cannot receive a seqno of the current epoch that is lower than the stored one.

Could you clarify the issue in more detail?

Your argument is valid. However, in practice, it does not introduce a new security risk.
If we assume that 2/3 of the validators in a given epoch can collude, then the system is already compromised, regardless of whether they attempt to validate an invalid block for the next epoch or their own. The key point is that such a scenario already breaks trust in the network, making the specific validation check for prev_key_block_seqno non-essential.
In other words, while skipping this check theoretically allows for an attack vector, it does not create an additional risk beyond the fundamental problem of assuming a 2/3 validator collusion, which is a critical failure in any case.
However, the issue is accepted.

The concern about a "fork of aug hashmap" is incorrect. Cryptographically, it is impossible to construct a different transaction that produces the same hash as a fork of the augmented hashmap.

The purpose of a hash is to serve as a cryptographic commitment to the data, allowing verification without checking every field explicitly.

The check guarantees that the provided transaction hash exists in the verified block. Even if an attacker submits the hash of a forked augmented hashmap instead of a transaction, it gives them no advantage. Since referencing a non-transaction hash has no practical effect, this additional check does not add any real security benefit.
I intentionally skipped some checks to save gas.

The `proof` structure is described at the beginning of the `tx-checker.ts` file.

Thanks for the review!
Regarding this concern:
"If the top-1 validator didn't sign, the block won't be accepted."

This is not actually the case. The logic does not depend on any specific validator signing. Instead, it iterates over all validators from the config and accumulates the signed weights.
If a high-weight validator does not sign, a "false" flag is set for them, and in the contract, their weight is considered zero. This ensures that missing a high-weight validator does not prevфent the block from being accepted, as long as enough other validators sign.

As for:
"Checking on proofs for tx_checker is quite complicated, seems like attempt of implementation of shard transaction checks introduce security issues."

Yes, this is indeed an implementation of shard transaction checks.