The contract has the withdraw functionality, the flow of which is to check the given proof and give money to the recipient user account. ETH side can add additional messages into the event (data will be part of the proof), and it will be contained in the same data field where the recipient account is stored. In regular cases, these strings should be separated with “:”, and the NEAR side should parse it well. In the current implementation, when proof from the byte array is parsed, it is casted to NEAR AccountId type where the symbol ‘:’ is not allowed. So in case the contract receives proof with this additional message - the contract will crash while trying to make AccountId type from this string.
The contract has the withdraw functionality, the flow of which is to check the given proof and give money to the recipient user account. ETH side can add additional messages into the event (data will be part of the proof), and it will be contained in the same data field where the recipient account is stored. In regular cases, these strings should be separated with “:”, and the NEAR side should parse it well. In the current implementation, when proof from the byte array is parsed, it is casted to NEAR
AccountId
type where the symbol ‘:’ is not allowed. So in case the contract receives proof with this additional message - the contract will crash while trying to makeAccountId
type from this string.