Why destination chain not execute proposal once threshold met?

[livelybug]

Hello,

I am reading the doc Transfer Flow --> As Destination Chain(https://chainbridge.chainsafe.io/chains/ethereum/#as-destination-chain).

I have a question about the flow.
Once a destination chain has met some vote threshold for a proposal, why doesn’t the chain execute the proposal immediately?
It would save the relayers' gas fee of calling executeDeposit.

Thank you

[roethke]

Hi @livelybug, thanks for your question. Are you suggesting that the contract itself perform the action to execute the proposal rather than the relayer?

[livelybug]

Hi @livelybug, thanks for your question. Are you suggesting that the contract itself perform the action to execute the proposal rather than the relayer?

Hi, Thanks for your response. Yes, that's exactly my suggestion. Is the suggestion viable for the chainbridge project? Is there any security concern about it? Thanks

[roethke]

Unfortunately contracts need to be poked in order for actions to be taken. Because of this limitation, the relayer manages the invocation of contract methods such as executing a proposal to mint tokens on the destination chain.

[livelybug]

Notice the latest chainbridge-solidity already adopted MPC and removed voting logic.

My question is still about the voting logic and may be outdated

Tracing back to the commit right before the voting logic is removed, the proposal is executed once the threshold is met. which is upgraded from commit develop, where voteProposal and executeProposal were merged to be called by one tx instead of two.
So the doc(https://chainbridge.chainsafe.io/chains/ethereum/#as-destination-chain) is outdated by the code. The relayer only needs one tx in order for a proposal to be executed.
Feel free to correct me if wrong. Thanks

[roethke]

Chainbridge-solidity does not include MPC code; as of now, MPC is specific only to Sygma but yes, the chainbridge docs need to be updated in general.

In general though, the bridge contract would need to be watching for the event or state change in order to then execute the proposal, which cannot be managed without a third party software like a relayer watching for events and submitting txs to the bridge contract, though perhaps you knew as much already.

I hope this answers your question. If you have a Sygma-related question, feel free to open up an issue within either the sygma-relayer or the sygma-solidity repositories. We will be activating discussions functionality on those repositories shortly.

[livelybug]

Thank you, that does answer my question.