Skip to content

fix: set signatureChainId in recover_user_from_user_signed_action - #312

Open
massimiliano1991 wants to merge 1 commit into
hyperliquid-dex:masterfrom
massimiliano1991:fix/recover-user-signed-signature-chain-id
Open

fix: set signatureChainId in recover_user_from_user_signed_action#312
massimiliano1991 wants to merge 1 commit into
hyperliquid-dex:masterfrom
massimiliano1991:fix/recover-user-signed-signature-chain-id

Conversation

@massimiliano1991

Copy link
Copy Markdown

Summary

recover_user_from_user_signed_action is the inverse of sign_user_signed_action, but the two are asymmetric:

  • sign_user_signed_action sets both signatureChainId and hyperliquidChain on the action before building the EIP-712 payload.
  • recover_user_from_user_signed_action sets only hyperliquidChain.

Because user_signed_payload reads action["signatureChainId"], recovering the signer from a freshly reconstructed action — the normal case for a verifier that never called sign_user_signed_action on that dict — raises KeyError: 'signatureChainId'.

Reproduction

from hyperliquid.utils.signing import (
    sign_usd_transfer_action, recover_user_from_user_signed_action, USD_SEND_SIGN_TYPES,
)
import eth_account

wallet = eth_account.Account.from_key("0x" + "01" * 32)  # any test key
action = {"destination": "0x0000000000000000000000000000000000000001", "amount": "1", "time": 1677777606040}

sig = sign_usd_transfer_action(wallet, dict(action), True)
recover_user_from_user_signed_action(dict(action), sig, USD_SEND_SIGN_TYPES, "HyperliquidTransaction:UsdSend", True)
# -> KeyError: 'signatureChainId'

Fix

Set signatureChainId in recover_user_from_user_signed_action symmetrically with sign_user_signed_action. Added a sign → recover round-trip regression test (mainnet + testnet) that asserts the recovered address equals the signer — the function previously had no test coverage, which is why this slipped through.

pytest tests/signing_test.py passes (14 tests).

Note on #267

This is orthogonal to #267 (which makes signatureChainId configurable in sign_user_signed_action). The fix here matches current master, where sign_user_signed_action hardcodes 0x66eee. If #267 lands, the recover side should stay in sync — ideally both sign and recover would share a single helper for the default so they can't drift apart again.

sign_user_signed_action sets both signatureChainId and hyperliquidChain on the
action, but recover_user_from_user_signed_action only set hyperliquidChain.
Since user_signed_payload reads action["signatureChainId"], recovering the
signer from a freshly reconstructed action raised KeyError: 'signatureChainId'.

Set signatureChainId symmetrically with sign_user_signed_action, and add a
sign -> recover round-trip regression test (the function had no coverage).

@koriyoshi2041 koriyoshi2041 left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Verified at a08ae6e761. A freshly reconstructed USD-send action fails with KeyError: 'signatureChainId' on master, while this restores the same EIP-712 domain input used by sign_user_signed_action; mainnet and testnet round trips recover the signer correctly. The full local suite passes (37/37) on Python 3.11, and git diff --check is clean.

The hardcoded value deliberately matches current master. If #267 later makes it configurable, both sign and recover paths will need to move together.

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.

2 participants