# Privacy Mining v2 (May 2024 ~)

## 1. Overview

The goal of **privacy mining** is to expand and maintain the anonymity set of the privacy protocol. By simply following the on-screen instructions, you can contribute to privacy and earn rewards.

[UI instruction](https://docs.network.intmax.io/user-guides/privacy-mining/)

## 1.1 Play now

Go to [TL;DR](https://hackmd.io/@lionfeeder/HkNOuv9Ege) and follow the guidance.

You can just deposit 1 ETH without thinking anything to have both privacy and rewards. ***[IMPORTANT] You DON'T have to read the explanation below unless you want to maximize your rewards.***

## 2. Key improvement under the New Rule

**NOTE**: This rule will be enforced starting **two days after the mainnet release**.

### 2.1 Network & Lock Period

- Operates on the **Ethereum Mainnet**.
- **Lock Period**:
- **Old Rule:** Rewards were distributed at two stages (after 2 weeks and 3 months).
- **New Rule:** Funds are locked for **2–5 days**, and users can claim all rewards at once when the lock is lifted.

### 2.2 New User Interface

- **Old Rule:** Mining tool was available only via CLI.
- **New Rule:** A **web interface** is now available, making participation easier. We plan to release an updated version of the CLI compatible with the new version in the coming days.

## 3. Issuance of the Token

### 3.1 Token Information

- The token symbol is **`ITX`**.
- The maximum supply is **1,001,000,000** tokens (1.001 billion).
- The issuance period spans **2,032 days** (16 + 32 + 64 + 128 + 256 + 512 + 1024 days) with **6 halving events**.

| Term | Start | End | Days | Rewards Per Day | Rewards of This Term |
| --- | --- | --- | --- | --- | --- |
| 1 | 2024/08/07 | 2024/08/23 | 16 | 8,937,500.0000 | 143,000,000 |
| 2 | 2024/08/23 | 2024/09/24 | 32 | 4,468,750.0000 | 143,000,000 |
| 3 | 2024/09/24 | 2024/11/27 | 64 | 2,234,375.0000 | 143,000,000 |
| 4 | 2024/11/27 | 2025/04/04 | 128 | 1,117,187.5000 | 143,000,000 |
| 5 | 2025/04/04 | 2025/12/16 | 256 | 558,593.7500 | 143,000,000 |
| 6 | 2025/12/16 | 2027/05/12 | 512 | 279,296.8750 | 143,000,000 |
| 7 | 2027/05/12 | 2030/03/01 | 1,024 | 139,648.4375 | 143,000,000 |
| **Total** | | | **2,032** | | **1,001,000,000** |

### 3.2 Reward Calculation Formula

- The daily issuance amount is predetermined.

Rewards are distributed based on:

**(Daily Issuance) * (Individual Contribution) / (Total Contribution)**

See details on how rewards are calculated in **SECTION 7**

### **3.3 Reward Distribution Under the New Rules**

- After the **2–5 day lock period** ends, and once the user’s status is “Claimable,” they can receive their rewards.
- If a user violates the mining rules, the associated deposit will be **ineligible** for rewards.
See details on mining rule in **SECTION 5**

## 4. AML

- From an AML perspective, deposits from **high-risk addresses** (e.g., sanctioned addresses) may be rejected.
- A “Proof of Innocence” mechanism is available if needed, allowing users to prove their funds are not illicitly mixed.
- The initial deposit limit is **100 ETH**, which will be **raised every six months**, reaching **10,000 ETH** after two years. It remains fixed thereafter.

## 5. Rules of Mining and Lock Period

- **Deposit Amounts:** Deposits must be precisely 0.1, 1, 10, or 100 ETH.
- **AML Compliance:** All deposits are subject to Anti-Money Laundering (AML) checks upon entry. Deposits failing to meet AML standards are not accepted into the INTMAX Network.
- **Lock Period:** Once deposited, funds must remain in place for the entire lock period. This period is determined by the hash of the INTMAX block containing your deposit and a random value set at the time of deposit.
- **ITX Token Eligibility:** If you breach any of the deposit rules, you will not qualify to receive ITX tokens.

**Withdrawal Flexibility:** You can withdraw your deposited funds at any time, even if you violate the above rules. It is recommended to use the official user interface, designed to help avoid common violations.

## 6. Comparison With the Old Rules

| Rule | Old Version | New Version |
| --- | --- | --- |
| Partial reward distribution | After 2 weeks (1/3), then after 3 months(2/3) | None (All rewards claimed 2–5 days after deposit) |
| Circulation slashing | Reduce mining rewards | None (It may be introduced in the future) |
| Rushy Deposit | Reduce mining rewards | None |
| 10/10 Deposit Cycle | Reduce mining rewards | None |
| Mining cycle | Deposit to a new address | UI supports starting new cycles |

## 7. Reward Distribution Method

### 7.1 Mining Contribution

Based on your deposit amount, you will be assigned points used to calculate your share of the rewards. The table below shows how these points are allocated:

| Mining Amount | Points |
| --- | --- |
| 0.1 ETH | 1 |
| 1 ETH | 4 |
| 10 ETH | 9 |
| 100 ETH | 16 |

Your total rewards are proportional to the number of points you have relative to everyone else.

**Example**: Suppose that on March 14, Person A requests a mining reward of 0.1 ETH, and Person B requests 1 ETH. Assume that no one else has made a request. According to the table, the contribution score (points) for 0.1 ETH is 1, while the contribution score for 1 ETH is 4. This means the total points for the day amount to 5. If the total reward distributed per day is 10,000 ITX, then Person A will receive $10,000 \times 1 / 5 = 2,000$ ITX, and Person B will receive $10,000 \times 4 / 5 = 8,000$ ITX. The reward will be sent to the user's Ethereum address on March 15.

### **7.2 Reward Schedule**

Rewards will be distributed to users participating in privacy mining, based on their level of contribution. The daily reward amounts will be distributed according to the schedule below:

1. **Mainnet Release to December 16, 2025 (End of Term 5)**
- Daily Distribution: **558,593.75 ITX**
2. **December 16, 2025, to May 12, 2027 (End of Term 6)**
- Daily Distribution: **279,296.875 ITX**
3. **May 12, 2027, to March 1, 2030 (End of Term 7)**
- Daily Distribution: **139,648.4375 ITX**

**Important Notes:**

- If there is a day on which no mining activity occurs, all tokens scheduled for distribution on that day will be burned.
- Any fractional amounts resulting from token distribution will also be burned.

## 8. Mining Flow in the back-end


Users connect their wallets on the [INTMAX website](https://beta.testnet.app.intmax.io/). Initially, they sign with the connected wallet to generate the INTMAX address they will use. Once the INTMAX address is generated, they can start mining.

The INTMAX website provides features to simplify complex address management for mining. Users only need to visit the website and perform the required actions when making deposits or withdrawals.

**IMPORTANT**: It is essential to keep the deposit and withdrawal addresses separate. It is recommended to use the UI, which will guide you to automatically manage multiple addresses.

## 9. The History of This Mining

- **June 8, 2024**: Mining begins
- **September 5, 2024**: Mining page pinned
- **September 14, 2024**: The ERC20 contract is deployed by LappsNet in El Salvador
- **September 28, 2024**: Deposit contract upgraded
- **October 19, 2024**: Migration to Base Mainnet
- **Q2 2025**: Migration to Ethereum Mainnet; old CLI-based mining will be discontinued

**NOTE**: Access from heavily regulated regions such as the United States may be partially blocked. Please use the service at your own risk, adhering to all local laws and regulations.

---

## 10. Appendix: Details of Reward Claiming

## 10.1. Overview of Privacy Mining and Claim

Privacy Mining allows users to deposit tokens into the system, lock them for a certain period (determined by a ZKP circuit), and later claim their rewards. Claims require users to produce zero-knowledge proofs to demonstrate:

- A valid deposit has been made.
- A sufficient lock period has elapsed since the deposit.
- The deposit address has not sent any transfers during the lock period.
- The deposit has not been double-spent (double-claim prevention).

These claims are aggregated into a single proof for on-chain verification, ultimately enabling reward distribution to recipients on Ethereum.

## 10.2. Privacy Mining Flow

The high-level flow of Privacy Mining related to claiming rewards is as follows:

1. **Fetch your ongoing mining**
- Obtains a **Mining** record (an object) that includes information such as deposit details, the block in which the deposit was included, the maturity time, etc.
- A mining record has the following structure:
- `deposit_data`: Detailed information about the deposit, including `deposit_salt`.
- `block`: The first block that contains the deposit.
- `maturity`: The maturity Unix timestamp.
- `status`: Current status of the deposit, possible values include:
- `locked`: Deposit is currently locked.
- `claimable`: Deposit has matured and is ready to be claimed.
- `claimed`: Deposit has already been claimed.
2. **Check If a Mining Is Already Claimed**
- Before creating a new claim, the system confirms if any deposit (identified by a deposit index or nullifier) has already been claimed.
3. **Determine the Correct Claim Block**
- Let `deposit_block_number` be the block number in which the deposit was first included.
- Let `claim_block_number` be a block number after the deposit’s lock period has passed.
- **Constraint**: No other token transfers from the same public key are allowed between `deposit_block_number` and `claim_block_number`.
4. **Wait for Validity Prover Synchronization**
- The system’s validity prover must be synced up to the `claim_block_number`.
5. **Obtain Update Proof**
- Update the balance proof from `deposit_block_number` to `claim_block_number`, creating an update witness (sometimes called an **UpdateWitness**).
6. **Compute Merkle Trees at Relevant Blocks**
- For the block at `deposit_block_number` and the immediately preceding block, compute the Merkle proofs for the deposit index.
- These proofs show that the deposit was included at `deposit_block_number` and *not* included in the previous block, thus identifying the exact block where the deposit became valid.
7. **Construct the `DepositTimeWitness`**
- Combine the Merkle proofs and block data into a structure called **DepositTimeWitness**.
- `DepositTimeWitnes` has the following structure:
- `publicWitness`:
- `prevBlock`: The previous Intmax block before the user's deposit.
- `block`: The Intmax block containing the user's deposit.
- `depositMerkleProof`: A Merkle proof demonstrating that the user's deposit is included in the deposit tree at the time of `currentBlock`.
- `prevDepositMerkleProof`: A Merkle proof demonstrating that the user's deposit was **not** included in the deposit tree at the previous block (`prevBlock`).
- `depositIndex`: The index of the user's deposit within the deposit tree.
- `deposit`: The publicly available details of the user's deposit.
- `depositSalt`: A value used for computing the recipient salt hash.
- `pubkey`: The user’s public key.
8. **Combine to Form the `ClaimWitness`**
- Package the deposit-time information, the update proof, and the final claim recipient into a single structure called **ClaimWitness**:
- `recipient`: the user’s address to receive mining rewards.
- `depositTimeWitness`
- `updateWitness`
9. **Generate the Single Claim Proof**
- The user runs:
1. `DepositTimeCircuit`:
2. `SingleClaimCircuit`:
- These produce a **single_claim_proof**, which is a Plonky2 proof verifying deposit validity, maturity, and up-to-date balance status.
10. **Claim Aggregation**
- A “claim aggregator” then takes multiple `single_claim_proof`s and merges them with a previously aggregated claim proof (`prev_claim_proof`) into a single “cyclic” proof. This repeated aggregation yields one final proof (`claim_proof`) verifying multiple claims at once.
11. **Wrapping Proof for On-Chain Verification**
- The aggregator wraps the `claim_proof` into a format suitable for gnark-based Solidity verification. This wrapped proof is returned as a `wrapped_claim_proof`.
12. **On-Chain Submission**
- The aggregator (or user) calls `submitClaimProof` on-chain, providing the `wrapped_claim_proof`.
- The smart contract verifies all claims within that proof, storing any new or unprocessed claims in contract storage.
13. **Daily Aggregation and Reward Assignment**
- Claims are aggregated daily, with the reward distribution schedule set to **every day at 00:00 UTC**.
14. **Relay of Claims to Ethereum**
- By calling `relayClaim(period)`, the aggregator or a relayer informs Ethereum about the claims.
- Then a relayer calls `relayMessageWithProof`, causing the reward tokens (ITX) to be sent to the user’s recipient address.
- Internally, `relayMessageWithProof` calls the liquidity contract’s `processWithdrawals`, finalizing the transfer.

## 10.3. Claim Contract Specification

### 10.3.1 Claim Structure

{
    "recipient": "0xabc...def",
    "amount": 1000000000000000000,
    "nullifier": "0xabc...def",
    "block_hash": "0xabc...def",
    "block_number": 12
}

- **recipient**: The recipient of the claim
- **amount**: The amount of the deposit (in wei)
- **nullifier**: Used to prevent double claims
- **block_hash**: Balance proof block hash used for withdrawal
- **block_number**: Balance proof block number used for withdrawal

### 10.3.2 Claim Aggregation Flow

1. **Single Claim Proof**
- The user obtains a proof (e.g., `ProofWithPublicInputs`) from the `SingleClaimCircuit`.
2. **Aggregation**
- The aggregator repeatedly merges:

        prev_claim_proof + single_claim_proof → claim_proof

- This creates a single cyclic proof containing multiple claims.
3. **Wrapping for gnark**
- The aggregator or server creates a “wrapped” proof compatible with gnark, enabling a Solidity contract to finalize on-chain verification.

### 10.3.3 Contract Functions

- **`submitClaimProof`**
- Accepts the aggregated `wrapped_claim_proof` on-chain.
- In the on-chain verification process, the `block_number` and `block_hash` referenced by each Claim must match the latest data from the Rollup, verified by calling something like `IRollup.getBlockHash(block_number)`.
- The smart contract manages daily reward allocations using an allocation mechanism (e.g., `AllocationLib`). When executing the `relayClaims` function, processing is performed based on this allocation data.
- **`relayClaim`**
- Communicates the final reward data to the Ethereum contract, referencing a specific `period`.
- **`relayMessageWithProof`**
- Called by a relayer after `relayClaim`, finalizing the token transfer by calling a liquidity contract’s `processWithdrawals`.

## 10.4. Claim ZKP Constraints and Circuits

The Claim ZKP is composed of two main sub-circuits:

1. **DepositTimeCircuit** is a ZKP circuit that verifies a deposit was included for the first time in a specific block and that a valid lock duration was set.
2. **SingleClaimCircuit** verifies that the deposit has matured and that no other transfers occurred from the user's account during the lock period.

### 10.4.1 DetermineLockTimeTarget

`DetermineLockTimeTarget` is an intermediate module for computing the lock time.

The lock time is derived from the deposit’s block hash and salt:

- **block_hash**: 32 bytes
- **deposit_salt**: Some Salt type

**Pseudo-steps**:

1. `seed_poseidon` = PoseidonHash(block_hash, deposit_salt)
2. Convert `seed_poseidon` into a value within `[172800, 432000]` (2–5 days in seconds).

### 10.4.2 DepositTimeTarget

`DepositTimeTarget` ensures:

1. **Block Linking**
- `prev_block` and `block` are valid blocks.
- `prev_block.block_hash` equals `block.prev_block_hash`.
2. **Deposit Validity**
- `deposit.is_eligible` is `true`.
- `deposit_index` fits within 32 bits.
- `deposit_salt` is valid.
- `pubkey` is 256 bits.
3. **Merkle Proof Checks**
- A proof that at `deposit_index`, the deposit was *not* included in `prev_block`.
- A proof that at the same `deposit_index`, the deposit *is* included in `block`.
4. **Salt Hash Matching**
- `pubkey_salt_hash` is computed from `deposit` and `deposit_salt`.
- `Poseidon(deposit, deposit_salt)` produces a `nullifier` for double-claim prevention.
5. **Lock Time Reference**
- Checks that `determine_lock_time_target.block_hash` and `deposit_salt` match the deposit data.

### 10.4.3 DepositTimeCircuit

- Enforces all constraints from `DepositTimeTarget`.
- Exposes the necessary public inputs (`block_number`, `block_hash`, `pubkey`, etc.) for the subsequent circuit to verify deposit-time correctness.

### 10.4.4 SingleClaimTarget

Within the `SingleClaimCircuit`, we have constraints such as:

1. **Valid Plonky2 Proofs**: Both `validity_proof` and `deposit_time_proof` must be valid.
2. **Merkle Proofs**: The `block_merkle_proof` confirms `block_hash` is indeed part of a recognized `block_tree_root`.
3. **Account Membership Proof**: Ensures no transaction was sent by this pubkey prior to the relevant block.
4. **Maturity Check**: Confirms the deposit is matured by checking `deposit_time + lock_time <= current_block_timestamp`.
5. **Recipient Format**: The `recipient` must be a valid address.

### 10.4.5 SingleClaimCircuit

- Uses a zero-knowledge configuration (Plonky2).
- Enforces the constraints from **SingleClaimTarget**.
- The public inputs follow the structure described in **3.1 Claim Structure**.

## 10.5. Putting It All Together

1. The user performs a deposit, creating a **Mining** record.
2. Once the deposit’s lock time is reached, the user initiates a **claim**.
3. The system checks if the deposit is unclaimed and constructs:
- DepositTimeWitness
- UpdateWitness

These form a **ClaimWitness**.

4. The user or aggregator runs:
- **DepositTimeCircuit** checks that a deposit was included for the first time in a specific block and that a valid lock duration was set.
- **SingleClaimCircuit** checks that the deposit has matured and that no other transfers occurred from the user's account during the lock period.
5. A single proof (`single_claim_proof`) is produced.
6. Multiple single claims can be aggregated into one (`claim_proof`).
7. The proof is wrapped for gnark-based Solidity verification.
8. On-chain:
- **submitClaimProof** is invoked, verifying all claims and storing new claim info.
- Rewards are aggregated daily, with final distribution triggered via:
- **relayClaim** → signals to Ethereum.
- **relayMessageWithProof** → calls `processWithdrawals` for ITX token distribution.

### Final Notes

- Randomizing the lock time is crucial to avoid predictable deposit intervals.
- The `nullifier` prevents double-spending/claiming.
- Aggregating claims into a single proof significantly reduces on-chain verification costs.
- All core data (block hashes, Merkle proofs, account membership) must be validated by the circuit to ensure system integrity and privacy.