> For the complete documentation index, see [llms.txt](https://plabs.gitbook.io/plabs-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://plabs.gitbook.io/plabs-docs/privacy-core/orchard-concepts.md).

# Orchard concepts

Privacy Core uses the [**Orchard shielded pool**](https://zips.z.cash/protocol/names#orchard-shielded-pool) data model ([Zcash Protocol Specification](https://zips.z.cash/protocol/protocol.pdf)), deployed on EVM with [**Groth16**](/plabs-docs/privacy-core/groth16-action-circuit.md) and a [**per-asset Merkle tree**](#commitment-tree).

## Notes vs account balances

Public tokens use **account balances**:

```
balance[Alice] = 100
balance[Bob]   = 50
```

Privacy Core uses **shielded notes**:

```
Tree: { cmx₁, cmx₂, cmx₃, ... }   // commitments only on-chain
Alice holds: notes decryptable with her viewing key
Bob holds:   notes decryptable with his viewing key
```

There is **no** on-chain `mapping(address => uint256) balance`.

## Note lifecycle

```
Create (mint / transfer output)
    → cmx inserted into Merkle tree
    → encCiphertext in NoteAdded event
         │
Hold (off-chain scan + trial-decrypt)
         │
Spend (transfer / burn input)
    → reveal nfOld (nullifier)
    → Groth16 proves knowledge + non-freeze
    → create output note (transfer) or destroy (burn)
```

## Cryptographic objects

| Object            | Role                             | On-chain visibility           |
| ----------------- | -------------------------------- | ----------------------------- |
| **cmx**           | Note commitment, Merkle leaf     | ✅ commitment                  |
| **nf**            | Nullifier, anti double-spend     | ✅ on spend                    |
| **anchor**        | Historical Merkle root for input | ✅                             |
| **encCiphertext** | Recipient-encrypted note (580 B) | ✅ ciphertext                  |
| **outCiphertext** | Sender OVK recovery (80 B)       | ✅ ciphertext                  |
| **v**             | Note value                       | ❌ constrained in circuit only |

## Action

One **action** = optionally consume **one input note** + create **one output note**, with:

1. **Value conservation** (`valueBalance` + bindingSig)
2. **Input membership** (Merkle32 under `anchor`)
3. **Correct nullifier** (`nf_old` from `nk, rho, psi, cm_old`)
4. **Output commitment** (`NoteCommitNew`)
5. **Spend authorization** (`rk` + spendAuthSig)
6. **Compliance non-membership** (input `cm_old` not in freeze set) — [Compliance freeze](/plabs-docs/privacy-core/compliance-freeze.md)

Mint uses a **dummy input** (`v_old = 0`) on the same path as transfer.

## Commitment tree

| Parameter | Value                                            |
| --------- | ------------------------------------------------ |
| Depth     | 32                                               |
| Hash      | Poseidon (incremental insert)                    |
| Views     | `cmxRoot()`, `isValidAnchor(root)`, `treeSize()` |

Historical roots are permanently queryable (`_allRootsEver`) for spending against old anchors.

## Keys (summary)

| Key                     | Use                        |
| ----------------------- | -------------------------- |
| Spending key            | Nullifiers, spendAuthSig   |
| Viewing key (ivk)       | Scan events, trial-decrypt |
| Address (pk\_d / perc1) | Recipient identifier       |

Wallet derivation is application-layer; the circuit binds `ivk` to `pk_d` via `CommitIvkPkD`.

## Privacy guarantees & limits

**Hidden**: sender, recipient, transfer amounts (mint/burn amounts are public at app layer).

**Visible**: `NoteAdded` blobs, `totalSupply` (pERC20), submitter EOA (unless relayer).

**Important**: `NoteAdded` alone does not prove payment — recipient must trial-decrypt.

## Next

* [Note state machine](/plabs-docs/privacy-core/state-machine.md)
* [Groth16 action circuit](/plabs-docs/privacy-core/groth16-action-circuit.md)


---

# 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://plabs.gitbook.io/plabs-docs/privacy-core/orchard-concepts.md?ask=<question>&goal=<endgoal>
```

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