You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is a good practice on Starknet, for example, to use different popular standards like ERC20 for obvious reasons. But there are conflicts with the Cairo language.
E.g., the function names should be written in snake_case, while in Solidity (and the ERCs), we use camelCase. One way to resolve the issue is to duplicate the functions and create both snake_case and camelCase versions.
There can be other problems as well, and this can apply not only to Starknet.
Anyway, the point is that it is definitely not good to mention an ERC in the docs and contracts of a project and leave the question of compliance open.
So, I suggest thinking a little and coming up with some decisions on how to evaluate findings like the one above in the contests. Should we adhere to the existing rules (which is understandable because the project explicitly mentions the ERCs) or apply less strict ones (which can be technically justified)?
The text was updated successfully, but these errors were encountered:
See the discussion below this finding:
code-423n4/2024-01-opus-findings#17
It is a good practice on Starknet, for example, to use different popular standards like ERC20 for obvious reasons. But there are conflicts with the Cairo language.
E.g., the function names should be written in
snake_case
, while in Solidity (and the ERCs), we usecamelCase
. One way to resolve the issue is to duplicate the functions and create bothsnake_case
andcamelCase
versions.There can be other problems as well, and this can apply not only to Starknet.
Anyway, the point is that it is definitely not good to mention an ERC in the docs and contracts of a project and leave the question of compliance open.
So, I suggest thinking a little and coming up with some decisions on how to evaluate findings like the one above in the contests. Should we adhere to the existing rules (which is understandable because the project explicitly mentions the ERCs) or apply less strict ones (which can be technically justified)?
The text was updated successfully, but these errors were encountered: