# Details of Silent Transfers The silent transfers feature allows users to send private transfers between two arbitrary EVM addresses. We refer to the section [silent-transfers](https://docs.blanksquare.io/user-guides/silent-transfers "mention") to learn what it and what are the use-cases from an end-user perspective. This section is devoted to explaining the technical details and inner workings of the transfers. ## General Idea If we ignore some low-level details, a silent transfer is determined by the following parameters: * `origin` and `destination` EVM addresses * `amount` (let's assume for simplicity we work with the native token, so ETH, or HYPE, etc.) * `time_delay` — the number of seconds between the moment the transfer is initiated at `origin` till it lands at `destination` What happens under the hood is simply that the user (owner of `origin`) deposits `amount` tokens to the Shielder and then after `time_delay` seconds withdraws them to `destination`. External observers are not able to link `origin` to `destination` thanks to the properties guaranteed by the Shielder. ## Two Variants The silent transfer feature comes in two variants in which both the client-side part (frontend) and the backend side differ significantly. 1. **2-click version** — this is a "vanilla" version where the user makes two interactions with the client-side application (dApp): one is to make the deposit, and, after `time_delay` it initiates the withdraw. While this is keeping it simple and retains maximum control on the user-side, it is also a little bit clunky from the UX perspective. Indeed, the use must remember to come and make the withdrawal after `time_delay`. While this is just one simple click in the interface, the time delay aspect is problematic. 2. **1-click version** — this is delegating the problematic second "click" to an offchain service run within a TEE. More specifically, the user sends the encrypted payload of the withdraw transaction to a TEE, and this offchain service executes the transaction after the `time_delay` has passed. We discuss details below. ## TEE In the first version of the 1-click privacy backend AWS nitro-enclaves are used as TEEs. It is fair to note that the security of the system now also depends on trust to the cloud-provider and not just on trust in a specific piece of hardware, however in the light of recent attacks on TDX and SGX this assumption is now necessary for all deployments of TEE-based projects. Ultimately, trust in cloud providers underpins much of the Internet’s safety: domains, DNS, and routing, hence this is not really extending the trust any further. ## 1-click Privacy Scheduler The implementation of the backend service for scheduling withdraw transactions is available open-source here along with extensive documentation.