Closed polus-arcticus closed 2 months ago
This is happening because you are trying to sign the message using Alchemy's provider, and they never supported this flow properly (no idea why if to be honest)
This is happening because you are trying to sign the message using Alchemy's provider, and they never supported this flow properly (no idea why if to be honest)
Thanks for the prompt response, ill give it a try with moralis or infura.
https://community.infura.io/t/the-method-eth-signtypeddata-does-not-exist-is-not-available/3122/3
I may be running into this issue getting out of hardhat because it is no longer intercepting the eth_signedtypeddata_v4 eth rpc call. and since im in node and not the browser i dont have a wallet doing it for me either. For others crossing this issue, i'm seeing that if creating my own EIP-1193 provider might help me get around this, as for some reason the ethers JsonRpcSigner is not intercepting this rpc call like hardhat or metamask
@lbeder if interested
Writing my suggested change here https://github.com/polus-arcticus/eas-sdk/tree/feature/sign-without-special-provider . I dont think EAS should rely on specially made providers such as those created by metamask or hardhat to intercept eth_signtypeddata_v4 before it hits the rpc directly. In this branch it uses @metamask/eth-sig-util to sign the messages instead of asking the provider to do it
Writing my suggested change here https://github.com/polus-arcticus/eas-sdk/tree/feature/sign-without-special-provider . I dont think EAS should rely on specially made providers such as those created by metamask or hardhat to intercept eth_signtypeddata_v4 before it hits the rpc directly. In this branch it uses @metamask/eth-sig-util to sign the messages instead of asking the provider to do it
Some providers are indeed don't handle this great, but in general, it's still recommended to delegate this functionality to a signer, since it's ultimately the controlling the required keys. Other than Alchemy's, we never encountered any issues.
Some providers are indeed don't handle this great, but in general, it's still recommended to delegate this functionality to a signer, since it's ultimately the controlling the required keys. Other than Alchemy's, we never encountered any issues.
@lbeder Indeed, for base sepolia, i couldnt get any one i tried to work, Ankr, Moralis, Alchemy, Infura, after a while i gave up. Digging deeper, it was because i was not in the browser or in hardhat. Indeed, metamask and hardhat intercept requests to a provider for eth_signtypedata_v4. I expect 99% of users test and exist in these environments. But if one is looking to do this server side with autonomous agents they are out of luck. Perhaps extending the signer prototype with @metamask/eth-sig-util to keep the private key management on the web3.js/ethers/viem instance is the way to go
Yes, currently the SDK expects a signer that implements the signTypedData
function (https://github.com/ethereum-attestation-service/eas-sdk/blob/017ee207cf5b8dfbbfa4cd7f9988fba33a7891f0/src/offchain/typed-data-handler.ts#L17). You can overload or even provide a custom implementation for this function.
Hi im trying to use the signOffchainAttestation API
Its working well on hardhat tests forking mainnet, but i'm trying to do it in node against base sepolia i run into
where we see
i'm not sure where in the code its hitting the rpc url,
perhaps i need to write my own EIP-1193 compliant provider ?
thanks!