Mantanetwork

Mantanetwork readiness on Manta Pacific requires network, gas, and contract checks before signing and receipt verification afterward

Select Manta Pacific in the wallet, confirm the intended account and expected chain ID, and keep enough ETH available for gas. Before the first signature, compare the asset contract, spender or recipient, and displayed call with the action you intend. Submit only a bounded transaction, then inspect its receipt and resulting state before deciding whether another action is warranted.

Keep the first action bounded and verify its result. That result should confirm the selected path or expose one specific mismatch before you grant broader permissions, transfer larger values, or submit more transactions.

Wallet network entries control where the first call goes

Start with an existing Manta Pacific wallet entry or a manually configured network. Either choice must resolve to Manta Pacific through the correct numeric identity. Manta Pacific mainnet uses chain ID 169. Changing an RPC endpoint changes where the wallet reads data and broadcasts calls, but it does not move balances between chains.

Chain selection changes the execution domain

The active network determines which account state, contracts, token balances, and transaction history the wallet reads. Confirm the selected account again after switching networks. A familiar address or token symbol does not correct a network mismatch, and a balance shown on another EVM chain is not available for a Manta Pacific call.

ETH funds execution

Manta Pacific charges transaction gas in ETH. The required amount depends on the gas consumed and the fee fields applied to that transaction; it is separate from any token amount being transferred. An account may hold the intended token yet remain unable to submit because its Manta Pacific ETH balance is too low. A separate approval, when required, also needs gas.


The account, asset contract, and call target must match the intended action

Readiness depends on three linked identities: the selected account, the asset contract on chain 169, and the recipient or contract that will receive the call. The wallet can display all three while one remains wrong. Check them as a set instead of treating a recognizable ticker or application screen as proof.

Token identity comes from the contract

An ERC-20 token’s identity combines its network and contract address. Names, symbols, and icons are metadata that another contract can copy. A bridged representation can also use a different address from the asset on its source chain. Match the address selected by the application with the Manta Pacific record you intended to use. Stop if those records cannot be reconciled.

Permissions target a spender, not a logo

A transfer names a recipient, while a contract interaction names the contract that receives the call. An ERC-20 approval adds another address: the spender allowed to use a stated allowance. The approval does not transfer the token by itself, but it changes an on-chain permission. Review both the spender and allowance. A broad allowance extends beyond one bounded action unless it is later reduced or revoked.


A transaction preview defines the first commitment

The confirmation window lets you reject the request before the wallet signs or submits it. Check the network, active account, target, transferred value, approval amount, and displayed gas requirement before signing. If the wallet identifies the requested method, it should fit the intended action. Rejecting an unexplained prompt changes no on-chain state.

Some wallets simulate a call before submission. A successful simulation can show that the call is executable against the state used for that preview, while a failed simulation may expose an immediate revert. Neither outcome guarantees later execution because balances, allowances, contract state, and fee conditions can change before inclusion. Treat the preview as a preflight check, not a receipt.

A transaction preview defines the first commitment: The confirmation window lets you reject the request before the wallet signs or submits it.; Check the network, active account, target, transferred value, approval amount, and displayed gas requirement before signing.; If the wallet identifies the requested method, it should fit the intended action. Rejecting an unexplained prompt changes no on-chain state.

Open full-size image


A receipt separates broadcast from completed execution

After broadcast, the transaction hash identifies the submitted transaction so the wallet or a Manta Pacific explorer can follow its status. The hash alone does not show that execution succeeded. Once the transaction is included in a block, inspect its receipt status and the state that the call was meant to change.

Pending is an unfinished state

A pending transaction has not produced a final execution record. Keep its hash and nonce, then inspect that transaction before sending a duplicate. A second call may use another nonce and wait behind the first, or it may attempt to replace the original when the wallet supports replacement. Those are different actions, so a stalled interface should not trigger an automatic resubmission.

Receipt status and application state answer different questions

A successful receipt means the EVM call did not revert. Event logs and the resulting balance, allowance, ownership record, or application state show what the call actually changed. A failed receipt records execution without the intended state change. If the action starts a later process, its first receipt proves only that initial step; inspect the relevant later state before treating the broader task as complete.


A mismatch calls for the smallest recovery step

When a check fails, change only the prerequisite that explains the failure. Rebuilding several inputs at once can hide the original cause and create a different transaction from the one already reviewed.

A wrong network or account requires a fresh unsigned request after the correct selection. Do not approve a confirmation window that remained open through the switch. Recheck the target contract because an application can prepare different calls for different networks.

A mismatch calls for the smallest recovery step: When a check fails, change only the prerequisite that explains the failure.; Rebuilding several inputs at once can hide the original cause and create a different transaction from the one already reviewed.

Open full-size image

An insufficient gas balance requires enough ETH on Manta Pacific before submission. A simulation revert needs a different response: inspect the stated error, current balance, allowance, and contract conditions. Raising the gas limit cannot repair a call that fails because its authorization or state requirement is not satisfied.

If a receipt succeeds but the interface remains unchanged, compare the account, chain, transaction hash, and resulting on-chain state. Refreshing the read path is smaller and safer than repeating a successful write. A pending transaction still needs its original status resolved before another nonce-dependent action begins.


The wallet and transaction request must describe the same action before signing

Check each condition before signing one bounded action:

Apply this checklist to one signature only; it does not validate later requests. After a successful receipt and expected state change, decide whether another transaction advances the same task. If it does not, end the session. If it does, review the new call on its own facts because the recipient, allowance, and contract state can change.

The wallet and transaction request must describe the same action before signing: Apply this checklist to one signature only; it does not validate later requests. After a successful receipt and expected state change, decide whether another transaction advances the same task.; If it does not, end the session. If it does, review the new call on its own facts because the recipient, allowance, and contract state can change.

Open full-size image

Useful questions about Mantanetwork

Can connecting a wallet move funds from my Manta Pacific account?

No, connecting a wallet does not create an on-chain transfer or token allowance by itself. It usually shares the selected public address and network with the application. A later transaction or signature request is a separate decision. Read each prompt because an application may request a message signature, approval, or transfer immediately after connection.

Is signing a message the same as sending a Manta Pacific transaction?

No, a message signature is normally created off-chain and does not consume transaction gas. It can still authorize a login, order, permit, or other action defined by the signed data. An on-chain transaction is broadcast to Manta Pacific, uses a nonce, consumes ETH for gas when included, and produces a transaction receipt.

Does adding a token to the wallet grant an allowance?

No, importing a token only tells the wallet which contract balance and metadata to display. It does not give another address permission to spend that token. An allowance requires an on-chain approval transaction or a supported permit-style signature. Confirm the token contract before importing it because a copied symbol does not establish identity.

What happens to gas if the first transaction reverts?

A reverted transaction that reaches a block normally consumes ETH for the computation already performed, even though its intended state changes are discarded. Unused gas is not charged as if it had been consumed. A request rejected before broadcast or inclusion does not create the same on-chain gas charge, so check whether a receipt exists.

Will disconnecting the wallet cancel an ERC-20 approval?

No, disconnecting removes the application’s current wallet connection but does not erase an allowance recorded on Manta Pacific. The approval remains until it is spent, reduced, revoked, or otherwise changed through the token contract. Revoking it requires a separate Manta Pacific transaction, so the account also needs ETH for that gas.

Updated on