Skip to main content

Sign data

Data signatures are commonly used for login verification, authorization statements, order confirmations and off-chain protocol interactions. UKey Wallet will use the current account private key to generate a signature after the user confirms, and the DApp is responsible for demonstrating a clear signature purpose and completing signature verification on the server or contract side.

Use UKey Wallet to initiate signature​

If you need a runnable example, please refer to js-eth-personal-sign-examples.

For signature encoding and verification tools, please refer to eth-sig-util.

Signature method selection​

UKey Wallet supports multiple Ethereum signing methods. In production environments, methods that have clear semantics, are understandable to users, and are not prone to abuse should be preferred:

  • eth_sign (DEPRECATED, unsafe)
  • personal_sign
  • signTypedData (currently the same as signTypedData_v1)
  • signTypedData_v1
  • signTypedData_v3
  • signTypedData_v4

Different signature methods have different security attributes, and you cannot just look at whether they can generate a signature.

eth_sign allows the signing of arbitrary hashes. The signature content lacks clear context and risks being disguised as other authorizations or transactions. Therefore it is not advised for use in production environments.

If legacy systems do rely on eth_sign, please only use it in a controlled environment and clearly state the signing risks on the interface.

personal_sign will add the Ethereum signed-message prefix to the message, reducing the risk of the signature being interpreted as a transaction. It is suitable for login, terms confirmation, one-time nonce challenge and other scenarios.

If the signature needs to be verified by the contract at low cost, use EIP-712 structured data signature.

EIP-712 has multiple versions during its evolution, so it is very important to include the version number in the method name. For compatibility reasons, use eth_signTypedData_v4 first.

Sign Typed Data v1​

This was an early form of structured signatures and lacked some of the security and expressiveness improvements of subsequent versions. Unless compatibility with old systems is required, it is not advised to use it first.

There are several major design considerations for the signTypedData series:

  • Reduce on-chain signature verification costs.
  • Let users see fields that are more readable than the original hash.
  • Reduce the risk of signature misappropriation through domain and type structures.

If only new projects are connected, please evaluate v4 directly.

Sign Typed Data v3​

signTypedData_v3 is a more mature version of EIP-712, suitable for scenarios that require structured display and on-chain signature verification.

If the signature data contains arrays or more complex structures, use v4.

When verifying the signature on the contract side, please ensure that the coding logic of domain, type, and message is completely consistent with the front-end.

Sign Typed Data v4​

signTypedData_v4 is the current preferred EIP-712 method, supports arrays and fixes critical issues in struct encoding.

If there are no special compatibility requirements for new projects, eth_signTypedData_v4 will be used first.

Typed Data message inputs​

domain: Used to limit the valid scope of the signature, usually including application name, version, chain ID, verification contract and other information. Its functions include:

  • Make the signature only valid in the specified application, contract or network.
  • Reduce the risk of signature conflicts or replays between different DApps.
  • Help users identify which application or contract the current signature belongs to.

chainId: Used to bind the network to which the signature belongs.

  • Testnet signatures cannot be misused for mainnet if the signature contains the correct chain ID.

name: Mainly used for users to identify the source of signatures.

  • If a user is using a DApp but another application name appears in the signature pop-up window, it should be considered a risk signal.

verifyingContract: Specifies the contract address for final verification of the signature, which is an important field to prevent confusion among applications with the same name.

  • Even if two applications use the same name, the contract address is different.
  • If there is no contract, other fields that can limit the validator can also be used according to the protocol design.

version: Indicates the domain version, suitable for distinguishing different signature formats during protocol upgrades.

message: business data subject. Fields are defined by the DApp itself, but should be kept as understandable as possible to avoid displaying only obscure numbers or hashes.

Below is an example of using UKey Wallet to sign typed data. More references can be found at here.

Reference snippet​