Repository navigation
fix: preserve eip-7702 authorization yParity in serializeAuthorizationList - #5304
Merged
Merged
Conversation
…tionList` `serializeAuthorizationList` normalized every nonzero authorization `yParity` to 1. EIP-7702 permits any `y_parity` below 2**8 in an authorization tuple, so mainnet transactions with such tuples serialized to a different hash. A numeric `yParity` is now encoded as is. Fixes #5297 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_018xsBq1f9h7D6pGXhaZ2aJv
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: e98d1f5 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Merged
This was referenced Oct 26, 2026
jxom
added a commit
to wevm/ox
that referenced
this pull request
Oct 26, 2026
* fix: accept punycode top-level domains in `Siwe.createMessage` Ports wevm/viem#5299. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: preserve EIP-7702 authorization `yParity` above 1 in `Authorization` Ports wevm/viem#5304. EIP-7702 permits any `y_parity` below 2**8 in an authorization tuple. `Authorization.fromRpc`, `Authorization.fromTuple`, and `Authorization.toTuple` now read and encode it as is. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: bound authorization `yParity` to one byte and keep it in `Authorization.toRpc` `Authorization.fromRpc` and `Authorization.fromTuple` reject a `yParity` of 2**8 or more, which EIP-7702 forbids, with the same `Hex.IntegerOutOfRangeError` as `Authorization.toTuple`. `Authorization.toRpc` encodes `yParity` as is instead of through `Signature.toRpc`, which writes 0 or 1. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: keep the port in group 3 of `Siwe.domainRegex` The top-level domain alternation is non-capturing, so the capture groups of the exported regex stay as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: use a line comment for the private `assertYParity` helper `check:tsdoc` requires an `@example` in every JSDoc block, and the helper is not part of the public API. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * docs: name `Authorization.toRpc` in the authorization `yParity` changeset Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: bound authorization `yParity` to one byte in `Authorization.toRpc` `Authorization.toRpc` now rejects a `yParity` of 2**8 or more with the same `Hex.IntegerOutOfRangeError` as the other `Authorization` codecs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: check authorization `yParity` in `Authorization.toTuple` `Authorization.toTuple` encoded a `NaN` `yParity` as the zero parity. It now rejects any `yParity` that is not an integer from 0 to 255, like the other `Authorization` codecs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM --------- Co-authored-by: Claude <noreply@anthropic.com>
jxom
added a commit
to wevm/ox
that referenced
this pull request
Oct 26, 2026
* fix: accept punycode top-level domains in `Siwe.createMessage` Ports wevm/viem#5299. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: preserve EIP-7702 authorization `yParity` above 1 in `Authorization` Ports wevm/viem#5304. EIP-7702 permits any `y_parity` below 2**8 in an authorization tuple. `Authorization.fromRpc`, `Authorization.fromTuple`, and `Authorization.toTuple` now read and encode it as is, and the zod `Authorization` schemas accept an 8-bit `yParity`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: bound authorization `yParity` to one byte in `Authorization.fromRpc` and `Authorization.fromTuple` Both now reject a `yParity` of 2**8 or more, which EIP-7702 forbids, with the same `Hex.IntegerOutOfRangeError` as `Authorization.toTuple`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: keep the port in group 3 of `Siwe.domainRegex` The top-level domain alternation is non-capturing, so the capture groups of the exported regex stay as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: bound authorization `yParity` to one byte in `Authorization.toRpc` `Authorization.toRpc` now rejects a `yParity` of 2**8 or more with the same `Hex.IntegerOutOfRangeError` as the other `Authorization` codecs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM * fix: check authorization `yParity` in `Authorization.toTuple` `Authorization.toTuple` encoded a `NaN` `yParity` as the zero parity. It now rejects any `yParity` that is not an integer from 0 to 255, like the other `Authorization` codecs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VLjvB9RWejr3jdFDh3WjiM --------- Co-authored-by: Claude <noreply@anthropic.com>
jxom
added a commit
that referenced
this pull request
Nov 1, 2026
…in recovery (#5371) * fix: accept an EIP-7702 authorization `yParity` above 1 in `parseTransaction` `parseAuthorizationList` parsed each authorization signature with `parseEIP155Signature`, which throws `InvalidYParityError` for any `yParity` other than 0 or 1. EIP-7702 permits any `y_parity` below 2**8 in an authorization tuple, and #5304 made `serializeTransaction` keep such a value, so a transaction viem serializes, for example mainnet 0xaec84209...cb09 whose authorization has a `y_parity` of 28, could not be parsed back, and `recoverTransactionAddress` threw on it. An authorization `yParity` from 2 to 255 is now kept as is, with `r` and `s` padded as before. 0 and 1 parse as before, and 256 or more still throws. * fix: reject an EIP-7702 authorization `yParity` other than 0 or 1 in recovery With `parseTransaction` now keeping an authorization `yParity` from 2 to 255, a parsed `yParity` of 27 or 28 reached `recoverPublicKey`, which maps them to recovery bits 0 and 1 as legacy `v` values. A tuple the protocol skips therefore recovered a signer, and `verifyAuthorization` returned `true` for it. EIP-7702 recovers the authority with `y_parity` as the raw recovery id, so `recoverAuthorizationAddress` now throws `InvalidYParityError` for a `yParity` other than 0 or 1, and `verifyAuthorization` returns `false`. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01D3nmWhB4o7Zekbowt3QdXf --------- Co-authored-by: ecamli <107792368+erkancamli@users.noreply.github.com> Co-authored-by: Claude <noreply@anthropic.com>
This branch was successfully deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #5297
serializeAuthorizationListpassed each authorization's signature throughtoYParitySignatureArray, which normalizes any nonzeroyParityto1. EIP-7702 permits anyy_paritybelow 2**8 in an authorization tuple. A tuple that fails recovery is skipped and does not invalidate the transaction, so such transactions land on chain. Re-serializing one (for example, mainnet0xaec84209…cb09, whose authorization holdsyParity: 28) produced a different hash.A numeric authorization
yParityis now encoded as is. Everything else is unchanged:yParity0 and 1, thev-only fallback, unsigned tuples, and the transaction-level signature.Tests: a new
serializeTransactioncase rebuilds the mainnet transaction from the issue and matches the raw bytes frometh_getRawTransactionByHashand the on-chain hash. A newserializeAuthorizationListcase coversyParity: 28. Both fail without the change.For reviewers:
parseTransactionstill throwsInvalidYParityErrorfor authorizationyParityvalues other than 0 or 1, as the existinginvalid authorization list yParitytest asserts. Parsing this transaction's raw bytes therefore still throws. This PR leaves that as is. Changing it would mean accepting values below 2**8 and choosing whatvis for them.Generated by Claude Code