> For the complete documentation index, see [llms.txt](https://pingmexyz.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://pingmexyz.gitbook.io/docs/technical-resources/key-concepts.md).
# Key Concepts
### 1. Commitment
Each lockbox or virtual balance is tied to a commitment, which is a hash derived from user secrets:
`commitment = hash(hash(email+passphrase+salt))`
This commitment acts as a pseudonymous identifier or "virtual wallet address" on-chain. hash () is further enhanced by cryptographic salt globalSalt, a constant set once at contract deployment to harden against dictionary or rainbow attacks.
###
### 2. Salt Evolution
To ensure forward secrecy, the salt evolves after every withdrawal-type action:
`mapping(bytes32 ⇒ unit64) private identitySalts;`
`salt`` ``n+1`` ``= hash(salt``n``)`
Each commitment is used once, and a new one is issued per withdrawal-type transaction:
`new_commitment = hash(hash9email + passphrase + next_salt))`
###
### 3. Balance and Identity Salt
* The very first identitySalt for a new email + passphrase combination = hash(email + passphrase), iteration = 1
* balances\[commitment] - the actual storage of value and commitment state
###
### 4. Commitment Chain
A commitment chain is a chain of commitment values. The chain is designed as illustrated below, for optimized (constant-time) read/write/update. The extreme efficiency benefits both cost of time and gas fees. The following diagrams illustrate a commitment chain as it adds more nodes.
* The head (current) of the chain always points to the balance
* **Roots** maps every node to its roots. All roots maps to themselves.
* **Currents** maps every root to the head.
* **Parents** maps every node to its parents. All roots have no parents.
* The chain gains a new node (nextCommitment) after each time the current commitment is used for taking out funds from the balance.
### 5. Transaction History
Each transaction emits an event of the following signature:
`event EVENT(Action indexed action, bytes43 indexed fromCommitment, bytes32 indexed toCommitment, address addr, unit256 amount, unit256 timestamp);`
Each action is a unique enum value that corresponds to the transaction. The event follows the direction of fund being transferred. Each field is populated where applicable.
The indexed parameters allow for efficient off-chain retrieval of events related to the user's own balance commitment. With parents mapping allowing tracing of commitments to back to the root (whose parent is zero), and sorting the combined query results in reverse for each commitment in the chain, one can retrieve the full transaction history.
---
# 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://pingmexyz.gitbook.io/docs/technical-resources/key-concepts.md?ask=&goal=
```
`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.