---
# System prepended metadata

title: Q&A

---

# Q&A

- It seems that a client requires some infrastructure (API server, db). is it expected that every user will need to deploy this infrastructure? Why can't the proposer provide this role and remove the client requirement?
- can many users, with different keys, connect to the same client? if so, is this the expected behavior?
- Are keys generated per user?  when should they be generated? Having multiple key sets allows to have multiple accounts? what's the viewing key used for? An the ask?
- POST /incoming-viewing-key is used to allow the client to decrypt blockProposed events and update its dB? if so, does the client store the transactions decrypted?
- To make a deposit, you need the destination pkd (i understand that owner of tokens in L1 is not necessarily the same as the owneer in L2). But in the sdk, i see that you assume that the destination pkd matches the transmitter. Is this the normal behavior, or should I allow user to configure destination in the wallet?
-  what's the meaning of tokenId? I understand that for ERC20 is 0, and for ETH721 is non-zero. But not sure what it is used for.
- It's not clear the commitment selection mechanism. There is the idea of single and double transfer. Does this mean that during the transfer, the recipientData parameter is limited to an array of two elements?
- In nf3.mfs file, it is said `Note that the Nightfall_3 State.sol contract must be approved  by the token's owner to be able to withdraw the token`. How is this done? Is it only during withdraw?
- Function getWalletBalance() (used when calling GET /commitment/balance) returns the balance of each token address stored in L2. But this balance seems to be aggregated (meaining that it is not specified per user). Is this correct?

---
Oct 15th
- Is there a way to check the existing commitments in a client? My understanding is that depending on the existing commitments, it may be possible that a withdraw or transfer operation is denied. I would like to be able to warn about this in the wallet beforehand.
- Reviewing this point about commitments in a client in the SDK, probably it could be solved storing the `salts` about the commitments in an array property when processing transfers in the client. Then a client could have another function as `getCommitments` where the SDK could ask to the endpoint `/commitment/salt` for this commitments. It could be analysed. 
- Can the zkpKeys be deterministic, based on some hashed signed message from the user? A user will open several sessions with the wallet, and the zkpKeys should be persistent across sessions. If the zkpKeys are generated deterministically, we woulnd not need to store them. 
- I saw that BOND and STAKE are initialized in the SDK. Contracts check that these numbers are equal to an expected fixed number. Why are these numbers fixed in the contract? Shouldnt the contracts check for a minimum number? also, I found that the initial values in the SDK do not match the expect values in the contract.
- When doing the issue #197 I have found some operations that are missing now in the SDK. I will complete the list when finishing the issue.
    - nf3.deregisterProposer(). Allows de-register a proposer.
    - nf3.getProposers(). Get all available proposers.
    - nf3.withdrawBond(). Allows withdraw of the bond by a proposer.
    - nf3.getCommitmentBySalt(salt). Allows get one commitment by salt.
    - nf3.getCommitments(). Allows get all the commitments of the client.

---
Oct 22
- In the transactions, amounts have a width of 64 bits. This is done to minimize the gas cost. It relies on the assumption that tokens have few decimal bits so that transactions fit. Currently, the ERC token contract doesn't support decimals, so it behaves strangely.
- If users are using the same client then they are in the same trusted environment and thus their local application will take care of any local privacy that is needed (e.g. it only displays the balance of the logged in person).  If they don't trust other users, they really need to be on a separate client.
- Transfer and deposits are done to a given pkd. Is it possible to substitute this pkd to compressedPkd? Reason i am asking is that pkd has an X and a Y component, and compressedPkd only 1. For the user its easier to enter just one bit of info rather than two.
- Should there be a wallet docker?
- 