Polygon is configured with chain ID 137, POL gas, and receipt checks

POL replaces MATIC in the wallet setup path

The POL migration is the wallet-facing change on Polygon PoS: POL now pays native gas, while mainnet keeps chain ID 137 and existing account addresses unchanged.

Native MATIC balances on Polygon PoS were converted to native POL at a 1:1 ratio, so no separate wallet transaction is required. Older custom records may label the unit MATIC because the currency symbol is local metadata. Editing it to POL corrects the display without modifying the balance. Native POL uses 18 decimal places: one POL contains 10^18 wei, and one gwei equals 10^9 wei. MetaMask, Rabby, Ledger-linked accounts, and applications using WalletConnect read the same chain state even when their labels differ. The corrected record lets fee quotes and balance deltas use the right unit.

Chain ID 137 separates Polygon state from Ethereum state

Chain selection is the signed transaction boundary between Polygon PoS and every other EVM network, including Ethereum mainnet. An EVM address contains 20 bytes and displays 40 hexadecimal characters after the 0x prefix, so the same account looks identical on chain ID 1 and chain ID 137. Its balances, token contracts, nonces, and transaction history remain chain-specific. An EIP-155 transaction signed for one chain ID is invalid on the other. Reading the active chain beside the account and recipient keeps the confirmation attached to the intended ledger.

Add Polygon PoS without duplicate network records

Network addition is a metadata workflow linking an EVM wallet to Polygon PoS; switching activates an entry the wallet already recognizes. MetaMask and Rabby support both operations, while WalletConnect carries the selected chain through an application session, as documented in Polygon pricing.

Manual identifiers

Polygon PoS mainnet uses decimal chain ID 137, expressed as 0x89 in hexadecimal JSON-RPC requests. A manual record needs the Polygon PoS name, POL symbol, 18 decimals, and an HTTPS RPC endpoint. The eth_chainId response from that endpoint must also be 0x89; a name or icon is not a protocol check. Polygonscan supplies the explorer view; explorer metadata does not control execution. EIP-3085 prevents multiple network entries with the same chain ID, so edit an outdated record or switch to the built-in entry instead of creating another 137 record.

Automated add and switch requests

An application uses wallet_addEthereumChain under EIP-3085 to propose chain metadata. A successful response is null, but it does not guarantee the new chain became active. The separate EIP-3326 wallet_switchEthereumChain request carries one chainId field, which should be 0x89 for Polygon mainnet. The wallet asks the user to authorize that switch, keeping application state and wallet state aligned.

Account and gas prerequisites

An EVM account, an approved wallet connection, and enough native POL for the displayed maximum cost are the normal prerequisites. A Ledger account can sign through MetaMask or Rabby, while a WalletConnect session still relies on the connected wallet for authorization. USDC and other ERC-20 balances do not pay protocol gas unless the application uses a relayer or paymaster to sponsor it. Meeting these inputs turns network metadata into a usable transaction path.

Read the confirmation screen as a state-change proposal

The confirmation panel is the last structured view of the Polygon action before a wallet produces a signature. First distinguish an off-chain message signature from an on-chain transaction carrying a gas estimate and executable data.

• The active account and chain ID 137.
• The recipient or contract address, shown as 42 characters including the 0x prefix.
• The POL value or token amount, with its displayed unit.
• The decoded method, such as transfer or approve, plus the spender and allowance when relevant.
• The gas limit, maximum fee per gas, priority fee, and maximum total cost.

For a native transfer, the transaction value is POL. For an ERC-20 transfer, the raw to field points to the token contract, while the intended recipient and amount sit inside calldata. Native USDC uses 6 decimals, whereas POL uses 18, so equal-looking integers represent different display amounts. An approve call changes allowance without moving the approved tokens at confirmation time. MetaMask and Rabby decode contract calls to different depths; matching the method, contract, account, and fee ties the signature to the intended state change.

How much POL should the wallet hold for gas?

A gas reserve is the POL balance available to cover the confirmation screen’s maximum transaction cost. Polygon PoS mainnet enforces a 25 gwei minimum priority fee, while Polygon Gas Station and EIP-1559 wallets estimate the moving base fee and gas limit.

Worked example. All changing inputs in this hypothetical fee display are illustrative: the wallet sets a 25,000 gas limit and a 40 gwei maximum fee, while execution uses 21,000 gas with a 5 gwei base fee and the 25 gwei minimum priority fee. The maximum reservation is 25,000 × 40 gwei, or 0.001 POL. The actual fee is 21,000 × 30 gwei, or 0.00063 POL. The wallet releases the unused gas allowance and the difference between the fee cap and the effective gas price.

The maxFeePerGas value is a ceiling, not the expected charge. Actual cost equals gasUsed multiplied by effectiveGasPrice, both recorded in the receipt after inclusion. Comparing the reserve, fee cap, and decoded action prevents a valid signature from failing solely because the account lacks enough POL.

What changed after the transaction executed?

An executed Polygon transaction is an EVM state transition: account balances, nonces, allowances, token ownership, and contract storage change only after successful execution. The transaction type determines which fields move.

In a native POL transfer, the recipient balance rises by the transfer amount, the sender balance falls by that amount plus the actual fee, and the sender nonce increases by exactly 1. An ERC-20 transfer changes balance records inside the token contract, while the sender’s native POL pays gas. An approval changes the spender allowance rather than transferring the token. An ERC-721 transfer updates the owner record for one token ID; ERC-1155 changes balances for one or more IDs. Receipt status 0x1 records successful execution, so these changes survive in the resulting state.

An included transaction with receipt status 0x0 reverts its requested contract and balance changes, yet it charges gas and consumes the sender’s nonce. A user rejection creates no transaction hash and no on-chain change. A pending hash has no receipt yet, so the interface cannot claim an executed state transition from submission alone. These distinctions tell the reader whether to retry an action, refresh a read, or inspect a completed failure.

Verify the receipt, balances, and token events

Receipt verification is the three-layer check connecting a Polygon transaction hash to execution status, account deltas, and contract events. Each layer answers a different confirmation question.

Transaction receipt

A transaction hash is 32 bytes, displayed as 64 hexadecimal characters after 0x. The JSON-RPC method eth_getTransactionReceipt returns null while no receipt is available; after inclusion, inspect status, blockNumber, gasUsed, effectiveGasPrice, and logs. Polygonscan presents the same on-chain fields through an indexed interface, which helps separate a wallet display delay from missing execution.

Balance delta

A balance delta checks the intended asset rather than the ticker alone. For POL, compare the sender’s reduction with the transfer plus actual gas fee and the recipient’s increase with the transfer amount. For an ERC-20 action, read the token contract’s balance for both addresses. Reloading MetaMask or switching RPC endpoints refreshes cached presentation without creating another transaction.

Token event and finality

Contract logs provide a third record of the executed method. ERC-20 and ERC-721 transfers emit a Transfer event, while ERC-1155 uses TransferSingle or TransferBatch; an ERC-20 allowance update emits Approval. Polygon PoS milestone finality is designed to land within 2 to 5 seconds, using Heimdall block times of 1 to 2 seconds. A client can query the finalized block tag and compare that height with the receipt’s block number, rather than treating first display as finality.

Receipt status, the asset-specific balance delta, and the expected event together identify the completed state change. That combined record is stronger than a green interface label alone.

Recover from a chain ID or RPC mismatch

RPC recovery is a configuration repair for wallets that cannot switch to Polygon, return the wrong chain, or stop updating confirmed state. Start with the chain response because it separates metadata errors from endpoint availability.

Unknown chain response

MetaMask commonly returns code 4902 when a requested chain has not been added; that code is wallet-specific rather than part of EIP-1193. Request a switch to 0x89 first, add the EIP-3085 Polygon metadata only after the unknown-chain response, and then request the switch again. Code 4001 means the user rejected the prompt, so a new request belongs behind a fresh user action rather than an automatic loop.

Endpoint returns the wrong chain

Call eth_chainId through the configured endpoint before changing transaction settings. A Polygon mainnet endpoint must return 0x89; 0x1 identifies Ethereum mainnet, and no response points to connectivity or provider availability. Select the wallet’s built-in Polygon entry or replace the endpoint inside the existing chain ID 137 record, then reconnect the application. EIP-1193 code 4900 means the provider is disconnected from all chains, whereas 4901 means it cannot service the requested chain. A matching response restores reliable balance and receipt reads.

Pending nonces, approvals, and asset context

Advanced wallet handling is nonce, allowance, and asset-context management after the basic Polygon path works. A pending transaction at nonce N blocks later transaction N+1 from the same account; a replacement uses nonce N with a higher viable fee. An ERC-20 approval remains active until another approval changes it, and setting the allowance to zero removes that permission. Native POL, wrapped POL (WPOL), and USDC occupy different balance records, so chain ID 137 plus the token contract identifies the asset the interface should display.