# Glossary

## Balance proof

A cryptographic proof attesting to a user's balance on INTMAX2. Legacy balance proofs are no longer accepted for withdrawals due to the circuit vulnerability.

## Data Store Vault

Encrypted storage for INTMAX2 user data. Only the user's view key can decrypt the contents.

## Deposit

Sending funds from Ethereum (L1) into the INTMAX2 Liquidity contract. Deposits are directly verifiable on the Ethereum blockchain and are always immediately counted in balance calculations.

## Exit contract

The Ethereum smart contract managing the exit process. It enforces the 24-hour timelock and handles submission, cancellation, and execution of exit requests. It does not hold funds — it instructs the Liquidity contract to transfer them.

## Exit request

A request to withdraw funds, specifying a recipient address, token, and amount. Must pass through a 24-hour timelock before execution.

## Guardian

An independent security role monitoring exit requests. The Guardian can:

* **Cancel** individual suspicious requests.
* **Pause** the entire system (only admin can unpause).
* **Cannot** execute requests, unpause, or access user funds.

Operates with a separate private key from the Submitter.

## Liquidity contract

The Ethereum smart contract holding all funds deposited into INTMAX2. During exit, funds are transferred directly from this contract to users' Ethereum addresses.

## Mining account

An INTMAX2 account derived from an Ethereum wallet signature. Each Ethereum address can have multiple mining accounts (index 0, 1, 2, ...), each with its own balance and history.

## Spend key

The private key that authorizes transactions on INTMAX2. **Never shared** with the Exit system.

## Timelock

A mandatory 24-hour waiting period between exit request submission and execution. Enforced by the Exit smart contract — cannot be bypassed or shortened by anyone, including operators. This window allows the Guardian to review and cancel suspicious requests.

## Transfer validation

The process of verifying that a transfer was legitimate by confirming the sender had sufficient balance. Validation is **recursive**: to validate a received transfer, the server must verify the sender's balance, which may depend on validating the sender's own incoming transfers, tracing all the way back to L1 deposits.

Each incoming transfer has one of three states:

| State         | Meaning                                                                                              |
| ------------- | ---------------------------------------------------------------------------------------------------- |
| **Validated** | Sender's balance confirmed sufficient. Counted in your balance.                                      |
| **Pending**   | Sender's balance not yet determined (typically: sender has not submitted view key). Not counted yet. |
| **Invalid**   | Sender had insufficient balance. Not counted.                                                        |

If a sender does not submit their view key, their transfers remain pending. A new countermeasure is planned for deployment by the end of February 2026 to resolve pending transfers without requiring the sender's participation.

## View key

A cryptographic key that allows **reading** (decrypting) a user's transaction data, but **cannot** move funds. Users submit their view keys (encrypted) to the Exit server so it can calculate their balances.

## View pair

The combination of a view key and its corresponding public spend key. This is what gets submitted during registration.

## Zero-knowledge proof (ZKP)

A cryptographic technique that proves a statement is true without revealing the underlying data. INTMAX2 uses ZKPs for transaction privacy and correctness.


---

# 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://intmax-exit.gitbook.io/intmax-exit-documentation/reference/glossary.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.