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