Closed ebma closed 1 year ago
Maybe using the substrate-primitives u256
for balances works better than using the u256
from ethnum. There is a related thread on stackexchange here.
Another problem might be that the solidity contract is passing some bytes that are mismatching our expected types (e.g. AccountId
) and that's why the contract traps.
I think to approach this problem it's probably best to try to log the input that the psp-22 functions receive as part of the cross-contract call from the Solidity contract and then act from there.
I think we can consider this ticket obsolete since we identified the issues about cross-contract calling.
It seems like PR #9 introduced some kind of regression in regards to cross-contract calling. At least I was able to properly receive the
name
of a deployed PSP-22 contract with thenameWithHex()
function of the solidity contract added in #11 before #9 was merged which does not seem to work anymore. We should try fixing that again.