Hydro
  • Getting Started
  • Raindrop
    • Raindrop Overview
    • Client Side Raindrop
      • Client-Side Raindrop Overview
      • Handling User Signatures
      • Recognizing Users
      • User Account Management
        • Check if Username is Taken
        • Creating HydroIDs
        • Creating HydroIDs (delegated)
        • Deleting Users
      • Verifying signatures
    • Server Side Raindrop
  • Snowflake
    • Snowflake Overview
      • Setting Up Snowflake
      • Naming Conventions
      • Handling User Signatures
    • Address Management
      • Adding Addresses
      • Removing Addresses
    • Provider Management
      • Add Providers
      • Upgrade Providers
    • Resolver Management
      • Adding Resolvers
      • Adding Resolvers (delegated)
      • Removing Resolvers
    • Allowances in Snowflake
      • User Hydro Balances and the Allowance Structure
      • Allowance management logic
      • Setting Initial DApp Allowances
      • Changing DApp Allowances
      • Change DApp Allowances (Delegated)
    • Payments in Snowflake
      • Self-Initiated Payments
      • Resolver-Initiated Payments
        • EIN - EIN Transfer
        • EIN - Address Withdrawal
      • Resolver-Initiated Via Payments
        • EIN - Via - EIN Transfer
        • EIN - Via - Address Withdrawals
      • Resolver-As-Escrow Payments
        • Resolver - EIN Transfer
        • Resolver - Address Withdrawal
      • Resolver-As-Escrow Via Payments
        • Resolver - Via - EIN Transfer
        • Resolver - Via - Address Withdrawal
    • Building a Resolver
      • Smart Contract
      • React Front-End
    • Building a Via Contract
  • Ice
    • Untitled
  • Tide
    • Untitled
Powered by GitBook
On this page

Was this helpful?

  1. Snowflake
  2. Snowflake Overview

Handling User Signatures

PreviousNaming ConventionsNextAddress Management

Last updated 6 years ago

Was this helpful?

Signatures

Several Snowflake function calls require a signature from a user-owned address. These function calls are designed to enable meta-transactions where a service provider can pay Ethereum network gas costs on behalf of an end-user. Meta-transactions enable a much smoother user-experience for dApps. These function calls contain r, s, and v as parameters, which can be derived from a signed message from the user's private key. Upon obtaining a signed message through a web3 client, the r, s, and v signature can be determined from the following steps:

  1. Extract the first 32 bytes to create the r value, the next 32 bytes to create the s value, and the last byte to create the v value.

  2. If you are using ecrecover, v will be either a 00 or a 01. As a result, you will have to parse it to an integer and add 27. This will result in either a 27 or a 28. See for further context.

  3. The r and s should be of type bytes32, and v should be of type uint8.

this issue