yihuang

yeah, right now, the tls config is only used for the WebSocket server, not the HTTP json-rcp server.

but it still need to pay the fee, at least the gas used part?

Do you mean some `send_to_ethereum` request will revert at ethereum side, and it's treated as success at cronos side, thus the double spend risk?

The issue is there's no flow in gravity-bridge to handle the failure case on the ethereum side, but it could fail in reality, right?

I guess on a "normal" erc20 contract, it shouldn't fail, but if the token contract has some custom logic attached to the fund transfer process, then anything can happen.

yeah, I think you are right here. But I believe you can implement vesting logic in an EVM smart contract?

> There's a few advantages of using the native Cosmos's vesting accounts, for example: > > * Even though they cannot transfer coins to another account the owner of the...

it's fixed by upgrading to 0.46, and tested in https://github.com/crypto-org-chain/cronos/pull/648

Is this issue still relevant?

For private node, should not be an issue, for public node, one should limit batch size and apply rate limit in the reverse proxy server. we are also adding timeout...