Refactor MNTs to NTs

EIPS/eip-7809.md

@@ -14,9 +14,9 @@ requires: 2718, 2930
 ## Abstract
 
 This EIP introduces Native Tokens (NTs) as a backward-compatible extension of the EVM, enabling
-fungible tokens to function with native-like properties. Unlike ERC-20 tokens, MNTs are
+fungible tokens to function with native-like properties. Unlike ERC-20 tokens, NTs are
 integrated into the global VM state, allowing for direct transfers through newly defined opcodes and eliminating the
-traditional two-step "approve" and "transfer" pattern. Ether (ETH) is designated as one of the MNTs while retaining its
+traditional two-step "approve" and "transfer" pattern. Ether (ETH) is designated as one of the NTs while retaining its
 unique role as the exclusive token for gas fee payments. The EIP introduces the new opcodes `MINT`, `BURN`, `BALANCEOF`,
 and `CALLVALUES` to manage NT supply and query account balances. Additional opcodes such as `NTCALL`, `NTCALLCODE`,
 `NTCREATE`, and `NTCREATE2` facilitate NT transfers and NT-infused contract creation. Existing opcodes and transactions
@@ -283,36 +283,36 @@ This EIP does not introduce any breaking changes to the existing Ethereum protoc
 functionality that requires consideration across various layers of the ecosystem.
 
 - Front-end Ethereum libraries, such as web3.js and wagmi, will need to adapt to the new transaction structures introduced
-by MNTs. These libraries must update their interfaces and transaction handling mechanisms to accommodate the inclusion
+by NTs. These libraries must update their interfaces and transaction handling mechanisms to accommodate the inclusion
 of token transfers within smart contract calls and the absence of traditional "approve" and "transfer" functions.
 - Smart contract languages like Solidity will need to incorporate support for the newly introduced opcodes associated with
-MNTs. This includes adapting compilers and development environments to recognize and compile contracts that interact
+NTs. This includes adapting compilers and development environments to recognize and compile contracts that interact
 with tokens stored in the VM state.
-- Additionally, Ethereum wallets, block explorers, and development tools will require updates to fully support MNTs.
+- Additionally, Ethereum wallets, block explorers, and development tools will require updates to fully support NTs.
 Wallets must be capable of managing native token balances, signing new types of transactions, and displaying
 token information accurately. Explorers need to parse and present the new transaction formats and token states, while
 development tools should facilitate debugging and deployment in this enhanced environment.
 
 To ensure a smooth transition, the authors recommend a gradual deployment process. This phased approach allows
-developers, users, and infrastructure providers to adapt incrementally. By introducing MNTs in stages, the ecosystem can
+developers, users, and infrastructure providers to adapt incrementally. By introducing NTs in stages, the ecosystem can
 adjust to the new functionalities, verify compatibility, and address any issues that arise, ensuring that every
 component behaves correctly throughout the integration period.
 
 ## Reference Implementation
 
 The authors have begun implementing this EIP in Sablier's [SabVM repository](https://github.com/sablier-labs/sabvm), a
-fork of [REVM](https://github.com/bluealloy/revm) that supports MNTs. Unlike the proposed EIP, SabVM uses precompiles
+fork of [REVM](https://github.com/bluealloy/revm) that supports NTs. Unlike the proposed EIP, SabVM uses precompiles
 instead of opcodes because that was easier to implement at the time.
 
 A particularly relevant resource in SabVM is this
-[draft Solidity spec](https://github.com/sablier-labs/sabvm/discussions/87), which details support for MNTs in Solidity.
+[draft Solidity spec](https://github.com/sablier-labs/sabvm/discussions/87), which details support for NTs in Solidity.
 
 Additionally, the [SRFs repository](https://github.com/sablier-labs/SRFs) (Sablier Requests for Comments) hosts the
-SRF-20 standard: an application-level standard designed to replicate the ERC-20 standard specifically for MNTs.
+SRF-20 standard: an application-level standard designed to replicate the ERC-20 standard specifically for NTs.
 
 | Name   | Link                                                                     | Description                                                                       |
 | ------ | ------------------------------------------------------------------------ | --------------------------------------------------------------------------------- |
-| SabVM  | [github.com/sablier-labs/sabvm](https://github.com/sablier-labs/sabvm)   | Fork of REVM that implements MNTs with precompiles                                |
+| SabVM  | [github.com/sablier-labs/sabvm](https://github.com/sablier-labs/sabvm)   | Fork of REVM that implements NTs with precompiles                                |
 | SRFs   | [github.com/sablier-labs/SRFs](https://github.com/sablier-labs/SRFs)     | Sablier Requests for Comments                                                     |
 | stdlib | [github.com/sablier-labs/stdlib](https://github.com/sablier-labs/stdlib) | Sablier Standard Library, providing precompiles, standards, and testing utilities |