> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stablenet.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Mint and Burn Protocol

## Purpose and Scope

This document describes the **end-to-end protocol** for minting and burning the native stablecoin on StableNet.\
It covers off-chain coordination between minter members and financial institutions, the proof structures used to verify fiat movements, and the **GovMinter governance contract with quorum-based approval procedures**.

For detailed information on the governance contracts implementing this protocol, see [Minting Governance (GovMasterMinter and GovMinter)](/en/governance-system/5.4-minting-governance-\(govmasterminter-and-govminter\)).\
For the token layer where minting and burning are actually executed, see the [NativeCoinAdapter Contract](/en/governance-system/5.2-nativecoinadapter-contract).\
The overall governance architecture is described in [System Contracts Overview](/en/governance-system/5.1-system-contracts-overview).

## Protocol Overview

The mint and burn protocol aims to issue stablecoins **backed by verifiable fiat deposits and withdrawals**.\
The protocol follows three core principles:

1. **No unilateral execution without quorum**: Mint and burn operations are executed only after a GovMinter proposal and quorum-based approval.
2. **Proof-based verification**: Every mint and burn is proposed together with a proof referencing an off-chain fiat movement.
3. **Quorum-based consensus**: Operations are executed only when the minter quorum defined at GovMinter genesis is reached.

The protocol assumes cooperation among the following participants:

* **Minter members**: Governance participants who verify proofs and vote on mint/burn proposals
* **Collateral accounts**: Bank accounts where fiat deposits and withdrawals actually occur
* **GovMinter contract**: On-chain governance contract managing mint/burn proposals and voting\
  (`0x0000000000000000000000000000000000001003`)
* **NativeCoinAdapter contract**: System contract that executes approved mint/burn operations by modifying native balances\
  (`0x0000000000000000000000000000000000001000`)

## System Architecture

The mint and burn protocol consists of three layers: **off-chain verification + on-chain consensus + native balance modification**.\
The off-chain layer verifies fiat movements, the on-chain layer validates them via collective consensus, and the execution layer updates balances and total supply consistently through the NativeCoinAdapter.

## Minting Protocol

### Minting Workflow

The minting protocol follows the four-step flow below:

1. **Deposit detection**: A fiat deposit into a collateral account is detected
2. **Proof construction**: A mint proof containing deposit information is created
3. **Proposal and verification**: A proposal is submitted to GovMinter and independently verified by minters
4. **On-chain execution**: Once quorum is reached, minting is executed via the NativeCoinAdapter

### Mint Proof Structure

A mint proof is a data structure that binds a token issuance request to a specific fiat deposit.\
On-chain, it is represented by the `MintProof` struct in GovMinter.

| Field           | Type    | Description                                            |
| --------------- | ------- | ------------------------------------------------------ |
| `beneficiary`   | address | Address that will receive the minted tokens            |
| `amount`        | uint256 | Amount of tokens to mint (in smallest units)           |
| `timestamp`     | uint256 | Unix timestamp when the deposit occurred               |
| `depositId`     | string  | Unique identifier of the deposit in the banking system |
| `bankReference` | string  | Bank transaction reference (1:1 with deposit record)   |
| `memo`          | string  | Optional memo for internal accounting and auditing     |

This structure, together with GovMinter state (`usedProofHashes`, `depositIdToProposalId`, `executedDepositIds`), ensures:

* **Uniqueness**: Each `depositId` can be used only once, preventing double minting
* **Traceability**: On-chain issuance is linked to a specific off-chain deposit
* **Timeliness**: Old proofs can be rejected based on timestamps

### Minter Responsibilities During Minting

Minter members have the following responsibilities during minting:

1. **Collateral account association**: Minters must be associated with predefined collateral accounts, managed via GovMasterMinter
2. **Deposit monitoring**: Continuously monitor fiat deposits in collateral accounts off-chain
3. **Proof creation**: Generate a mint proof when a deposit is detected
4. **Proposal submission**: One minter submits a mint proposal to GovMinter\
   Duplicate proposals for the same `depositId` are rejected
5. **Independent verification**: Other minters independently verify the proof:
   * Whether the deposit occurred
   * Whether the amount matches
   * Whether the beneficiary address is correct
   * Whether the deposit has already been used
6. **Approval voting**: Approve after successful verification; otherwise reject or abstain

### On-Chain Execution

Once a mint proposal reaches quorum, `GovBase.executeProposal()` calls GovMinter’s `_executeMint()`, which internally issues tokens via `fiatToken.mint(beneficiary, amount)`.\
In typical networks, this `fiatToken` is the `NativeCoinAdapter`.

Execution steps:

1. **Quorum check**: GovBase verifies that sufficient approvals have been collected
2. **Allowance verification**: Confirms that `fiatToken.minterAllowance(GovMinter)` is sufficient
3. **Mint execution**: Calls `fiatToken.mint(beneficiary, amount)`\
   For NativeCoinAdapter, native balances are increased via the internal `ICoinManager.mint()`
4. **Proof consumption**: Records `executedDepositIds[depositId] = true` to prevent reuse
5. **Total supply update**: Increases the fiat token total supply
6. **Event emission**: Emits `Mint` and `Transfer(address(0), beneficiary, amount)` events

## Burn Protocol

### Burn Workflow

The burn protocol operates as the reverse of minting.\
After tokens are burned on-chain, an equivalent amount of fiat is returned off-chain.

### Burn Proof Structure

A burn proof represents a valid withdrawal request corresponding to a token burn.\
On-chain, it is represented by the `BurnProof` struct in GovMinter.

| Field          | Type    | Description                                        |
| -------------- | ------- | -------------------------------------------------- |
| `from`         | address | Address holding the tokens to be burned            |
| `amount`       | uint256 | Amount of tokens to burn                           |
| `timestamp`    | uint256 | Time when the withdrawal request was received      |
| `withdrawalId` | string  | Unique identifier of the withdrawal request        |
| `referenceId`  | string  | External settlement system reference ID            |
| `memo`         | string  | Optional memo for internal accounting and auditing |

GovMinter uses `withdrawalIdToProposalId`, `executedWithdrawalIds`, and `usedProofHashes` to ensure:

* **ID uniqueness**: Each `withdrawalId` can be used only once
* **User specificity**: Burns are executed for a specific `from` address
* **Idempotency**: Duplicate burns for the same withdrawal request are prevented

### Minter Responsibilities During Burning

1. **Receive withdrawal request**
2. **Generate withdrawal ID**
3. **Share off-chain**
4. **Create burn proof**
5. **Submit proposal and escrow**: Call `proposeBurn{value: amount}` to escrow the same amount of native coin
6. **Independent verification**
7. **Approval voting**
8. **Fiat return**

### On-Chain Burn Execution

When quorum is reached, `GovBase.executeProposal()` calls GovMinter’s `_safeBurn()`.

Execution steps:

1. **Quorum verification**
2. **Emergency pause check**
3. **Escrow balance deduction**
4. **Burn execution**: `fiatToken.burn(amount)`
5. **Withdrawal ID consumption**
6. **Event emission**

## Quorum Requirements and Governance

### Quorum Configuration

The quorum required for mint and burn operations is set via GovMinter genesis parameters.

```
systemContracts.govMinter.params:
- members: "comma-separated list of minter addresses"
- quorum: "minimum approvals required"
- expiry: "proposal expiration time in seconds"
- memberVersion: "version identifier"
- fiatToken: "0x0000000000000000000000000000000000001000"
```

Recommended guidelines:

* **Minimum**: 1
* **Maximum**: Number of minters
* **Typical**: `ceil((members.length * 2) / 3)`

### Proposal Lifecycle

1. **Proposed**
2. **Voting**
3. **Quorum reached**
4. **Executed**
5. **Expired**

## Security Considerations

### Byzantine Fault Tolerance

With quorum set to `ceil((N * 2) / 3)`, up to `floor((N - 1) / 3)` malicious minters can be tolerated.

### Off-Chain Dependencies

Failures in off-chain coordination may cause delays or rejections, but are mitigated by the multi-minter structure and on-chain event auditing.

### Proposal Expiry

The expiry mechanism prevents execution of stale proofs, governance griefing, and unbounded proposal accumulation.

## Integration with NativeCoinAdapter

### Mint Execution Path

```
GovBase.executeProposal()
→ GovMinter._executeMint(...)
→ fiatToken.mint(...)
→ CoinManager.mint(...) precompile
→ Transfer(0x0, beneficiary, amount)
```

### Burn Execution Path

```
GovBase.executeProposal()
→ GovMinter._safeBurn(...)
→ fiatToken.burn(...)
→ CoinManager.burn(...) precompile
→ Transfer(from, 0x0, amount)
```

Through these execution paths, native balances, fiat tokens, and event logs remain consistent, enabling both on-chain and off-chain auditing.