> For the complete documentation index, see [llms.txt](https://docs.veilnyx.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veilnyx.com/technical-implementation/shielded-account.md).

# Shielded Account

Implementation of a shielded account

## Overview

A **Shielded Account** can be thought of as having a private crypto account counterpart to regular Ethereum accounts. However, unlike public Ethereum accounts, which have a single public-private key pair, a shielded account has two such key pairs - **Sign** and **View** key pairs, along with a **Root Address.**

For a better user experience, the shielded account keys are derived from the public Ethereum address itself. Meaning, that a user having a seed phrase and/or private key to their wallet can recover the same shielded account. This eliminates the load of handling any additional keys or seed phrases other than your regular Ethereum wallet. You implicitly have a Shielded Account if you have an Ethereum account in wallets (e.g. MetaMask, Rainbow, etc.).

To derive keys, the user signs a fixed message (EIP-712). The obtained signature's (Poseidon) hash acts as the seed ( $$\delta$$ ) for deriving both key pairs of Shielded Account.

$$
\sigma = \mathtt{ECDS\_Sign}(M) \\
\delta = H(\sigma)
$$

### Sign Key Pair

The sign key allows the holder of the shielded account to authorize transactions from its shielded account. A valid signature is constructed by signing the transaction data with the signing private key, $$s$$ via the Schnorr signature scheme over the Baby JubJub curve.

{% hint style="warning" %}
Holding a **Sign private key** gives the holder authority to spend any asset associated with that shielded account. Never share it!
{% endhint %}

The signing operation is intended to happen in a secure environment. 

**Sign private key** is derived as:

```typescript
SALT_SIGN = poseidonHash(stringToHex('sign'));
```

$$
s = H(\delta, \text{SALT\_SIGN})
$$

**Sign Public key** is a point on the curve generated using this sign private key.

### View Key Pair

The view key renders the view access to your shielded account, giving anyone holding the ability to read your balance and transaction history. The view private key encrypts the transaction-specific data while performing the transaction. Later, the same data is decrypted to reveal the balance and transaction history by the same key.

**View private key** is derived as:

```typescript
const SALT_VIEW = poseidonHash(stringToHex('view'));
```

$$
p = H(\delta, \text{SALT\_VIEW})
$$

**View Public key** is a point on the curve generated using this view private key.

### Root Address

Root address is a Poseidon hash of the sign public keys and the view private key.

```typescript
poseidonHash([this.signer.publicKey.x, this.signer.publicKey.y, this.viewer.privateKey]),
```


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.veilnyx.com/technical-implementation/shielded-account.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.