Replies: 1 comment
-
|
I believe that this was specific to something in wagmi but i was not around when this was changed, so I cant really help. @tmm any thoughts? |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello, I have been working around signed types/messages and have run into quite a perplexing situation. Right now, the declaration of
TypedDataDomainis:This is fine in most cases as there are not currently any chains with a large
chainId, however I think there may be a case to treat it as auint256like specified in EIP-712Right now, if you are working with signed types you will inevitably find yourself needing to declare the domain type like:
Again, we are still fine here. However, as you can see,
chainIdis a uint256 which means it should "really" be abigint(I think) like here https://github.com/wagmi-dev/abitype/blob/00dd694139d995a98b8994ed180e60bcbc5e2947/packages/abitype/src/utils.ts#L66-L75.I have been working on a library that automatically builds my entire stack, but
domainhere has sent me down a rabbit hole after building everything around the declaredTypedDataDomain. It's auint256, so I get abigintas my expected type in one piece, but then when it comes to signing my data, it expects a number. Obviously, I could just doas bigintbut this is spread everywhere throughout my codebase and is in multiple points: the database, API, etc.Thoughts? I saw it was updated in this commit originally, so maybe I am missing something?
In the end, I got past it with a super hacky fix, but still wonder why that was needed and if this is an issue others have experienced?
Is the expected fix to override the export as is suggested here?
Beta Was this translation helpful? Give feedback.
All reactions