Looks solid to me.

- I would check for global_id in case the same validators operate in another network
- Doesn't seem to prevent duplicate signature counting

I don't mind sending signature proof on to lite client, though it's probably more gas-efficient to verify it separately within transaction checker?

Reply on `Mad Otter Feb 7 at 15:52`
>> - Doesn't seem to prevent duplicate signature counting
No, key of `signatures` and `storage::active_validators` is

```
int node_id =
string_hash(
begin_cell()
.store_uint(0xc6b41348, 32)
.store_uint(pub_key, 256)
.end_cell()
.begin_parse()
);
```
So, no duplicates

In lite-client contract on `new_key_block` message you save all validators and `total_weight`. But we should take first `main` validators and calculate their weight.

In lite-client contract on `check_block` message you don't check that the block corresponds to currently known epoch.

No handler for bounced messages in Transaction-checker smart-contract. Lite-client can throw an exception in case of invalid input data, etc. Also, Transaction-checker send messages with flag BOUNCEABLE to lite-client.

You go through all cells of `shard_account_blocks` to find tx in the block in transaction-checker. It's not good:
1) Attacker can get random cell from `shard_account_blocks` and you contracts say that it's valid transaction. But in reality, it's fork of aug hashmap,
2) It's pretty expensive.

Implemented basic functionality with a few security issues: no max_main_validators logic, no global_id check (minor). Full cell scan is used: insecure. No exotics (won't work for big blocks). Block as tx_proof(ok).

More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment