> For the complete documentation index, see [llms.txt](https://docs.blanksquare.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.blanksquare.io/protocol-details/details-of-silent-transfers.md).

# 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](/user-guides/silent-transfers.md) 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.&#x20;

## 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 <https://tee.fail/files/paper.pdf> 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 <https://github.com/Cardinal-Cryptography/blanksquare-monorepo/tree/main/crates/shielder-scheduler-tee> along with extensive documentation.&#x20;


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.blanksquare.io/protocol-details/details-of-silent-transfers.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
