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

# MFY Token

Technical overview of the MFY Token, including contract address, supply, decimals, burn functionality, and on-chain verification.

The MFY Token is the core digital asset of the MFY ecosystem.

Deployed on Polygon PoS as an ERC-20 compatible token, MFY is designed to support the protocol’s participation mechanics, ecosystem interactions, liquidity-related components, decentralized tools, and future utility layers.

The token contract is publicly visible on PolygonScan, allowing users, developers, community members, and technical reviewers to inspect important token information directly on-chain.

***

### Token Details

| Item                          | Information                                  |
| ----------------------------- | -------------------------------------------- |
| Token                         | MFY Token                                    |
| Network                       | Polygon PoS                                  |
| Token Standard                | ERC-20 compatible                            |
| Contract Address              | `0x20cf65451376f1c6BC8DE2EC29042e14F4062716` |
| Decimals                      | `18`                                         |
| Current Observed Total Supply | `499,987,678.51303068... MFY Token`          |
| Source Code                   | Verified on PolygonScan                      |
| Verification Type             | Exact Match                                  |

***

### Contract Address

The official MFY Token contract address on Polygon PoS is:

`0x20cf65451376f1c6BC8DE2EC29042e14F4062716`

Users should always verify the contract address before interacting with MFY through wallets, decentralized exchanges, blockchain explorers, or third-party tools.

Using the wrong contract address may expose users to fake tokens, phishing attempts, or unrelated assets.

***

### Decimals

MFY uses `18` decimals.

This is the common ERC-20 convention used by many Ethereum-compatible tokens and allows balances, transfers, and contract interactions to be represented with high precision.

The `decimals()` function returns:

`18`

***

### Total Supply

At the time of the observed on-chain reference, the MFY Token contract showed a total supply of approximately:

`499,987,678.51303068 MFY Token`

The raw `totalSupply()` value returned by the contract was:

`499987678513030687126341480`

Because MFY uses 18 decimals, the user-readable supply is obtained by dividing the raw value by `10^18`.

> **Supply Note**
>
> MFY includes burn functionality. Because burned tokens are permanently removed from circulation, total supply values should always be verified directly on-chain for the most current information.

***

### Burn Functionality

The MFY Token contract includes burn-related functions through ERC20Burnable components.

The observed write contract interface includes:

* `burn`
* `burnFrom`

Burning permanently removes tokens from circulation according to the contract rules. Burn activity can be verified through on-chain transactions and may reduce the total supply over time.

This supports the protocol’s transparency model, where supply-related changes can be inspected through public blockchain data.

***

### Ownership

The MFY Token contract includes ownership-related functions through an Ownable structure.

The observed contract interface includes:

* `owner`
* `renounceOwnership`
* `transferOwnership`

At the time of the observed on-chain reference, the `owner()` function returned:

`0x23415EC861310e982FD37FA30112C0D448f4B453`

This means contract ownership was associated with this address at the time of observation.

Any future ownership change, transfer, or renouncement should always be verified directly on-chain through PolygonScan.

***

### Mint Function Visibility

Based on the observed Write Contract interface, there was no visible public `mint` function listed for the MFY Token contract.

The visible write functions included standard ERC-20 operations, burn functions, ownership controls, and a pool-related authorization function.

> **Important Technical Note**
>
> “No visible public mint function” means that the observed PolygonScan write interface did not display a public mint function. Technical reviewers should always inspect the verified source code directly before making deeper assumptions about contract behavior.

***

### Pool-related Functionality

The MFY Token contract also exposes pool-related functions, including:

* `isV3Pool`
* `isAuthorizedPoolSender`
* `setAuthorizedPoolSender`

These functions indicate the presence of pool-related logic within the contract structure.

Because pool-related behavior may depend on contract rules and authorized addresses, users and reviewers should inspect the verified source code directly before making assumptions about how these functions are used within the ecosystem.

***

### Verified Source Code

The MFY Token contract source code is verified on PolygonScan as an exact match.

This means the published source code corresponds to the deployed bytecode, allowing independent review of the contract structure and available functions.

The observed technical configuration includes:

| Item               | Information             |
| ------------------ | ----------------------- |
| Contract Name      | MFY                     |
| Compiler Version   | Solidity `v0.8.35`      |
| Optimization       | Enabled with `200` runs |
| EVM Version        | Cancun                  |
| Source Code Status | Verified                |
| Verification Type  | Exact Match             |

***

### OpenZeppelin-based Structure

The MFY Token contract uses well-known OpenZeppelin-based components, including ERC-20, ERC20Burnable, and Ownable modules.

These components provide standard token behavior such as:

* Token transfers
* Balance tracking
* Allowance and approval management
* Burn functionality
* Ownership-related controls

Using familiar contract components helps make the token structure easier to inspect and understand for developers and technical reviewers.

***

### Public Auditability

Because MFY is deployed on public blockchain infrastructure, users can inspect token-related information directly through PolygonScan.

This includes:

* Contract address
* Verified source code
* Total supply
* Holder data
* Token transfers
* Burn transactions
* Contract functions
* Ownership status
* Transaction history
* Pool-related interactions

MFY’s token layer is designed around open verification: users do not need to rely only on internal statements or private reporting to understand the token’s on-chain activity.

***

### Token Summary

The MFY Token is the foundation of the MFY ecosystem.

It provides the core asset layer for protocol participation, ecosystem mechanics, decentralized interactions, liquidity-related components, and future utility expansion.

Through Polygon PoS, verified source code, burn functionality, public contract functions, and transparent on-chain data, MFY aims to make its token layer inspectable, traceable, and independently verifiable.


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://mfytoken.gitbook.io/litepaper/protocol/mfy-token.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.
