# Audit scope

## In scope

All Tolk source under `apps/contracts/contracts/` **except** the auto-generated `verifier.tolk` (treat that as a known-good output of `export-ton-verifier` from a reviewed snarkjs zkey).

| File               | LOC (approx) | Risk area                              |
| ------------------ | ------------ | -------------------------------------- |
| `pool_native.tolk` | 350          | TVL custody, withdraw flow             |
| `pool_jetton.tolk` | 450          | TVL custody, counterfeit-jetton attack |
| `merkle_tree.tolk` | 200          | Root correctness, history window       |
| `poseidon.tolk`    | 250          | Hash correctness vs circuit            |
| `lib/*.tolk`       | 50           | Op codes, error codes                  |

## Off-chain in scope

| Path                                                   | Risk area                             |
| ------------------------------------------------------ | ------------------------------------- |
| `packages/core/src/poseidon.ts`                        | MUST match Tolk + circom Poseidon     |
| `packages/core/src/proof.ts`                           | Proof input ordering                  |
| `packages/core/src/pool.ts` :: `serialiseGroth16Proof` | Proof byte layout fed to TVM verifier |
| `apps/relayer/src/libs/Indexer.ts`                     | Correct decoding of log out-messages  |

## Out of scope

* The user's wallet / wallet-version implementation (`@ton/ton` library).
* Toncenter / lite-client correctness.
* circomlib's Poseidon implementation (treated as reviewed prior art).
* snarkjs's Groth16 prover (treated as reviewed prior art).
* TVM's BLS12-381 opcodes (chain-wide concern; trusted).

## Specific questions for auditors

1. Does the Tolk Poseidon match the circom Poseidon over BLS12-381? (Provide test vectors and run them against the on-chain harness.)
2. Are `is_known_root` and the root-history ring buffer correct? Does a slow withdraw (one that takes longer than 30 deposits) cleanly fail with `ERR_UNKNOWN_ROOT` rather than silently corrupt state?
3. Is the proof cell serialisation in `packages/core/src/pool.ts :: serialiseGroth16Proof` bit-compatible with what the auto-generated `verifier.tolk` expects?
4. Counterfeit-jetton attack: is sender validation correct, complete, and does it cover edge cases (e.g. bounce messages, deploy-time race)?
5. Gas budgeting: does the deposit path stay within TVM limits at 20-level Poseidon traversal? At 2^20 worst-case tree depth?
6. Storage rent: does the fee accrual model keep the pool alive for the expected lifetime?

## Test coverage required

* Property-based fuzz test for `insert_leaf`: random sequence of 1..N leaves, verify root matches `fixed-merkle-tree` mirror for every prefix.
* Spec test for double-spend reject.
* Spec test for unknown-root reject (more than 30 deposits between proof build and submission).
* Counterfeit-jetton fuzz: try to submit `transfer_notification` from every address that is *not* the pool's jetton wallet.
* Mainnet-equivalent fork test (Acton fork mode) once we have a real mainnet pool deployed.


---

# 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.tonadocash.com/operations/audit-scope.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.