Skip to content

Conversation

@florrdv
Copy link
Contributor

@florrdv florrdv commented Apr 25, 2025

Pull Request Checklist


PR-Codex overview

This PR introduces a new method, toViemWalletClient, to the BaseAlchemySigner class, allowing for the adaptation of the signer to a viem WalletClient. It enhances interoperability with viem by providing options for transport and configuration.

Detailed summary

  • Added a new method toViemWalletClient to BaseAlchemySigner.
  • Method accepts options for transport and returns a WalletClient.
  • Implements a fallback transport for handling requests.
  • Supports signing messages and typed data through the viemAccount.
  • Provides example usage in the documentation comments.

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

@vercel
Copy link

vercel bot commented Apr 25, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
aa-sdk-site ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 28, 2025 11:11pm
aa-sdk-ui-demo ✅ Ready (Inspect) Visit Preview 💬 Add feedback Apr 28, 2025 11:11pm

@graphite-app
Copy link
Contributor

graphite-app bot commented Apr 25, 2025

How to use the Graphite Merge Queue

Add 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.

@florrdv florrdv marked this pull request as draft April 25, 2025 19:39
@github-actions
Copy link

github-actions bot commented Apr 25, 2025

🌿 Documentation Preview

Name Status Preview Updated (UTC)
Alchemy Docs ✅ Ready 🔗 Visit Preview Apr 28, 2025, 10:56 PM

@github-actions github-actions bot temporarily deployed to docs-preview April 25, 2025 19:39 Inactive
@github-actions github-actions bot temporarily deployed to docs-preview April 25, 2025 22:28 Inactive
Comment on lines +872 to +874
isHex(params[0])
? { message: { raw: params[0] } }
: { message: params[0] }
Copy link
Collaborator

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?

Copy link
Contributor

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

Copy link
Contributor

@dphilipson dphilipson Apr 28, 2025

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.

Copy link
Collaborator

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?

Copy link
Contributor

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]);
Copy link
Collaborator

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea +1

Copy link
Contributor

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

Copy link
Collaborator

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) {
Copy link
Contributor

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

Comment on lines +872 to +874
isHex(params[0])
? { message: { raw: params[0] } }
: { message: params[0] }
Copy link
Contributor

@dphilipson dphilipson Apr 28, 2025

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) {
Copy link
Contributor

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)?

@florrdv
Copy link
Contributor Author

florrdv commented Apr 30, 2025

Closing this for now because there's no immediate need to create EIP1193 viem wallet clients.

@florrdv florrdv closed this Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants