BlockHeaderRegistry

[pmlambert]

@leonprou I believe I'm supposed to sync up with you to figure out exactly how to structure the runtime logic for the changes. Everything works here, I just need to know exactly where you guys want to go with this feature. For example, who can submit signatures for which blocks (are cycles important), can validators submit signatures for multiple blocks at the same height, how many blocks should be confirmed before submitting the signatures, etc.

[sirpy]

• contracts should not be here, they are irrelevant to the fuseapp
• what are all the changes to fuseapp files not related to the bridge?
• you are missing unit tests for the fuseapp bridge part, it is part of the bounty requirements
• By default fuse+ethereum+bsc are always enabled no matter if they are in the list or not

@pmlambert you missed the comment above

You are still not handling errors correctly in the .subscribe, better extract the whole .subscribe callback to a function

[pmlambert]

1. contracts should not be here, they are irrelevant to the fuseapp Deleted
2. what are all the changes to fuseapp files not related to the bridge? From using rebase, has been fixed
3. you are missing unit tests for the fuseapp bridge part, it is part of the bounty requirements That is step 3, this is for parts 1 and 2
4. By default fuse+ethereum+bsc are always enabled no matter if they are in the list or not Changed to use env keys ETH,BSC _RPC

[sirpy]

1. contracts should not be here, they are irrelevant to the fuseapp Deleted
2. what are all the changes to fuseapp files not related to the bridge? From using rebase, has been fixed
3. you are missing unit tests for the fuseapp bridge part, it is part of the bounty requirements That is step 3, this is for parts 1 and 2
4. By default fuse+ethereum+bsc are always enabled no matter if they are in the list or not Changed to use env keys ETH,BSC _RPC

Every step has its own requirement for unit tests. you can check the bounty and check boxes again for each step.