Skip to main content

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

AccessManagedUpgradeable ties mint/upgrade authority to the central AccessManager; no local roles are defined.

Initialization

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

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

Any holder can burn their own tokens. burnFrom requires allowance. The contract also exposes a protocol-burn path:
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)

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:
Any mint above the cap reverts.

Access control summary

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: 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:
Emitted in addition to the standard transfer event for explicit mint/burn accounting.

SDK usage

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).