Mantra

Mantra requirements are a Native MANTRA Gas Balance and Correct Network Setup

Mantra requirements are a spendable MANTRA balance for network fees, a compatible wallet and the correct MANTRA Chain network. Mainnet activity uses native MANTRA, formerly OM, while Cosmos and EVM interfaces require different identifiers and address formats before the wallet signs a transaction.

Choosing the execution environment before funding

Two execution environments settle the first decision: Cosmos SDK actions use Keplr, while EVM applications use MetaMask or Rabby.

Keplr reads the Cosmos Chain Registry record and exposes a Bech32 account that starts with mantra1. That route fits native sends, Inter-Blockchain Communication transfers, delegation and other Cosmos SDK messages. A Ledger device can sign through Keplr while keeping the same network record. CosmJS and mantrachaind use the same chain identity when an application or operator builds the transaction outside the wallet. The account needs liquid MANTRA because delegated coins, contract tokens and balances under another address do not fund its fee.

MetaMask and Rabby use the EVM view, display a 0x address and sign EIP-155 transactions for Solidity contracts. ethers, Viem, Foundry, Hardhat and Remix also target this route. An application built for a Cosmos message expects the Bech32 account, while an EVM decentralized application requests the hexadecimal account. Choose the route named by the application before moving any balance.

Budgeting the MANTRA gas reserve

One spendable MANTRA balance must cover both the intended action and the fee quoted before signing.

One MANTRA equals 10^18 amantra, and the mainnet minimum gas price is 40 000 000 000 amantra for each gas unit. This 18-decimal base denomination explains why raw wallet and command-line values look large. A Cosmos fee multiplies the selected gas limit by the offered gas price. EVM wallets estimate resources through their own fee interface, then debit native MANTRA for the gas actually used. Contract execution, message count and stored-data changes raise the estimate.

Keep fee funds liquid. Staked MANTRA and ERC-20 wMANTRA do not replace the native balance controlled by the signing address.

Worked example: take these hypothetical changing inputs: a gas limit of 120 000 units, an offered gas price of 80 000 000 000 amantra per unit and a transfer amount of 3 MANTRA. Multiplying the first two values gives a submitted fee of 9 600 000 000 000 000 amantra. Dividing by 10^18 converts the fee to 0.0096 MANTRA. Adding the transfer produces a concrete funding requirement of 3.0096 MANTRA for that transaction.

Wallet simulation should replace those sample inputs before signing. The reserve changes when the gas limit, offered price or number of separately signed transactions changes.

Mainnet and Dukong identifiers

Two MANTRA Chain mainnet identifiers must agree with the wallet context: Cosmos chain ID mantra-1 and EVM chain ID 5888. Dukong testnet uses mantra-dukong-1 for Cosmos and 5887 for EVM. Mainnet also configures a 3-second commit timeout, although wallet display and transaction inclusion remain separate steps. Mixing a mainnet identifier with a Dukong network record sends the request to the wrong execution context. Use the Dukong pair only for an explicitly testnet action.

Address and key compatibility across both environments

One 20-byte account supports distinct renderings, with Bech32 used on the Cosmos side and hexadecimal used on the EVM side.

A standard EVM address appears as 0x followed by 40 hexadecimal characters, producing 42 visible characters in total. The Cosmos representation uses Bech32 with the human-readable prefix mantra, which produces the familiar mantra1 opening. The destination field determines the required rendering. An EVM contract field expects the hexadecimal form, while a native Cosmos bank send expects the Bech32 form. Comparing the first characters catches a format mismatch before signing.

MANTRA Chain registers the ethsecp256k1 key algorithm and SLIP-0044 coin type 60, matching Ethereum-style derivation. The same private key produces related 0x and mantra1 forms only when the account uses the EVM-compatible key type. An account created with the standard Cosmos secp256k1 key type lacks that conversion relationship. If one key must serve both views, create the compatible account first and fund the address that the selected application displays.

Reading OM and MANTRA labels after redenomination

One former OM unit became four MANTRA units at block 13000000, so legacy labels no longer identify the gas asset accurately.

The redenomination occurred on March 2, 2026 and changed the ticker from OM to MANTRA. It applied a non-dilutive 1:4 split and set the hard cap at 10 000 000 000 MANTRA. Holdings already on MANTRA Chain changed automatically. The native base denomination is amantra. Some immutable TokenFactory strings retain older uom text because an on-chain identifier cannot be renamed after creation.

A legacy OM label counts toward gas only when the underlying balance is native MANTRA on the selected MANTRA Chain address. ERC-20 OM on Ethereum, contract-based wMANTRA and a TokenFactory liquidity token are different assets and balances. This distinction matters whenever an older interface or transaction history displays the former ticker. Match the denomination and network identity before treating the number as spendable gas.

Wallet configuration fields that must agree

Four wallet fields establish an EVM connection, while Keplr imports the Cosmos record through its chain visibility controls.

MetaMask needs a network name, a remote procedure call endpoint, chain ID 5888 and currency symbol MANTRA. The name is descriptive; the chain ID controls signature replay protection under EIP-155. Rabby follows the same EVM identity. Keplr reaches the Cosmos side through Manage Chain Visibility, where selecting MANTRA imports the registered mantra-1 configuration. Ledger users approve the account through Keplr instead of entering a private key into the browser wallet. The wallet should display the expected address family before receiving funds.

Read the transaction preview before signing. It should show the intended chain, the expected address and a fee denominated in MANTRA or amantra. An ERC-20 amount belongs to a contract ledger and remains separate from native gas. Developers using ethers or Viem should confirm 5888; operators using CosmJS or mantrachaind should confirm mantra-1. Reconfigure the wallet when any field points to Dukong or another account.

Cartoon train beneath text about staying on track every day

What happens when the gas balance is too low?

Zero spendable MANTRA prevents a wallet from submitting a fee-bearing transfer, delegation or EVM contract call to MANTRA Chain.

A wallet stops during fee estimation when it cannot construct a funded transaction, or a node rejects the broadcast for insufficient funds. Sending the full displayed amount creates the same condition because the fee comes from that spendable balance. Delegated MANTRA remains outside the liquid balance, and wMANTRA held on a contract ledger does not substitute for native gas. Add MANTRA to the same signing address, then estimate again without changing the destination or application call. The same subject is covered in practice.

An out-of-gas response describes a different condition: the balance covered the proposed fee, but execution exceeded the gas limit. Increase the limit or let wallet simulation recalculate it. One EVM message also stands alone in its transaction, so two independent contract actions require two signatures and two gas charges unless the contract implements a valid multicall path. The funding requirement changes with the final execution path.

Matching requirements to the intended action

Three activity types map to three setups: Cosmos transactions, EVM interactions and Dukong testnet development workflows. Native transfers, IBC messages and staking require Keplr, a mantra1 address, chain ID mantra-1 and liquid MANTRA. Contract calls require MetaMask or Rabby, a 0x address, EVM ID 5888 and native MANTRA for gas. Testing uses Dukong identifiers 5887 and mantra-dukong-1 with faucet-issued test tokens. Faucet assets serve testing only and never carry a mainnet fee balance. These Mantra requirements follow the execution environment selected by the application.

Can USDC, wMANTRA or an IBC asset replace native MANTRA for gas?

No. MANTRA Chain registers amantra, the base denomination of native MANTRA, as its fee token. USDC, Inter-Blockchain Communication assets and ERC-20 wMANTRA occupy separate balances and do not satisfy a fee request from the native signing account. Keep a small liquid MANTRA amount at the address that signs the transaction, even when the application action primarily uses another token.

Does adding MANTRA Chain to Keplr create a separate recovery phrase?

No. Adding chain visibility derives a MANTRA account from the wallet key already loaded in Keplr. It does not create a new recovery phrase unless the user deliberately creates or imports another wallet. A Ledger-backed account still uses Ledger to approve signatures. After adding the chain, compare the displayed mantra1 address with the receiving address before funding it.

Where does Ledger fit into a Keplr-based MANTRA setup?

Ledger works as the signing device while Keplr provides the MANTRA Chain interface. Add MANTRA mainnet in Keplr, open the corresponding Ledger-backed account and confirm the mantra1 address before receiving funds. Keplr prepares the Cosmos transaction, but approval happens on the Ledger device. The same liquid MANTRA fee requirement applies to that account.

What does gas adjustment change in mantrachaind?

Gas adjustment multiplies the result of automatic gas simulation to set a higher gas limit. It does not change the gas price, asset denomination or transfer amount. With --gas auto, a factor such as 1.2 adds 20 percent headroom to the simulated estimate; it is an input rather than a universal MANTRA requirement. The final fee follows the submitted limit and price.

Are Dukong faucet tokens usable on MANTRA mainnet?

No. Dukong faucet tokens exist on testnet and cannot fund a mainnet transaction. Dukong uses EVM ID 5887 and Cosmos ID mantra-dukong-1, while mainnet uses 5888 and mantra-1. A testnet balance cannot pay a mainnet fee because the ledger and chain context are separate. Switch to the intended network and fund that address with the native asset for that environment.