Payments in Snowflake

Payments in Snowflake follow five predominant patterns:

• Self-Initiated

• Resolver-Initiated

• Resolver-Initiated Via

• Resolver-As-Escrow

• Resolver-As-Escrow Via

Initiator\Type	Transfer	Withdraw
Self	EIN - EIN	EIN - Address
Resolver	EIN - EIN	EIN - Address
Resolver Via	EIN - Via - EIN	EIN - Via - Address
Resolver-Escrow	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.