Payments in Snowflake

Payments in Snowflake follow five predominant patterns:

  • Self-Initiated

  • Resolver-Initiated

  • Resolver-Initiated Via

  • Resolver-As-Escrow

  • Resolver-As-Escrow Via






EIN - Address



EIN - Address

Resolver Via

EIN - Via - EIN

EIN - Via - Address


Resolver - EIN

Resolver - Address

Resolver-Escrow Via

Resolver - Via - EIN

Resolver - Via - Address

Each payment pattern can be applied with an end-destination of another EIN or an address depending on whether the HYDRO is staying within Snowflake or leaving it, per the DApp developer's choice. We consider payments with end-destination EINs to be transfer functions while end-destination address payments are considered withdrawals, as the HYDRO balances are no longer contained within the Snowflake smart contract.

The two "via" patterns take advantage of via contracts. In a standard ERC-20 token transfer, tokens are transferred from point A to point B upon execution of a transfer function. Via contracts still denote a starting destination, a target destination, and an amount; however, they allow arbitrary logic to be executed with those parameters prior to completion of the transfer. Examples could include:

  • Routing the transfers through side-chains where multiple sub-transfers can occur.

  • Freezing the tokens in a contract that intermittently disburses them to the end-destination provided certain criteria persist.

  • Hot-swapping a token-transfer, so the receiving party receives ETH, DAI, or any other currency they would like.

  • Obfuscating the tokens through privacy protocols.

The Hydro team will focus on building robust, cutting-edge, generic via contracts in the "Tide" phase of Project Hydro. Until then, however, developers are encouraged to write custom via contracts or follow generic patterns as-needed for using via contracts.