OneKey Docs
  • 👋GUIDE
    • Introduction
    • Web App Integration Developer
    • Hardware Integration Developer
    • External Contribution Guide
    • Common Terms
  • 🔮Connect To Software
    • Compatible with Metamask
      • detectEthereumProvider
    • Support Wallet Kit
      • Web3 Onboard
      • Rainbowkit
      • Aptos Wallet Adapter
      • Web3Modal
    • WebApp Connect OneKey
      • ETH
        • Provider API
        • RPC API
        • Accessing Accounts
        • Sending Transactions
        • Signing Data
      • BTC
        • Guide
        • API Reference
          • requestAccounts
          • getAccounts
          • getNetwork
          • switchNetwork
          • getPublicKey
          • getBalance
          • getInscriptions
          • sendBitcoin
          • sendInscription
          • signMessage
          • pushTx
          • signPsbt
          • signPsbts
          • pushPsbt
          • inscribeTransfer (Deprecated)
        • Event
      • Nostr
        • Guide
        • API Reference
          • getPublicKey
          • signEvent
          • signSchnorr
          • getRelays
          • nip04.encrypt
          • nip04.decrypt
        • Event
      • WebLN
        • Guide
        • API Reference
          • enable
          • getInfo
          • makeInvoice
          • sendPayment
          • signMessage
          • verifyMessage
          • lnurl
          • getBalance
        • Event
      • NEAR
        • Introduction
        • Integrating
          • Install the Provider SDK
          • Detecting the Provider
          • Establishing a Connection
          • Accessing Accounts
          • Detecting Provider Network
          • Watch Accounts & Network Status
          • Sending Transactions
            • Create Transaction
            • Sign and Send Transaction
            • Signing Transaction
          • Signing Messages
          • RPC API Calling
          • Debug Logging
          • Migrate from Near Web Wallet
        • Reference
          • API Reference
          • Trouble Shooting
        • Resources
          • Example & Demo
          • FAQ
      • SOLANA
        • Detecting the Provider
        • Establishing a Connection
        • Sending a Transaction
        • Signing a Message
    • Using WalletConnect
      • ETH
      • APTOS
        • Wallet Connect API
  • 📟Connect to Hardware
    • Hardware SDK
      • Started
      • Install SDK
      • Config Event
      • Common Params
      • Path Params
      • Error Code
      • API Reference
        • Basic API
          • Init SDK
          • Search Devices
          • Get Features
          • Get Passphrase State
          • Cancel Request
          • Response UI Event
        • Device API
          • deviceSupportFeatures
          • checkBridgeStatus
          • checkTransportRelease
          • checkFirmwareRelease
          • checkBLEFirmwareRelease
          • deviceChangePin
          • deviceReset
          • deviceSettings
          • deviceUpdateReboot
          • deviceVerify
          • deviceWipe
          • firmwareUpdate
        • Bitcoin & Bitcoin forks
          • btcGetAddress
          • btcGetPublicKey
          • btcSignMessage
          • btcSignTransaction
          • btcVerifyMessage
        • Ethereum & EVM
          • evmGetPublicKey
          • evmGetAddress
          • evmSignTransaction
          • evmSignTypedData
          • evmSignMessage
          • evmVerifyMessage
        • Algorand
          • algoGetAddress
          • algoSignTransaction
        • Aptos
          • aptosGetAddress
          • aptosGetPublicKey
          • aptosSignMessage
          • aptosSignTransaction
        • Alephium
          • alephiumGetAddress
          • alephiumSignMessage
          • alephiumSignTransaction
        • Cardano
          • cardanoGetAddress
          • cardanoGetPublicKey
          • cardanoSignMessage
          • cardanoSignTransaction
        • Conflux
          • confluxGetAddress
          • confluxSignMessage
          • confluxSignMessageCIP23
          • confluxSignTransaction
        • Cosmos
          • cosmosGetAddress
          • cosmosGetPublicKey
          • cosmosSignTransaction
        • Dynex
          • dnxGetAddress
          • dnxSignTransaction
        • FileCoin
          • filecoinGetAddress
          • filecoinSignTransaction
        • Kaspa
          • kaspaGetAddress
          • kaspaSignTransaction
        • Near
          • nearGetAddress
          • nearSignTransaction
        • Nervos
          • nervosGetAddress
          • nervosSignTransaction
        • Nostr
          • nostrGetPublicKey
          • nostrSignEvent
          • nostrSignSchnorr
          • nostrEncryptMessage
          • nostrDecryptMessage
        • NEM
          • nemGetAddress
          • nemSignTransaction
        • Nexa
          • nexaGetAddress
          • nexaSignTransaction
        • Polkadot
          • polkadotGetAddress
          • polkadotSignTransaction
        • Ripple
          • xrpGetAddress
          • xrpSignTransaction
        • Scdo
          • scdoGetAddress
          • scdoSignMessage
          • scdoSignTransaction
        • Solana
          • solGetAddress
          • solSignTransaction
        • Starcoin
          • startcoinGetAddress
          • starcoinGetPublicKey
          • starcoinSignMessage
          • starcoinSignTransaction
          • starcoinVerifyMessage
        • Stellar
          • stellarGetAddress
          • stellarSignTransaction
        • Sui
          • suiGetAddress
          • suiGetPublicKey
          • suiSignMessage
          • suiSignTransaction
        • Tron
          • tronGetAddress
          • tronSignMessage
          • tronSignTransaction
        • Ton
          • tonGetAddress
          • tonSignMessage
          • tonSignProof
      • Advanced
        • Passphrase
        • Common SDK Guide
        • Low-level transport plugin
        • OneKey Message Protocol
      • Tutorial: Get started with OneKey
    • Air Gap SDK
      • Started
      • Tutorial: Wallet Integration
      • API Reference
        • Basic API
          • CryptoHDkey
          • CryptoCoinInfo
          • CryptoKeypath
        • Ethereum & EVM
          • EthSignRequest
          • EthSignature
  • ⛳Best Practice
    • Registering Your Contract's Method Names
    • Registering Tokens with Users
    • Defining Your App's Icon
    • Migration from MetaMask
  • 🎨Logo Assets
  • 🧙Support
  • 🕹️Trouble Shooting
  • ❤️Contribute
Powered by GitBook
On this page
  • Signing Data with OneKey
  • A Brief History
  • Sign Typed Data v1
  • Sign Typed Data v3
  • Sign Typed Data v4

Was this helpful?

Edit on GitHub
  1. Connect To Software
  2. WebApp Connect OneKey
  3. ETH

Signing Data

PreviousSending TransactionsNextBTC

Last updated 1 year ago

Was this helpful?

Since OneKey makes cryptographic keys available to each user, websites can use these signatures for a variety of uses. Here are a few guides related to specific use cases:

Signing Data with OneKey

If you’d like to jump to some working signature examples, .

If you’d like to read our JavaScript implementations of these methods, they are all available in the npm package .

Note that OneKey supports signing transactions with Trezor and Ledger hardware wallets. These hardware wallets currently only support signing data using the personal_sign method. If you have trouble logging in to a website or dapp when using a Ledger or Trezor, the site may be requesting you sign data via an unsupported method, in which case we recommend using your standard OneKey account.

A Brief History

There are currently six signing methods in OneKey, and you might wonder the history of these methods. Studying the history of these methods has some lessons in it for the emergent lessons of decentralized standards emergence. Our current five methods are:

  • eth_sign (Deprecated, unsafety)

  • personal_sign

  • signTypedData (currently identical to signTypedData_v1)

  • signTypedData_v1

  • signTypedData_v3

  • signTypedData_v4

There are likely to be many more over time. When OneKey first started, the Provider API wasn’t designed to be exposed to untrusted websites, and so some considerations weren’t taken as seriously as they were later.

In particular, the method eth_sign is an open-ended signing method that allows signing an arbitrary hash, which means it can be used to sign transactions, or any other data, making it a dangerous phishing risk.

For this reason, we make this method show the most frightening possible message to the user, and generally discourage using this method in production. However, some applications (usually admin panels internal to teams) use this method for the sake of its ease of use, and so we have continued to support it for the sake of not breaking the workflows of active projects.

The strange part of EIP-712, and this decentralized standards ecosystem, is that the proposal changed several times while retaining the same EIP. This means what we initially implemented as signTypedData was the earliest proposed version, while other groups implemented later versions under the same method name.

To avoid compatibility issues between clients, we recommend using the hard-versioned method names signTypedData_v1 and signTypedData_v3. The missing v2 represents an intermediary design that was implemented by the Cipher browser, so that we have room to implement it if there is ever enough developer demand for it.

In the future, it may help to have method names include a hash of their exact proposal, since in a decentralized ecosystem, there is no absolute source of truth of what a given name should map to. Instead, we are forced to invent new patterns of collaboration, where we can drive forward and innovate, while simultaneously avoiding creating a brittle ecosystem by changing our meanings out from under the words.

I hope this has been a useful introduction to the history of our signing methods!

Sign Typed Data v1

The signTypedData family has a few major design considerations:

  • Cheap to verify on chain

  • Still somewhat human readable

  • Hard to phish signatures

If on-chain verifiability cost is a high priority for you, you might want to consider it.

Sign Typed Data v3

This does not mean it is perfect, and we do already have a v4 in prototype stage (which supports recursive structs and arrays), but we do intend to protect this namespace and keep it compatible going forwards.

Hopefully soon we will also have good examples for parsing method input into structs for verification on-chain (great contribution opportunity!)

Sign Typed Data v4

This does not mean it is perfect, and does not mean we will not eventually have a v5, but we do intend to protect this namespace and keep it compatible going forwards.

Hopefully soon we will also have good examples for parsing method input into structs for verification on-chain (great contribution opportunity!)

Sign Typed Data Message Parameters

domain: The Domain or domain signature is important because it:

  • Will only be accepted for a specific website/contract.

  • Makes sure signatures are valid only where they are intended to be valid.

  • Allows you have a unique contract that verifies the address.

  • This is a bunch of information that restricts where the signature is valid.

  • This is the domain of validity. Could be a contract, a url, ect.

  • What needs to be put in here specifically what the DApp tells you.

  • Makes sure your signature(s) don't collide with other signatures.

chainId: The chainId tell you what chain you're on and this is important because:

  • It makes sure signatures signed on Rinkeby are not valid on another chain, such as the Ethereum Main Net.

name: This is primarily for UX(User Experience) purposes.

  • For example, as a user, you're using an Ether Mail app and a dialog comes up for cryptokitties exchange, this would arouse suspicion due to what the name is on the signature.

verifyingContract: This is an extra layer of assurance. Even if two developers end up creating an app with the same name, they will never have the same contract address.(You can add another field salt but it's complete overkill and unnecessary)

  • If you are unsure of the name this will show the contract responsible for message verification.

  • This field will also take a url.

version: This tell you the current version of the domain object.

message: Completely open to what you would like the structure of it to be. Every field is optional.

Example

Eventually, the personal_sign was proposed, which added a prefix to the data so it could not impersonate transactions. We also made this method able to display human readable text when UTF-8 encoded, making it a popular choice for site logins.

However, the text-prefix made those signatures expensive to verify on-chain, and so with the help of the team and , the spec was written.

This early version of the spec lacked some later security improvements, and should generally be neglected in favor of .

The method signTypedData_v3 currently represents the latest version of the , making it the most secure method for signing cheap-to-verify data on-chain that we have yet.

The method signTypedData_v4 currently represents the latest version of the , with added support for arrays and with a breaking fix for the way structs are encoded.

Below is an example of signing typed data with OneKey. Reference

🔮
Authenticating websites
you can visit this repository
eth-sig-util
spec
0xProtocol
SpankChain
EIP-712
signTypedData_v3
EIP-712 spec
EIP-712 spec
here