A felt based ERC20 token

It is indeed true that Cairo will evolve such that Uint256 could maybe be implemented at the language level…
Would anyone from Starkware have more insights on that?
Even though even if there is a natif support of Uint256 since the max felt is a fixed value it will still be less efficient (unless some magic happens ^^').


With the recent announcement of Cairo 1.0 and StarkWare’s plans for the language, which include improved syntax and features like integers, I think that waiting to see more detail is prudent. While this proposal highlights an issue to be addressed, I think that this is something that is best resolved at the language level. Further, other comments in this thread have indicated some circumstances where a felt will not be sufficient on its own. Those circumstances also need to be taken into account. I don’t agree with placing the responsibility on bridges to be the compatibility layer where this issue can be resolved, and may well be, by changes to Cairo itself.


What I think it’s missing here is compatibility with everything that lives outside chains, for which bridges cannot help much. What’s the plan for wallet adoption, web2 adoption, etc?

As mentioned above, a felt is “more compatible” than Uint256, because it’s a single numerical value whereas a Uint256 is a pair of two values which has to be converted to a single one.

Re: wallets - Julien from Argent expressed support above, so did Motty from Braavos in DM (but I don’t want to put words in his mouth).

I think there’s a reason every other big L2 in the space is not breaking EVM compatibility, but trying their best to be “the more compatible alternative” and we shouldn’t ignore it.

StarkNet already broke compatibility, for good reasons and with great rewards as a result. I agree with your suggestion that we might not want to call it “ERC20” then and improve a token standard further (many people reached out privately suggesting this).

I still believe the best solution (by far) is having a better Uint256 type at the language level, and I’d be interested to hear reasons against it.

I agree here as well, that might be an acceptable solution. As @davek mentioned, the situation might improve with Cairo 1.0, but I think that would only fix the developer experience issue. As @gaetbout writes, the primitive data type of Cairo is felt, which cannot represent 256 bit values, so it will always be cheaper to use felts than a composite type. At least that’s my understanding, would love it if someone from StarkWare or the Cairo team could chip in.


I don’t agree with this. Uint256 is a standard library type in the cairo language which can be easily converted to/from EVM’s uint256, whereas felt cannot. Underlying representation (aka “single value”) has nothing to do with compatibility.

I wouldn’t say there’s visible rewards for breaking compatibility, and if it’s just achieving ZKRU functionality, we’re seeing other rollups achieve that without breaking compatibility thus leveraging: existing devtooling, existing developers, existing frontends, existing wallets, long etc. Interested to hear other points in here, I’m sure there’s a few I can’t think of – although not sure if this thread is the right place for it.

Breaking compatibility in an interoperable world is not something we should celebrate and let alone augment, but something we should fix/amend. Maintaining compatibility reduces our need to amend for that lack of compatibility by adding complexity in critical infra as bridges or adapters.

I don’t think it has to do with DX but interoperability. Having a native uint256 type in cairo which smartly represents “single felt uint256” as, well, a single felt, would not just provide with the performance improvement we all agree it’s needed, but it will also maintain compatibility with existing systems (other chains, other contracts, frontends, tooling, monitoring scanners, etc).


Hey there, coming a bit late to the debate. I also fully support this initiative, compatibility with external world can be done in bridges and js/python libraries. The current implementation of Uint256 provided by Starkware adds too much complexity.

Pros with felt

  1. Math is way simpler to write and to read.
  2. Native type that can represent several solidity types. By using it more and moving away from Uint256, developers could build strong libraries to use them, and may discover new primitives.

Cons with Uint256

  1. For most computation, you need to convert Uint256 to felt, do your computation, convert back your results to Uint256.
  2. Management of negative numbers is tricky. Also, it doesn’t feel correct to use a Uint256 to represent negative numbers.
  3. Each project using Uint256 adds several lines of code per file to take into account edge cases that may never happen in the network. This doesn’t sound sane.

I think you missed the pros with uint256 and cons with felt ¯\_(ツ)_/¯

I think we all agree in that we want cheaper and more efficient tokens, the discussion is at which level we’re going to fix this (because breaking compatibility with no patches is no one’s option).

The question then is should we work around this at:

  • the application level
  • the bridge/adapter level
  • the language level

To me, unless unfeasible, the third option is by far the best (still waiting for arguments against it), since adding complexity at the application or bridge level is cumbersome and risky.



As for pros with Uint256, I don’t see any besides compatibility.
And the cons of using felt well… breaking the compatibility.

Solving it at the language level wouldn’t solve the fact that a felt cannot contain 256 bits of data and we would then always need to use 2 felts: 2*252=504 bits for which 246 would be useless.
If someone (with some insights about Cairo 1.0) could pop in to clarify this situation it would be very helpful and help close a part of the issue.

Solving it at the application would be very cumbersome as every application (and there will be a ton of them (I hope :smile:)) would have to deal with it.

And delegating it to a bridge could also create some problems indeed…
So my idea is to create a new “kind of app/token” that would just be a wrapper of token?
It would wrap an ERC20 standard EVM to ERC20 standard StarkNet.
We would have then the same as is already existing on other chains with ETH and wETH. Where some application only allow to deal with some wrapped tokens.

I hope someone can bring up more arguments in favor of Uint256 to broaden my view on the problem. But so far I don’t see any value (besides compatibility) in using Uint256.



Yes it would. The runtime can smartly decide whether to use one or two felts to represent a given uint256. So, unless there’s a value it cannot represent, it will mostly use one felt. But the interface remains.


Which when hitting the limit would use 2 felts and therefore leave quite a lot of bits unused.


just like a bool value today ¯\_(ツ)_/¯


This is a great discussion.

It seems to me that a good part of the issue described above is not a numerical one (2^251 vs 2^256), it’s an “coding comfort one” (3 simple lines of codes vs 5 complex ones).
This problem can be solved by making uint256 much easier to use when coding in Cairo. Cairo 1.0 should be a big step forward in that regard. More details coming soon(ish)


I personally actually don’t care too much about the inconvenience of using the Uint256 structs in the smart contracts. It’s more the complexity of the interface for web-devs and the increase in computational costs.

Imo a native Uint256 type would be the way to go…I remember that being part of the cairo roadmap.
It fixes the developer experience issues mentioned by milancermak and in most situations one should be able to split the uint256 into felts for optimized calculations.

If there is no native Uint256 type in sight then I would be hard pressed to agree with milancermak.


100% agree with @TotalPizza. Native Uint256 is the best of both worlds.


Just to be clear i don’t think the issue here is about DX but storage/costs.


It’s about both, see above.


100% in support
Lets not bring EVM technical baggage to StarkNet


It seems like Cairo 1.0 will significantly improve the developer experience of operating on uint256, which is great!
I think a remaining question is how much computational overhead does it impose? Handling uint256 increases complexity quite substantially with cairo today and presumably will still do so at the circuit level with cairo 1.0, even if the language abstracts some of it away. This is pretty hard for me to understand theoretically. Milan has provided some empirical benchmarks which shows it is quite substantial.

Would be really great if someone with a deeper understanding of the CairoVM could chime in on these aspects. Can we dismiss this concern as something that can be optimized at the compiler or does it have meaningful implications on the complexity of circuits?


As Cairo 1.0 will come with a new VM I feel like we don’t really have a choice other then wait for StarkWare to release the specs.
Before that we can just speculate.


Since we now have Cairo 1.0 visibility, should we consider it again?

From my point of view, u256 will be less risky and more convenient to be used in Cairo 1.0 for smart-contracts developers, however I don’t think it solves the following points:

  • web developer will still need to manage it as an array of 2 felts?
  • u256 storage will still be more expensive than native felt?

Also I’m not sure having 2 standards will be helpful for the ecosystem.


From the perspective of first principles, the more important question is whether Starknet still uses the ERC20 standard, the essence of ERC20 is designed based on EOA account, and starknet defaults to AA.