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

# Nota token

# NOTA Token

The `NOTA` token (Solidity name `NotareumNOTAToken`) is the ERC-20 utility and governance asset of the Notareum protocol. It pays registration and verification fees, collateralizes validator stakes, and, when locked as veNOTA, confers governance and reward-boost rights. The contract is a standard OpenZeppelin ERC-20 implementation with the IERC-2612 permit extension and governance-gated mint and burn controls.

## Key properties

* Name: `Notareum`
* Symbol: `NOTA`
* Decimals: `18`
* Total supply cap: `1,000,000,000 NOTA` (enforced at contract level)
* Post-genesis mint: governance-only, delay-gated
* Burn: permissionless (`burn`) and governance (`burnFrom`)
* Permit: EIP-2612 gasless approvals
* Votes extension: off (voting is via veNOTA, not raw NOTA)

## Inheritance

```solidity theme={"system"}
contract NotareumNOTAToken is
    ERC20Upgradeable,
    ERC20PermitUpgradeable,
    ERC20BurnableUpgradeable,
    AccessManagedUpgradeable,
    UUPSUpgradeable
{ }
```

`AccessManagedUpgradeable` ties mint/upgrade authority to the central [AccessManager](access-manager.md); no local roles are defined.

## Initialization

```solidity theme={"system"}
function initialize(
    address admin,           // AccessManager
    address genesisRecipient // receives the initial supply
) external initializer;
```

Initialization mints the genesis supply (1B NOTA) to `genesisRecipient`, typically a timelocked multisig that fans out to the allocations (validators, ecosystem, team, treasury). No further mints are possible until governance explicitly schedules one.

## Public interface

### ERC-20 surface

Standard: `transfer`, `transferFrom`, `approve`, `allowance`, `balanceOf`, `totalSupply`.

### ERC-2612 permit

```solidity theme={"system"}
function permit(
    address owner,
    address spender,
    uint256 value,
    uint256 deadline,
    uint8 v,
    bytes32 r,
    bytes32 s
) external;

function DOMAIN_SEPARATOR() external view returns (bytes32);
function nonces(address owner) external view returns (uint256);
```

This enables gasless approval flows: a user signs a typed permit off-chain; the relayer submits `permit` and the subsequent action (stake, pay fee) in a single transaction. The SDK wraps this in a `permitAndCall` helper.

### Burn

```solidity theme={"system"}
function burn(uint256 amount) public;
function burnFrom(address account, uint256 amount) public;
```

Any holder can burn their own tokens. `burnFrom` requires allowance. The contract also exposes a protocol-burn path:

```solidity theme={"system"}
function protocolBurn(address from, uint256 amount) external restricted;
```

restricted to the `FEE_MANAGER` role (held by `FeeManager`) to implement fee burns without needing holder consent (used for fees the contract collected in its own balance).

### Mint (post-launch)

```solidity theme={"system"}
function mint(address to, uint256 amount) external restricted;
```

Gated to the `MINTER` role, which is held by the treasury timelock and only grantable by a successful governance proposal. The total supply cap is enforced inside `mint`:

```solidity theme={"system"}
require(totalSupply() + amount <= MAX_SUPPLY, "NOTA: cap");
```

Any mint above the cap reverts.

## Access control summary

| Role          | Holder (post-launch) |             Delay |
| ------------- | -------------------- | ----------------: |
| `MINTER`      | Governance executor  |           14 days |
| `FEE_MANAGER` | FeeManager contract  | immutable at init |
| `UPGRADER`    | Governance executor  |           14 days |

The `FEE_MANAGER` wiring is set once during initialization and cannot be changed without upgrading the implementation. This constrains the contract's trust surface: the only entity that can burn from arbitrary addresses is the `FeeManager` contract itself.

## Allocation (illustrative)

The initial 1B NOTA supply distributes across buckets. Exact amounts are governance-ratified at genesis; the following reflects the default distribution described in the whitepaper:

| Bucket              | Share | Notes                                    |
| ------------------- | ----: | ---------------------------------------- |
| Validator rewards   |   30% | Vested over 5 years, emitted via staking |
| Ecosystem / grants  |   25% | Governance-controlled treasury           |
| Core contributors   |   18% | 4-year vesting, 1-year cliff             |
| Public distribution |   15% | Includes initial liquidity + airdrop     |
| Strategic backers   |    8% | 3-year vesting, 6-month cliff            |
| Foundation reserve  |    4% | Long-term operations                     |

All vesting schedules live in separate `NotareumVestingVault` instances parameterized at deployment. The token contract itself holds no custody logic.

## Events

Standard ERC-20 `Transfer` and `Approval` plus:

```solidity theme={"system"}
event Minted(address indexed to, uint256 amount);
event Burned(address indexed from, uint256 amount);
```

Emitted in addition to the standard transfer event for explicit mint/burn accounting.

## SDK usage

```typescript theme={"system"}
import { Notareum } from "@notareum/sdk";

const ntm = Notareum({ provider, signer, contracts });

const bal = await ntm.nota.balanceOf(addr);
const ts  = await ntm.nota.totalSupply();

// EIP-2612 permit
const sig = await ntm.nota.signPermit({
  spender: ntm.staking.address,
  value: parseNota("50000"),
  deadline: Math.floor(Date.now() / 1000) + 3600,
});
await ntm.staking.stakeWithPermit(parseNota("50000"), sig);

// Transfer
await ntm.nota.transfer(recipient, parseNota("100"));

// Burn
await ntm.nota.burn(parseNota("50"));
```

## Governance interaction

Mint and upgrade operations require a complete governance cycle:

1. Proposal submitted via veNOTA voting.
2. Proposal succeeds and enters the execution queue.
3. `AccessManager` timelock runs for 14 days.
4. Execution transaction lands on-chain.

This cadence prevents abrupt supply expansion or unilateral upgrades. Mint proposals typically bundle the vesting schedule and recipient rationale.

## Invariants

1. `totalSupply() <= MAX_SUPPLY` at all times.
2. Only addresses granted the `MINTER` role can call `mint`; the role itself is only reachable through a 14-day timelock.
3. `protocolBurn` is callable only by `FeeManager` and only against the contract's own balance or approved balances.
4. `transferFrom` from a zero-approval state reverts (standard ERC-20 semantics).

## Related pages

* [veNOTA](venota.md)
* [FeeManager](fee-manager.md)
* [AccessManager](access-manager.md)
* [Token Economics protocol doc](../token/overview.md)