-
Notifications
You must be signed in to change notification settings - Fork 199
feat: viem wallet client conversion #1565
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
How to use the Graphite Merge QueueAdd the label graphite-merge-queue to this PR to add it to the merge queue. You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has enabled the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. |
🌿 Documentation Preview
|
| isHex(params[0]) | ||
| ? { message: { raw: params[0] } } | ||
| : { message: params[0] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be technically possible to sign ascii/utf characters that represent hex characters, and this conversion prevents that by re-interpreting the characters to their raw value if they happen to be hex characters.
I think viem defaults to having the parameters to personal_sign be either a string or an object containing a field called raw - could we continue to use that type here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's what the check here is already doing no? Passing raw if hex so that it doesn't get treated as string
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, Adam's saying that this makes it impossible to sign the string "0x1234" because it will get interpreted as bytes 0x12, 0x34. (Or not impossible, but someone would need to pass the hex encoding of the above string, i.e. "0x307831323334"). Adam's saying that the caller should be responsible for specifying whether their string should be interpreted as hex rather than us trying to infer it.
But actually I think it's wrong to accept the type with raw here too. This code is trying to emulate the personal_sign method of the eth-jsonrpc API, and therefore should always interpret the input as hex (Metamask's docs). Getting non-hex input here should be an error.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good catch. So the real fix here is to just throw an error instead of handling the case of { message: params[0] }, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think so.
| : { message: params[0] } | ||
| ); | ||
| case "eth_signTypedData_v4": | ||
| return viemAccount.signTypedData(params[1]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we assert params[0] to be the account address?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yea +1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And probs same above checking that params[1] is the signer too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
params[1] is the typed data object, so I don't think there's anything we can assert over that.
| account: viemAccount, | ||
| transport: custom({ | ||
| async request({ method, params }) { | ||
| switch (method) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also eth_sendTx should be handled here as well which should call sign tx then submit it
| isHex(params[0]) | ||
| ? { message: { raw: params[0] } } | ||
| : { message: params[0] } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, Adam's saying that this makes it impossible to sign the string "0x1234" because it will get interpreted as bytes 0x12, 0x34. (Or not impossible, but someone would need to pass the hex encoding of the above string, i.e. "0x307831323334"). Adam's saying that the caller should be responsible for specifying whether their string should be interpreted as hex rather than us trying to infer it.
But actually I think it's wrong to accept the type with raw here too. This code is trying to emulate the personal_sign method of the eth-jsonrpc API, and therefore should always interpret the input as hex (Metamask's docs). Getting non-hex input here should be an error.
| account: viemAccount, | ||
| transport: custom({ | ||
| async request({ method, params }) { | ||
| switch (method) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: do we also want to implement eth_requestAccounts (Metamask's docs)?
|
Closing this for now because there's no immediate need to create EIP1193 viem wallet clients. |
Pull Request Checklist
yarn test)sitefolder, and guidelines for updating/adding docs can be found in the contribution guide)feat!: breaking change)yarn lint:check) and fix any issues? (yarn lint:write)PR-Codex overview
This PR introduces a new method,
toViemWalletClient, to theBaseAlchemySignerclass, allowing for the adaptation of the signer to aviemWalletClient. It enhances interoperability withviemby providing options for transport and configuration.Detailed summary
toViemWalletClienttoBaseAlchemySigner.WalletClient.viemAccount.