# Function Interface for Token Contract

### Function: mint

Your contract should include the `mint` function. Here is the signature:

```solidity
function mint(
    address to,
    uint256 amount
) external onlyMinter;
```

This function creates new tokens and adds them to the total supply. The parameters are:

* `address to`: The address to receive the newly minted tokens.
* `uint256 amount`: The amount of tokens to be minted and sent to the designated address.

Here is a brief implementation example of the `mint` function using OpenZeppelin's ERC20 library:

```solidity
// Using OpenZeppelin's ERC20
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    // ...
    function mint(address to, uint256 amount) public onlyMinter {
        _mint(to, amount);
    }
}
```

The `onlyMinter` modifier restricts access to the `mint` function to authorized minters only, ensuring control over the creation of new tokens.

This `mint` function is key to the effective operation of cross-chain transfers within our system. By minting tokens on the destination chain that correspond tokens burnt on the source chain, the `mint` function ensures that total token supply remains consistent across all chains

### Accessing the Minter Role

In order to use the `mint` function, you will need to provide **our relay contract** with permission to pass the `onlyMinter` check. This necessitates the inclusion of a function in your contract that enables the assignment of the minter role.

Possible options are:

1. **Mapping for Minters**: Use a mapping in your contract to track the minter access of addresses. 
2. **Grant Role Function**: Use a function in your contract that allows a specific role, such as an owner or admin, to grant the minter role. This can be done using a role-based access control library like OpenZeppelin's Access Control library.

### Function: burn

Your contract should also implement a `burn` function for token destruction. We expect this function will burn/remove a certain amount of tokens. We currently support the two interfaces for burn function:

#### XYERC20 (V1)

```solidity
function burn(
    uint256 amount
) external;
```

This `burn` function should destroy a specified amount of tokens from the `msg.sender`'s balance. The parameter is:

* `uint256 amount`: The number of tokens to be burnt or destroyed.

Here is a brief implementation of the `burn` function using OpenZeppelin's ERC20 library:

```solidity
// Using OpenZeppelin's ERC20
import "@openzeppelin/contracts/token/ERC20/ERC20.sol";

contract MyToken is ERC20 {
    // ...
    function burn(uint256 amount) external {
        _burn(msg.sender, amount);
    }
}
```

In this example, the `_burn` function, a part of OpenZeppelin's ERC20 library, is used to burn tokens. It deducts the `amount` from `msg.sender`'s balance and reduces the total supply of tokens accordingly.

#### XYERC20 (V2)

```solidity
function burn(
    address account,
    uint256 amount
) external onlyMinter;
```

This `burn` function should destroy a specified amount of tokens from the `account`'s balance. The parameters are:

* `address account`: The address of the account from which the tokens will be burned.
* `uint256 amount`: The number of tokens to be burnt or destroyed.

Make sure you add the `onlyMinter` modifier or such access control function to protect this burn function, and you will need to provide **our relay contract** with permission to pass the `onlyMinter` check as well.

***

The `burn` function empowers your contract to maintain the integrity of the token's supply when tokens are sent across different blockchains.


---

# 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.xy.finance/single-bridge-integration/xasset-bridge/how-to-develop-under-xy-standards/function-interface-for-token-contract.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.