At submission, I was not aware of XCTOS and used full blocks for the implementation as workaround. Another issue in my submission is that it didn't protect against duplicate signatures. I created a repo that includes fixes for both issues at https://github.com/Jaapp-/trustless-bridge-challenge-amendments

From README: "this implementation uses full block data to avoid pruned branches"

"It seems to be impossible to work with proofs"


I think I saw some submission parse exotic cells manually.

You could for example use 'XCTOS' to convert exotic cell into slice and parse manually.

Instruction docs: https://docs.ton.org/v3/documentation/tvm/instructions#XCTOS

TACT snippet:

struct Struc {
sli: Slice;
flg: Bool;
}

asm fun prs(c: Cell): Struc { XCTOS }

Gas consumption in `findTrustedTransaction` function:
1) You iterate over all cells to find the transaction.
2) You calculate hash for slice: `slice.hash()`. Opcode HASHSU takes 526 units of gas. You should use `root.hash()`. Opcode HASHCU takes only 26 units of gas.
526 / 26 = 20 times!

Implemented basic functionality in Tact with some security issues: in lite-client main_validators part is not implemented, in tx-checker full cell scan is used (expensive and insecure). Funny way of parsing vaidator list.
More info on issues: https://contest.com/docs/TrustlessBridgeChallengeAssessment

1. Contest task implementation implies extensive research. While we neglect some issues which are either too deep or too insignificant, `max_main_validator` were mentioned in the task and this logic is considered as required.

2. Indeed, while 0b0111 check prevent from going somewhere inside tx, it doesn't make this search fully secure. Any parent cell that starts with 0b0111 prevents from search in child cells. In ShardAccountBlocks tree it may happen, for instance, if in one of HasMapAug, label will be encoded with hml_short$0 and Unary field will contain three 1's (in that case tx which happen to be deeper in the tree will be unprovable). Generally not being able to understand where exactly in block structure some data is found (and thus what it means) is a security flaw.

In function `parseValidatorDescMap` (that is called on new_key_block message) you parse validator set manually. You can use TVM opcodes. It's OK.
In that function you takes all validators but you should take only `main` validators and use only them in `validateSignatures` function.

https://github.com/ton-blockchain/ton/blob/master/crypto/block/mc-config.cpp#L1865

In `validateSignatures` function:
1)
```
let requiredWeight = self.validatorSet.total_weight * 2 / 3;
```
Here is rounding error. It's better to use DIVR opcode or `(self.validatorSet.total_weight * 2 + 2) / 3`.
2)
Your code:
```
return weight >= requiredWeight
```
If weight == requiredWeight than it's not ok.
https://github.com/ton-blockchain/ton/blob/master/crypto/block/check-proof.cpp#L659

In lite-client contract in function `check_block` you don't check that the testing block is from current epoch.