chainslist is an EVM network directory that helps you find a network’s chain ID and RPC endpoint, then add that network to a compatible wallet. For a treasury team preparing payouts, the key question is which native currency the sending account needs to pay transaction fees, even when the payout itself uses a different token.
What Does chainslist Tell You About a Network?
chainslist helps you identify and connect to an EVM network using its chain ID and RPC endpoint. The chain ID distinguishes networks for transaction signing; an RPC endpoint is the address your wallet uses to read network data and submit transactions. Neither field, on its own, tells you what asset to keep for gas.
Suppose your team has been asked to make weekly payouts on Arbitrum One. Before funding the sending wallet, a chain list helps you distinguish Arbitrum One from another network with a similar name. chainslist gives you chain IDs and RPC endpoints to check and lets you add the selected network to MetaMask or another compatible wallet in one click. You can then review the wallet’s network details alongside the payout instruction.
Record the full network name and chain ID in the payout runbook, not only the ticker of the asset being sent. Arbitrum One, for example, has chain ID 42161. A token balance held by the same wallet address on another chain does not become an Arbitrum One balance when you add or select that network.
Which Asset Counts as the Native Currency?
The native currency is the asset the network uses for transaction fees, often called gas. It can differ from the token your team is transferring: a wallet may hold enough of the payout token but still be unable to send it because its native-currency balance is empty. The relevant balance must be on the network where the transaction will be signed and submitted.
On Arbitrum One, that fee asset is ETH. If the treasury receives ETH on Ethereum Mainnet, it cannot spend that particular balance on Arbitrum One; the team must obtain ETH on Arbitrum One through a supported withdrawal or bridge route. Likewise, receiving the payout token on Arbitrum One does not automatically supply the ETH needed to send it onward.
Do not infer the fee asset from a network’s name or from the token your business associates with it. Some EVM networks use a custom gas token, and networks built with related technology need not share a native currency. The deciding question is what the specific destination chain charges the sending account when it submits a transaction.
How Do You Confirm the Currency Before Funding?
Confirm the native currency in the network operator’s current documentation, then match its chain ID to the one you intend to add. Use chainslist RPC endpoints as connection details to review, while treating the operator’s published chain information as the check on the gas asset. This matters when names are similar or an internal payout request uses an informal network label.
The Ethereum Improvement Proposals document EIP-3085 describes the wallet request used to suggest adding an EVM chain. Its optional nativeCurrency field contains a name, symbol and decimal count, but that field is supplied as network metadata; a wallet may apply its own requirements or ignore parts of the request. A displayed symbol is therefore useful confirmation of what the wallet was told, not independent proof of what the chain charges.
For a team, the check is a short record: destination network, chain ID, native fee asset and the source used to confirm it. Keep that record with the payout setup so the person funding gas and the person approving transfers are using the same network definition. Recheck it when you introduce a new chain or change the RPC endpoint used by an automated process.
What Happens When You Add the Network to a Wallet?
Adding a network gives the wallet connection details; it does not move assets or fund transaction fees. The wallet can use the RPC endpoint to query balances and transaction data for the selected chain. When you submit a transfer, the transaction is signed for that chain ID, and the network charges the sending account according to its fee rules.
EIP-3085 calls this an add-chain request, and it does not require a wallet to switch to the new chain after accepting it. Check the active network before preparing a payout, even if the add request succeeded. Also inspect the network and chain ID shown for the transaction at approval time; the same-looking wallet address can exist on several EVM chains with separate balances.
Gas is a variable cost rather than a directory charge. As ethereum.org explains, an Ethereum Mainnet transfer uses 21,000 gas units, while a token transfer generally requires more work; the amount paid also depends on the fee per unit at the time. Layer 2 fees have their own calculations, so use a current wallet estimate for the actual transaction instead of copying a fixed ETH reserve from another network.
How Should a Team Prepare the First Payout?
Prepare the first payout by matching the recipient’s requested network, funding the native fee asset on that network and proving the route with a small transfer. For the Arbitrum One example, the runbook should say “Arbitrum One, chain ID 42161, ETH for gas” alongside the payout token and recipient address. That gives the operator a concrete set of fields to compare before signing.
Fund the sending wallet with enough native currency for the planned transfers and a margin for changing fee estimates. The amount depends on the number and type of transactions, current network fees and any later actions such as moving unused funds; there is no universal reserve that suits every payout batch. Keep the fee asset separate in your records from the token amount owed to recipients.
Send a small test payment on the intended network, then check its transaction record and the recipient’s confirmation before releasing the full batch. If the test does not arrive where expected, stop and compare the chain ID, token and receiving route rather than repeating the transfer. Before each run, ask: does the sending wallet hold the right fee asset on the exact chain the recipient expects?
Top comments (0)