Usage of uint256 for backward compatibility with EVM specifications introduces a lot of baggage; increasing storage costs, adding code complexity, and complicating contract interfaces. Given the number of applications that actually need uint256, it seems the costs outweigh the benefits.

Going forward, most assets in the starknet ecosystem will be starknet native assets, so maintaining backward compatibility with evm types provides only downside. I suggest the base implementation of ERC ports should prefer felt over uint256. Implementations could chose to maintain a compat variant which uses uint256.

See previous discussion here: OpenZeppelin/cairo-contracts#336

snake case is more typical for cairo code

Feature Request

A dedicated website with an at-a-glance overview of the SNIPs and their statuses would be amazing. See https://eips.ethereum.org/all for examples.

Codespell linter tool is very important for code and system quality, especially for enhancing docs readability.

So I want to add codespell linter workflow for CI.

Thank you very much.

The contact options in the readme are both dead links

Feature Request

Write an rss feed tracker which updates subscribers about status changes of any SNIPs.
If you're feeling spontaneous, write a twitter bot that does the same.

Raising this discussion again as it's been discussed a few times but OpenZeppelin has decided to use felt instead of felt* for tokenURI. Their reasoning is discussed here. This is problematic for the community as it means that no reasonable NFT with metadata can be used as the tokenURI limit of 31 characters is too small for even an IPFS URI

Other entities such as Aspect have also diverged from the OpenZeppelin Standard. Having discussed with the team at LootRealms, they will also face this issue.

Immutable X, out of necessity, has also diverged and created an ERC721 standard inspired by OpenZeppelin with a key divergence being the tokenURI. Immutable X provides this as a preset to the community: https://github.com/immutable/imx-starknet/blob/main/immutablex/starknet/token/erc721/presets/ERC721_Full.cairo

Having discussed with Martín Triay from OZ, his view was that they would rather wait for StarkNet to release Strings. This unknown date of string support causes issues for organizations wishing to move close to productionizing their apps.

Immutable X will be supporting the long-form Token URI represented using felt* as used in their preset. Immutable X also presents encoding and decoding implementation for the tokenURI:

We believe the community should align on enabling organizations to be successful as these organizations will drive users to StarkNet. For NFTs on StarkNet, this means enabling metadata through an extended tokenURI.

If this gets more than 10 Rocket reacts, I'll make a SIMP for it.

would like a standard for documentation, either documented in snip-4 or built directly into the cairo compiler

See the EIP landing page for comparison:
https://eips.ethereum.org/

• Improve the description of the stages and how they interact
• Indicate who the SNIP maintainers are
• Discuss how governance interacts with this process (updates which require mainnet contract changes likely require a vote)