Unable to create UserNameProofClaim about hub-monorepo HOT 6 CLOSED

Thank you! this led me to make a leap in fixing this. The initial problem was letting the wallet client pick the default chainId, which was optimism in my case. Obvious fix is setting the wallet client chainId to mainnet 🔥😅🔥

still not 100% done but getting there 🙌🏼

from hub-monorepo.

Yes so that was my initial problem. Difference between verifying contract chainId and the chainId that was set as default for walletClient.
I'm tracking the progress to fix this here: hero-org/herocast#146

from hub-monorepo.

is the error thrown by signTypedDataAsync? does signTypedDataAsync return a 0x${string} that you can use directly, without needing the toHex() call? I copied the domain, types and contract address from the hub-nodejs code and seems to be working for me

from hub-monorepo.

thanks @0x330a! I've tried your approach but still no luck. I've added it in a rename flow, so it's independent of account registration (see commit here: hero-org/herocast@750e3a0)

Still getting an Unknown RPC Error with this:

from hub-monorepo.

My implementation might be similar to what you're doing, although I had to call it out to a serverless function to do the fname API I think (I didn't actually try but I assumed there would be a cors issue from a react frontend)

https://github.com/0x330a-public/terminex/blob/master/src%2FNameEditor.tsx

The register name request just forwards that as a post to the fname transfer endpoint so the body should be the same, apologies for mess of code I'm not really a web/react dev but hopefully the code helps

from hub-monorepo.

Actually one fun thing I discovered was that certain wallets (MM) will sometimes not allow you to sign EIP-712 data if your current chainId for a connected session isn't the one that is the verifying contract's chainId. Not sure if that's happening on your end as well but could be something to keep in mind 😂

from hub-monorepo.