Why we need to keep config param 32 (List of validators from the previous key block):
The first key block in an epoch (starting key block) is signed by the previous epoch’s validators. We need to keep them to verify key block transactions if needed.

Why we need to keep config param 36 (List of validators from the next key block):
Transitioning key blocks introduce the next validator set. To ensure key block continuity, we must store them. Without this, the current validator set could manipulate the next set, compromising trustlessness.

We prune as much data as possible from key blocks, keeping our implementation gas-efficient (0.01 TON on testnet for submitting a new key block).

Agreed. It’s better to check msg.value to prevent this scenario.

Thanks for the comments. 
While only main validators usually sign blocks, verifying all valid signatures adds extra security without much gas overhead since we only process the signatures that are actually there. The code still enforces the 2/3 weight threshold, keeping all necessary security properties intact while staying adaptable to future protocol changes.
Also in order to get the main we need to sort them by their weights, which has more gas usage than only saving all of them and searching for the main ones through the 15 signatures we got.

We're verifying exactly what we need to - the block's cryptographic fingerprint (root_hash + file_hash) that validators actually sign. Checking the entire raw block would be redundant since these hashes already prove the block's authenticity and we are verifying the hashes before verifying the signatures.

Same answer

We're verifying a Merkle proof that connects the transaction to the block through the account blocks structure. When we check the transaction hash in the account block, we're following TON's transaction storage format where transactions are stored in account blocks as exotic cells with their hashes. Since we've already verified the Merkle proof leading to this account block, finding the matching hash proves the transaction is part of the block - that's how TON's blockchain structure works!
The key is that we're not just checking "some cell" - we're checking a verified path from block -> account blocks -> transaction hash.

Hello, thanks for the comments!

1) About the epoch check: Our main checks are based on seqno and the new current validator set. The time-based check was an extra security measure.

2) Could you elaborate more on the tx_checker issue? Since we stop when we reach a tx cell (an exotic cell at the highest level) and we don't check further so for example a msg cell in a tx will not be considered.

3) Tests are running properly. I’ve attached a screenshot of it.

1. We didn’t check that prev_keyblock_seqno matches the latest seqno in the contract. However, we verified that prev_validatorset matches curr_validatorset, covering both this check and an edge case.

If a new keyblock changes the validator set, transactions in that keyblock should be verified using the previous validator set. We save configParam32 to handle this edge case while ensuring continuity checks between keyblocks.

2. Right. It can be fixed by skipping non-pruned cells longer than 256 bits since keys are at most 256 bits, while transaction cells are longer.

3. Sounds good!

4. For keyblocks with an empty configParam32, we assume this doesn’t happen—there should always be a previous validator set. If documentation states otherwise, we’re happy to check, but under normal circumstances, we wouldn’t process such a keyblock.