assert_not_zero error when invoking transfer on the ERC20 contract

[agolajko]

Hey all thanks for all easily available contracts and tools, it's been fun building with these. However we've run into a small issue when looking to run the ERC20 contract on Starknet. Here's what we did:

• We deployed the ERC20 contract that was listed here to testnet from CLI
• We've minted some money to an account via Voyager (currently anyone call call the mint selector without needing a signature)
• Next we tried invoking the transfer command from an account contract (deploying the account and getting the correct hashes to work was a small project in itself but I think this part is working now). Here the ERC20 contract is rejecting the transfer with the following error: "code": "TRANSACTION_FAILED", "error_message": "Error at pc=0:6:\nGot an exception while executing a hint.\nCairo traceback (most recent call last):\nUnknown location (pc=0:879)\nUnknown location (pc=0:831)\n\nTraceback (most recent call last):\n File \"<hint0>\", line 3, in <module>\nAssertionError: assert_not_zero failed: 0 = 0.", "tx_id": 81809"code": "TRANSACTION_FAILED" "error_message": "Error at pc=0:6:\nGot an exception while executing a hint.\nCairo traceback (most recent call last):\nUnknown location (pc=0:879)\nUnknown location (pc=0:831)\n\nTraceback (most recent call last):\n File \"<hint0>\", line 3, in <module>\nAssertionError: assert_not_zero failed: 0 = 0.", "tx_id": 81809
• • The balance on the sending address is sufficient (the amount.low and amount.high values would also be non-zero after the transfer.), both the sender and receiver are non zero addresses so I am not sure what is causing the assert_not_zero error.
• Last, we were able to call both the mint and burn selectors from goerli.voyager.online as well as from CLI.
  We've been digging but haven't found the assert_not_zero error yet. Does anyone have suggestions on how to interpret this cryptic Cairo error message? Do you have suggestions for how we can interpret this error message in an actionable way? It reads like hieroglyphs to me right now.

[agolajko]

I found the error I think and it's as banal as expected. So Starknet represents numbers with the felt type, what this means is that when passing an base-10 integer or a hex integer the number will be converted to a felt. What we think is happening is that the conversion from base-10 and hex to felt are broken somehow, and hence when passing the same number via the base-10 or the hex route they are represented with a different felt. What this results in is if mint is called on the base-10 address and then you call balanceOf on both the base-10 and the hex address they will return return different results. We tried something similar with storing and printing both a base-10 and a hex, and this error didn't appear there. So perhaps this only happens when storing values in a @storagevar function?

[agolajko]

Adding an extra point onto this. When calling the balanceOf from the ERC-20 contract on address 0x10 and 16 they return the same value (meaning the both the base-16 and the base-10 values correspond to the same balance). However when calling balanceOf on a larger number (still within the values permitted by the size of felts) the base-10 and base-16 addresses return different values. Likely there is an overflow error somewhere but I haven't been able to find it yet

[martriay]

Thanks for reporting this with such detail. A few questions to better debug this:

• Can you share details on how are you passing these parameters? Are you using the CLI I understand.
• Can you reproduce this against a local network? (e.g. starknet-devnet)
• Can you share specific commands/numbers to reproduce the scenarios you've described?

[kelemeno]

@agolajko agolajko asked me to reply to you:

We think we found the bug (it is in Voyager.online), let me explain that first, and then answer your questions.

Since then we realized that the issue is on Voyager.online. We used their platform for a single mint, and to verify the account balance, and that was likely the cause of the whole issue. It seems Voyager.online cannot parse large hexes correctly, making large hexes equal to 1, both in the mint and getBalance calls, so it looks consistent. When looking at the transaction data, or when calling from the command line, the issue became visible. We have brought this issue up with the Voyager team: https://discord.com/channels/793094838509764618/912410047236149298/918850430308606073

Linking this back to our original problem, the result of this hex parsing error in Voyager was that we thought we were checking with getBalance on Voyager that the address had balance > 0, but then later when invoking transact from the command line, we called an account with 0 balance. This was the cause of the assert_not_zero error, which in retrospect was valid.

To specifically answer your questions: we found no issues when calling starknet from cli (so we could not reproduce the error on devnet), we included specific commands as pictures for the Voyager.online error with above linked Discord message, if that interest you.

[tomasz90]

I am experiancing the same or similar issue when transfering ERC20 or making swap. Tried many things to fix this but without result.
How can I perform such transactions???

[Naughty1905]

same here

[martriay]

if any of you share more details of your setup we could be able to point you up to the problem, if it's not similar/the same as this answer's