Monad is configured with chain ID 143 for wallet transfers

Monad is an EVM-compatible Layer 1 where mainnet wallet transactions use chain ID 143 and MON for both transfer value and gas. Select Monad in a supported wallet, or add the network manually, then confirm the receiving address, amount, gas limit, and fee caps before signing. After broadcast, match the 32-byte transaction hash in MonadVision or Monadscan and read the receipt status, block number, gas charged, and balance changes.

Why does the wallet show chain ID 10143 instead of 143?

Chain ID 10143 identifies Monad testnet, while chain ID 143 identifies mainnet; edit the saved entry or select mainnet before preparing a real transfer request. Monad mainnet uses decimal chain ID 143, which JSON-RPC returns as hexadecimal 0x8f.

Testnet and mainnet keep separate balances, nonces, receipts, and contract state even when the wallet displays the same 20-byte account address. If 10143 appears, cancel the unsigned request, open the wallet’s network settings, and choose the saved Monad mainnet entry. For a manual entry, replace 10143 with 143 and reconnect the application so it rebuilds the transaction. A direct RPC check through eth_chainId should return 0x8f. Do not edit a request already signed; preserve its 32-byte hash and inspect the network where it was broadcast.

A request still awaiting signature has made no on-chain change, so correcting the network and rebuilding it is sufficient.

Add Monad mainnet before preparing the transfer

Five visible fields establish a manual Monad mainnet connection: network name Monad, chain ID 143, one active RPC endpoint, currency symbol MON, and an explorer entry. The explorer field is optional for signing, but it gives the wallet a direct receipt view.

MetaMask provides native Monad support and also accepts custom EVM networks. Rabby Wallet, Rainbow, Trust Wallet, Backpack, OKX Wallet, and Uniswap Wallet support the chain through their network selectors. An automatic entry saves typing, while a manual entry exposes every field for inspection. Both methods should resolve to 143 before the wallet creates a signature. Use MonadVision or Monadscan as the named explorer; either can look up the same transaction hash.

Saving the entry modifies wallet configuration only; it does not create an account or move funds.

Choose the wallet’s built-in Monad entry when available, and reserve manual configuration for a missing or incorrect saved network.

Four prerequisites for a signable transfer

Four prerequisites make a Monad transfer signable: the correct account, chain ID 143, a valid 20-byte recipient address, and enough MON for value plus gas. The sender needs a spendable balance, while the recipient only needs a valid address.

Monad reuses Ethereum’s address space, so an externally owned account is 20 bytes: 40 hexadecimal characters, or 42 characters after the 0x prefix. ERC-55 checksum capitalization improves error detection without changing those bytes. Wallet interfaces display MON with 18 decimal places, while JSON-RPC quantities use integer wei; 1 MON equals 10^18 wei. Enter the amount in the wallet’s displayed unit, confirm the recipient resolves to the intended 20-byte address, and leave enough balance for the selected gas limit. The recipient needs no MON merely to receive a plain native transfer.

What should you check before signing?

Six confirmation values deserve a deliberate check before the wallet signs: chain ID 143, sender, 20-byte recipient, amount, gas limit, and type 2 fee caps. Every visible value maps to part of the signed request.

An ordinary EIP-1559 transfer uses transaction type 2, one of four types Monad supports alongside types 0, 1, and 4. Its typed envelope starts with 0x02, and the signed payload carries chain ID, nonce, two fee fields, gas limit, destination, value, data, access list, and three signature components. The wallet derives the sender from the signing key, so compare the selected account as carefully as the recipient.

For a plain MON transfer to an externally owned account, data should be empty, value is the intended amount, and the recipient is the address shown. A contract call may carry calldata and display an action summary instead. Monad charges the full gas limit, so a surprisingly large limit deserves correction before signing. The maximum fee per gas is a ceiling; the effective price is determined at inclusion.

Once every field agrees, sign once and retain the resulting hash.

Seven verification views for one transaction

Seven independent tools and methods answer different verification questions after Monad broadcasts a 32-byte transaction hash, from simple inclusion checks to decoded calls and pending-state inspection. A hash contains 64 hex digits and spans 66 characters with its 0x prefix.

For a plain wallet transfer, begin with MonadVision or Monadscan and match the full hash, sender, recipient, value, status, and block number. A contract interaction benefits from Tenderly Explorer or Phalcon Explorer because call traces explain nested execution and balance movement. Automated verification should call eth_getTransactionReceipt; a non-null receipt proves inclusion and exposes the execution status. eth_getTransactionByHash confirms signed fields but does not establish success by itself. Before inclusion, txpool_statusByHash describes pending state. Re-query the same 32-byte hash after the receipt appears, then compare its block hash and transaction index.

What changes after the transfer executes?

Three durable state updates describe an included native transfer: the sender nonce rises by 1, balances move, and the receipt records one binary execution status. A successful receipt uses 0x1; an included failure uses 0x0.

On status 0x1, the recipient’s native balance increases by the transfer value. The sender’s balance falls by that value plus the network charge, and the account nonce advances exactly 1. A simple native transfer between externally owned accounts normally emits 0 contract logs because it changes protocol balances rather than calling an ERC-20 token contract. The receipt still records the transaction hash, block hash, block number, sender, recipient, gas limit context, effective gas price, and gas figures. Compare those fields with the signed request instead of relying on a wallet’s activity label alone.

If status is 0x0, the recipient does not receive the intended state change, yet the nonce still advances and Monad still charges the chosen gas limit. That distinction separates inclusion from successful execution. The next decision is whether to correct the call or prepare a new transfer with the next nonce.

From type 2 fee fields to the final charge

Four numbers govern the common type 2 fee decision on Monad: gas limit, base fee, priority fee, and the user’s maximum fee per gas cap. The effective price equals the smaller of the cap and the base fee plus priority fee.

A plain native transfer uses a 21,000 gas limit, Monad’s minimum base fee is 100 MON-gwei, and the protocol charges the full chosen gas limit. With a zero priority fee at the minimum base fee, 21,000 × 100 × 10^-9 MON equals 0.0021 MON. A positive priority fee raises the charge until the maximum fee cap binds.

For type 2, multiply the effective price per gas by the gas limit, not by gas used. The maximum fee is a ceiling rather than the automatic charge. If the cap sits below the base fee required for inclusion, the transaction remains pending until conditions or the signed transaction change.

The network’s transaction limit is 30,000,000 gas. Each block permits 200000000 gas, with a controller target of 160,000,000, or 80% fullness; the controller’s maximum step parameter is 1/28, and its smoothing beta is 0.96.

Set 21,000 for a plain native transfer, then decide whether the wallet’s priority fee matches the desired inclusion speed.

Monad FAQs