# Introduction

**Axorix** is an Ethereum token factory protocol that lets users deploy customizable ERC‑20 tokens, configure token behavior, interact with token functions, and launch liquidity through a simple dApp interface.

## What Axorix Provides

* **Easy Ethereum token deployment** — one transaction to the factory creates a fully working ERC‑20 token.
* **Customizable ERC‑20 tokens** — name, symbol, description, initial supply, buy fee, sell fee, fee wallet, and owner are all set at deploy time.
* **Factory‑based deployment** — the `TokenFactory` contract deploys `CustomERC20` instances and keeps an on‑chain registry of every token it has produced.
* **On‑chain configuration** — once deployed, the token's owner can adjust fees, fee wallet, description, fee exemptions, and AMM pair registrations directly through the contract.
* **dApp interaction** — a frontend wraps the factory and token contracts so non‑developers can deploy, read, and manage tokens.
* **Uniswap V2 launch flow** — the dApp walks users through pairing their token with ETH on Uniswap V2 and registering the resulting pair on the token contract so buy/sell fees activate.
* **AI‑agent support** — a lightweight MCP server, hosted on the Axorix website, exposes contract‑aware tools that agents can call to read protocol state and **prepare** signed‑by‑user transactions.

## The Problem It Solves

Launching an ERC‑20 today usually requires writing or forking Solidity, compiling, verifying, and figuring out how to wire fees to a liquidity pool. Axorix collapses that into a single factory call with sane, audited defaults:

* Hard cap of **10%** on both buy and sell fees, enforced at the contract level — owners cannot turn a deployed Axorix token into a high‑fee honeypot after launch.
* Defense‑in‑depth validation: parameters are checked both in the factory and again in the token's constructor, so deploying the token contract directly is just as safe as going through the factory.
* Clean separation between **deployment** (factory) and **runtime configuration** (token owner), so the factory has no privileged role over your token after it ships.
* Fee logic gated on registered AMM pairs only — until the owner registers a Uniswap V2 pair, the token behaves like a standard fee‑less ERC‑20.

## Who It's For

| Audience                                    | What they get from Axorix                                                                                                                                       |
| ------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **End users** launching a token             | A guided dApp flow: fill a form, sign one transaction, get a deployed token with a tracked address.                                                             |
| **Developers integrating Axorix contracts** | Two small, readable contracts with a struct‑based API and full event coverage for indexing.                                                                     |
| **Frontend developers**                     | A predictable factory interface, a single `TokenCreated` event to listen for, and a token contract whose admin surface is just a handful of `set*` calls.       |
| **AI agents**                               | An MCP server that returns ready‑to‑sign transaction payloads for every meaningful action — never custodying keys.                                              |
| **Auditors and reviewers**                  | Two contracts totaling a few hundred lines, building only on OpenZeppelin's `ERC20` and `Ownable`, with explicit max‑fee bounds and no hidden privileged paths. |

## Scope of This Documentation

This documentation describes **only what is implemented in the attached contracts**:

* `TokenFactory.sol` — the factory.
* `CustomERC20.sol` — the token deployed by the factory.

Anything that is part of the Axorix product but lives **outside** the contracts — the dApp UI, the Uniswap V2 launch flow, and the MCP server — is described as an integration on top of those contracts. Where the prompt mentions features that are not present in the contracts (for example, on‑chain Uniswap launching, deployment fees, blacklists, max‑wallet limits, multi‑chain registries), this is called out explicitly as an **integration note** or a **future feature**, not as protocol behavior.


---

# 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.axorixeth.com/introduction.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.