I see some issues with the function mint inside mintable-fungible-token in the NEAR side.
This function receives as a parameter a proof that contains relevant information of an event that took place on Ethereum side, and relevant tokens are locked, so they can be safely minted in the NEAR side. The strategy to avoid double mints are storing all proofs in the state, and checking no repeated proof is stored.
This approach has a clear drawback, which is that state might blow up, just from usage by legitimate users.
Inside the mint function, the first step is calling record_proof. This means, that any proof that is submitted, disregarding if it is correct or not, will be stored inside the contract. I think we should only store valid proofs, with valid merkle-roots from the Ethereum blockchain.
Malicious user can prevent another user to mint its tokens if it call mint with an invalid proof. In this case the mint call will fail, but before failing, will store mint information with record_proof inside the contract, so it won't be able to call it again.
I see some issues with the function
mint
insidemintable-fungible-token
in the NEAR side.This function receives as a parameter a proof that contains relevant information of an event that took place on Ethereum side, and relevant tokens are locked, so they can be safely minted in the NEAR side. The strategy to avoid double mints are storing all proofs in the state, and checking no repeated proof is stored.
mint
function, the first step is callingrecord_proof
. This means, that any proof that is submitted, disregarding if it is correct or not, will be stored inside the contract. I think we should only store valid proofs, with valid merkle-roots from the Ethereum blockchain.record_proof
inside the contract, so it won't be able to call it again.