# User Wallet

In this section we sketch how a user wallet could work, i.e., what kind of state would it need to store, how to retrieve the state and how to make new transactions. We assume [Deterministic Secret Management](/knowledge-base/protocol-details/deterministic-secret-management.md) is used.

### Current State and Creating Transactions <a href="#pdf-page-g0h9md4oz23sbs1axtrj-current-state-and-creating-transactions" id="pdf-page-g0h9md4oz23sbs1axtrj-current-state-and-creating-transactions"></a>

The current state of the user consists of:

* `seed` -- the master seed used to derive all secrets
* `id` -- the ZK-ID of the user
* Current note:
  * `trapdoor`
  * `nullifier`
  * `account` -- the current account state

Given all the above it's possible to update the state with the `update_note` transaction, as explained in [Notes and Accounts](/knowledge-base/protocol-details/notes-and-accounts.md) (or the adjusted version in [Anonymity Revokers](/knowledge-base/protocol-details/anonymity-revokers.md)) indeed the reader is encouraged to check that all the proofs necessary to craft a new transactions can be generated using the data listed above.

### Restoring the State from the master seed <a href="#pdf-page-g0h9md4oz23sbs1axtrj-restoring-the-state-from-the-master-seed" id="pdf-page-g0h9md4oz23sbs1axtrj-restoring-the-state-from-the-master-seed"></a>

The whole premise behind using a single master `seed` is that the user can recover the entire state as above just from the `seed` and the on-chain data. Of course the recovery process might be lengthy, but should be possible. On the other hand, for everyday operation the user is supposed to keep its current state, and preserve it, for efficiency.

Recovering the current state of a user consists of several steps:

1. Generate the ZK-ID `id` of the user deterministically from `seed`
2. Compute the key `key=key(id)`
3. Obtain the chronological list of all transactions `tx_1, tx_2, ... tx_n` that were finalized on chain:
   * To this end filter the list of all transactions sent to the shielder from all users. The filtering rule is as follows:
     * let `tx` be a transaction
     * let `mac = (m_0, m_1)` be the mac of `tx`
     * If `m_1 = hash(m_0, key)` then keep the `tx` as it means it belongs to the user
   * (Note that this step is quite inefficient as written, below we explain how one can go about improving the efficiency).
4. `tx_1` is the `new_note` transaction and can be thus ignored. For the remaining ones perform the following procedure to recover the current `account`.
   1. Set `account := Account::new()`
   2. For `tx` in `[tx_2, tx_3, ..., tx_n]` do:
      1. Extract `op_pub` out of `tx`
      2. Extract `op_priv` out of `e_op` using the key `key` to decrypt it
      3. Combine `op = combine(op_pub, op_priv)`
      4. Update the account `account = Account::update(account, op)`
5. Derive the `trapdoor` and `nullifier` of the last note deterministically from `seed`

### Improving the collection phase <a href="#pdf-page-g0h9md4oz23sbs1axtrj-improving-the-collection-phase" id="pdf-page-g0h9md4oz23sbs1axtrj-improving-the-collection-phase"></a>

To collect all transactions relevant to the account one has to filter all shielder transactions which is quite slow. There are several ideas on how to improve upon that:

1. To the `n`th shielder transaction of a user attach an encrypted (using `SymEnc` with key `key(id)`) number `k` being the block number where the `n-1`th transation landed. This way the only thing the user needs to do is: find its last transaction, and scan `n` blocks in total.
2. Use fuzzy message detection techniques.


---

# Agent Instructions: 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:

```
GET https://docs.common.fi/knowledge-base/protocol-details/user-wallet.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.