> For the complete documentation index, see [llms.txt](https://hydro.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hydro.gitbook.io/docs/snowflake/payments-in-snowflake.md).

# 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.