NEM (XEM) Price

XEM is the native currency of the NEM NIS1 network, used for transfers and fees for on-chain operations; it is not XYM on the Symbol network. NEM NIS1 and the later Symbol are two coexisting networks, so holding XEM does not mean holding XYM, and their addresses, networks, and asset balances cannot be used interchangeably. This distinction was especially important when Symbol launched: the original NIS1 chain retained XEM, while Symbol issued its own XYM. NIS1 accounts with XEM that met the conditions at the time could receive XYM through a separate opt-in distribution, rather than having XEM in their accounts automatically replaced.

XEM's protocol supply is not continuously created through block production: official documentation states that 100% of XEM was issued in the genesis block. The technical reference gives a supply of 8,999,999,999 XEM, so harvesting a new block does not itself mint new XEM. This should be distinguished from “earning harvesting rewards.” In NIS1, transaction fees already paid in a block go to the account that successfully harvests that block. Network activity can therefore affect the total fees available for distribution, but it does not change the genesis issuance fact. Another 10,000,000 XEM is described in the documentation as program funds reserved for the Supernode Program; this is not block-based additional issuance either.

Harvesting is the NEM NIS1 process for producing blocks and receiving the transaction fees in a block. PoI (Proof-of-Importance) first calculates importance for eligible accounts; the higher an account's importance, the greater its chance of harvesting a block. When harvesting succeeds, the reward comes from fees already paid by transactions included in that block, not from newly issued XEM. PoI does not treat an account's total balance as its only input. An account must first meet the vested-balance threshold. The technical reference also builds transaction relationships from recent value transfers among eligible accounts: an included transfer must be at least 1,000 XEM, have occurred within the most recent 43,200 blocks (about 30 days), and have an eligible recipient. This relationship and the vested balance both feed into importance calculation, so “how much one holds” does not guarantee a particular harvest.

An account needs at least 10,000 vested XEM to enter PoI importance calculation and become eligible for harvesting; the same amount of unvested XEM does not satisfy this condition. This threshold determines eligibility to participate in importance calculation, not a fixed return promise. XEM newly transferred into an account initially forms an unvested balance. The documentation specifies that after every 1,440 blocks, 1/10 of the remaining unvested portion becomes vested; vesting therefore does not finish all at once, but converts progressively from a shrinking remaining unvested balance. If a transfer occurs, vested and unvested portions are used together in their original proportions, so the balance cannot simply be understood as “spending only the unvested portion.”

With local harvesting, a device running a local NIS node signs and harvests for the main account, so the device must remain running. Using a main-account private key directly on a remote NIS would expose a key that controls funds to a remote server, which is why the protocol does not allow that practice. Delegated harvesting first initiates an on-chain “importance transfer,” mapping the main account's importance to a proxy account with a zero balance. Once the transfer is accepted, it requires 360 confirmations to complete; before completion only the original account can harvest, and afterward the proxy account harvests. The remote node receives only the proxy account's private key to sign blocks, while fees are still paid directly to the original main account. Because the proxy account has a zero balance and cannot move funds from the main account, the principal risk if the remote node is compromised is that it cannot harvest properly on the account's behalf, rather than direct theft of the main account's XEM.

An XEM transfer fee is determined by the network resources used by the transaction, rather than being a single fixed charge for making a transfer. The technical reference splits the ordinary transfer fee into two added components: the amount component is 0.05 XEM for every 10,000 XEM transferred, capped at 1.25 XEM; the message component is 0.05 XEM for every started 32 bytes. Therefore, the final fee = amount component + message component. Without a message, the second component does not arise; the longer the message, the more fees accrue in upward-rounded “per started 32 bytes” increments. This formula describes the protocol basis for ordinary NIS1 transfers and should not be confused with withdrawal fees independently set by trading platforms.

The actual Symbol snapshot occurred on March 12, 2021, at NIS1 block height 3,105,500; Symbol then launched on March 16. A plan for January 14, 2021 and height 3,025,200 had previously been announced, but that plan did not become the actual snapshot or launch event because the launch was delayed. This arrangement was not a migration or swap of XEM for XYM. XEM remained on the original NIS1 chain. NIS1 accounts that held at least 100 XEM at the snapshot and had completed opt-in before launch received an equal amount of XYM. The opt-in linked a future Symbol account, and distribution was based on the balance at the snapshot height, not XEM bought, sold, or transferred afterward; therefore, a current XEM balance cannot by itself establish that XYM can still be obtained through the same pre-launch process.

When XEM is sent, the transaction signed by the sender first enters the network and is then included in a block by a harvester. If it is not included before its set deadline, the protocol treats it as expired and nodes discard it. Thus, “submitted” does not mean “confirmed in a block.” In practice, first verify that the destination network is NEM NIS1, along with the recipient address and amount, and reserve enough XEM to cover the transaction fee. If the transaction includes a message, note that message length changes the fee. Once a transaction has been included, it cannot be unilaterally withdrawn through an on-chain mechanism, so the address, amount, and message should all be confirmed before signing.

The smallest representable XEM unit is 0.000001 XEM, meaning 1 XEM can be divided into 1,000,000 smallest units. The protocol records amounts as integer smallest units and displays them to six decimal places, so small transfers and fee calculations do not depend on floating-point rounding. This precision only describes the representational capability of the NIS1 asset unit; it does not determine whether a transaction will be accepted by the network. Sending must still satisfy conditions including available balance, the fee for that transaction, and transaction format.