> For the complete documentation index, see [llms.txt](https://harmonic-protocol-1.gitbook.io/documentation/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://harmonic-protocol-1.gitbook.io/documentation/how-it-works.md).

# How it works?

#### Minting $HARMO

At launch, Harmonic introduces a **presale phase** with a total cap of **$100,000 USDC**. During this phase, users can mint $HARMO tokens directly through the protocol interface using the **Mint** page.

Each mint request follows the same x402 mechanism as trading - fully **gasless**, human-validated, and transparent:

1. **Choose Mint Amount:** Select a preset USDC amount (25, 50, 100, or 250 USDC).
2. **Set Validator Tip:** Add a tip in USDC (minimum 1). Higher tips could result in faster validation.
3. **Sign & Submit:** Sign your mint request; it enters the public mempool.
4. **Validator Execution:** Validators compete to execute your mint and earn your tip.
5. **Receive $HARMO Tokens:** Tokens are minted and sent to your wallet instantly.

Minting is completely non-custodial - your USDC is only debited after the mint is successfully executed on-chain. All tips are distributed 100% to the executors, while **no gas fees are required from you**.

> **Note:** This initial mint phase serves as the first liquidity entry point for $HARMO. Once the presale cap of 100k USDC is reached, minting will be disabled and secondary trading will open through the main Harmonic Protocol.

#### The Trading Flow

1. A user submits a trade request through the Harmonic dApp: amount, slippage, and tip.
2. The dApp sends a signed 402 request to Harmonic’s backend.
3. The backend places it in the **public mempool**, visible to everyone on our dApp.
4. A validator selects a transaction, solves a CAPTCHA, and executes it using the provided signatures.
5. The trade is settled, rewards are distributed, and the transaction disappears from the queue.

All swaps are executed by the **Harmonic router**, which holds the user’s permission to transfer USDC ↔ tokens once the signed 402 request is validated.

Every transaction must be validated by a human solving a CAPTCHA — ensuring that trades are intentionally executed, not front-run or spammed.

Validators can:

* Choose which transactions to process.
* Earn USDC rewards per validation.
* Increase their earnings by holding $HARMO tokens.

#### Tip & Prioritization

Each 402 trade includes a **tip,** an incentive paid to the validator who executes it.

Higher tip make your trade more likely to be picked and confirmed quickly.

* 100% of the tip goes directly to the validator.
* Validators can filter the mempool through tip size to focus on the most profitable trades.

Please note that the minimum bribe is 1 USDC to ensure that validators are in profit on every transaction even if they don’t hold $HARMO tokens.

#### Mempool Interface

The Harmonic app features a live view of all pending 402 requests.

Each entry displays:

* Transaction amount (in USDC)
* Tip value
* Status (pending / taken / executed)

Validators can sort and filter transactions by:

* Highest tip
* Transaction amount
* Request age

Once a transaction is validated, it disappears from the mempool and is permanently recorded on Base.


---

# 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://harmonic-protocol-1.gitbook.io/documentation/how-it-works.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.