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

Resolver Management

Resolver Management

Resolvers under ERC 1484 encode identifying information about an Identity.

DApps can call functions on Snowflake allows DApps to add and remove resolvers, which encode information that drives the logic behind how these DApps recognize end users.

In the example below, the makeHappy contract checks whether its users have a status of "happy" as defined in the Status contract (a Snowflake Resolver that encodes info about a user - the info being a user-defined "status"). If they don't have the Resolver set, it adds it for them. If they do, it drives its logic based on the user's status within the resolver (in particular it checks if their status = "happy"; if so, it does nothing; otherwise it gives them a warm message).

Resolvers added and removed through Snowflake are flagged based on whether they leverage Snowflake as a provider, allowing for snowflake-specific onSignup and onRemoval functions when a Resolver is added and removed from an EIN. This functionality is designed to streamline the onboarding flow for end-users of smart contracts leveraging Snowflake.

Example:

PreviousUpgrade ProvidersNextAdding Resolvers

Last updated 6 years ago

Was this helpful?