Mantra zone
Mantra zone links wallet actions to verifiable on-chain state changes
Mantra zone is a wallet-connected gateway to MANTRA Chain where users can swap tokens, provide liquidity, stake MANTRA and access mantraUSD. Each route starts from an existing wallet balance and requests a distinct on-chain change. It ends only when the network confirms the resulting balance, position or delegation. A pending wallet prompt isn't a completed action, and a success message should agree with the transaction record.
Routes and the state each one changes
Each featured route produces a different commitment. The expected output might be a validator delegation, a new token balance, a pool position or a converted asset.
Staking positions and rewards
Staking changes spendable MANTRA into a delegation assigned to a selected validator. Rewards accrue separately from the delegated principal. Claiming moves available rewards into the wallet, while redelegating changes the validator attached to some or all of the bonded position.
Swaps and liquidity positions
A swap exchanges one supported token for another through available liquidity. The settled balances matter more than the earlier quote because reserves and other inputs can change before execution. Providing liquidity creates a pool position instead: the supplied assets leave the spendable balance, and the position records the wallet's share of the pool.
mantraUSD and ecosystem applications
The mantraUSD route converts supported USDC into mantraUSD, so reconciliation requires checking both the debited input and credited output. Ecosystem listings can lead to separate applications. A wallet connection, approval or position in one application shouldn't be assumed to carry into another.
Records to capture before signing and after broadcast
A reliable starting record identifies the exact account, network and asset representation involved. It also separates spendable funds from delegated funds, unbonding entries, claimable rewards and pool positions. Those categories may contribute to a displayed total without being immediately usable.
- Confirm the selected wallet account and MANTRA Chain network.
- Record the spendable balance before the action.
- Check the validator, pool or conversion route.
- Read the requested amount, transaction type and network fee.
- Save the transaction hash after broadcast.
Native staking also needs enough available MANTRA to pay the transaction fee. Trying to delegate the full displayed balance can leave too little MANTRA for the delegation fee or a later claim, redelegation or unstaking request.
The commitment boundary in a wallet signature
Connecting an external wallet lets the interface read the selected public account, but it doesn't authorize a transfer or delegation. The consequential step begins when the wallet presents a transaction for approval. Its message should match the route, amount, account and intended state change.
Signing authorizes the request, while broadcasting submits it to the network. Neither step alone proves that the chain accepted the change. Acceptance appears in the transaction status and resulting state. Reversibility then depends on the action: a swap requires another trade, liquidity requires a withdrawal transaction and staked principal must follow the staking exit process.
How do I know a Mantra zone action finished?
An action has finished when the transaction succeeded on MANTRA Chain and the expected state appears under the same account. A hash identifies the request, but its final status shows whether execution succeeded. The resulting balance or position supplies the second half of the check.
For a swap, compare the input debit with the received output. A liquidity deposit should create or increase the relevant pool position. A delegation should appear under the chosen validator. An unstaking transaction is complete as a request when its unbonding entry appears, although the principal isn't spendable until that entry matures.
A hypothetical staking check from entry to exit
A reader's hypothetical wallet starts with 42 MANTRA available. The hypothetical instruction delegates 32 MANTRA to a selected validator, leaving 10 MANTRA before the actual network fee. The balances, amount and validator choice are illustrative; the example shows how the spendable balance, fee and delegation should reconcile.
- At entry, record the account, network, 42 MANTRA spendable balance and chosen validator.
- Before approval, verify that the 10 MANTRA remainder covers the live fee. Then approve the 32 MANTRA delegation and retain the resulting transaction hash.
- At the check, verify a successful status, a 32 MANTRA delegation increase and a spendable decrease of 32 MANTRA plus the actual fee.
- For exit, submit an undelegation later and verify its amount and unbonding entry before waiting for the released principal.
If the hypothetical delegation changes from 32 to 22 MANTRA, the pre-fee remainder rises from 10 to 20 MANTRA. The lifecycle doesn't change. The actual fee and unbonding period remain live network inputs rather than fixed values in the example.
Staking state changes
Staking separates three records that shouldn't be treated as one balance: delegated principal, claimable rewards and principal moving through unbonding.
Delegation
Delegation assigns MANTRA to a validator without returning a liquid receipt to the spendable balance. The validator's commission, status and displayed return estimate can change, and validator penalties can reduce the delegated principal. A confirmed delegation therefore establishes a position, not a fixed future payout.
Rewards and redelegation
Staking rewards accumulate outside the principal until claimed. A claim moves eligible rewards to the wallet, while a claim-and-stake action uses eligible rewards to increase the delegation. Redelegation keeps the selected amount bonded and changes its validator assignment rather than making it spendable.
Unbonding exit
An unstaking request creates an unbonding entry before the principal becomes spendable again. The entry carries the amount and a completion condition determined by the chain. Rewards stop accruing on that principal during the wait, so a submitted request isn't the same as a completed withdrawal.
Swap and liquidity reconciliation
Swap and pool records both depend on shared liquidity, yet they produce different outputs and expose the wallet to different ongoing conditions.
Swap execution
A successful swap debits the offered token and credits the received token. The received amount can differ from an earlier estimate within the transaction's accepted constraints. Closing the interface doesn't reverse a confirmed swap; changing back requires a separate transaction at the conditions available then.
Pool entry
Providing liquidity creates a pool position that can earn a share of trading fees. The position represents exposure to the pool's changing reserves rather than a promise to return the original asset quantities. Any optional locking condition also affects when the position can be withdrawn.
Pool exit
A withdrawal reduces or consumes the pool position and returns assets according to the pool state at execution. Reconciliation should compare the position removed, the assets received and the network fee. Holding the assets directly avoids pool composition changes, while providing liquidity adds fee income and reserve exposure.
Costs that move with the action
Transaction cost depends on the requested operation and live network conditions. The wallet preview estimates the fee, while the confirmed transaction records what was charged. Keeping some MANTRA spendable leaves funds available to pay for the next required transaction.
Other cost drivers belong to their routes. Validator commission affects staking rewards. A swap reflects pool fees, available liquidity and price movement before execution. A liquidity position can change in composition as traders use the pool. These inputs shouldn't be compressed into one advertised return figure.
Public records and wallet permissions
A public transaction links the signing address to its on-chain details. Depending on the action, those details can include amounts, contracts, validators or resulting positions. Changing a profile name or closing the browser doesn't remove those records. A connected interface may also read public balances associated with the selected address.
EVM token routes may request an allowance before the main action. An allowance is separate from the swap or deposit transaction, so review each wallet request on its own. Native staking uses a delegation transaction instead. Applications reached through the ecosystem directory may have different operators, contracts and permission models.
Bounded recovery when records disagree
Recovery starts by locating the last observable state. If no transaction hash exists, the request may never have left the wallet. Reopening the route is different from retrying a known on-chain transaction.
A pending hash calls for status checking rather than immediate duplication. The interface may display an older balance while the network processes the request, or it may need a refresh after confirmation.
A failed transaction didn't create the requested state, although it may still have consumed a fee. Read its error, then recheck the account, network, available balance and live parameters before building a replacement.
A successful transaction with an unexpected outcome requires reconciliation against the exact signed message. Compare the confirmed state with the intended state before choosing another transaction; a correction addresses an existing record, while a retry assumes no matching change occurred.
Practical questions
Does Mantra zone receive my private key when I connect a wallet?
No. A standard external-wallet connection shares the selected public address and lets the interface request signatures, but the wallet keeps the private key. Read every signature request because approving a transaction can still change balances, delegations or contract permissions without revealing the key itself.
What address should I compare after changing between Cosmos and EVM routes?
Compare the address shown by the route and the wallet that signed the transaction. Native Cosmos activity commonly uses a mantra-prefixed account, while EVM activity uses a 0x address. Don't reconcile one context against the other merely because both accounts may come from the same wallet setup.
Why is part of my MANTRA balance unavailable for a new transaction?
A total balance can include MANTRA that isn't spendable. Delegated principal, an unbonding entry and some application positions remain separate from the available balance. Network fees must come from spendable funds, so the transaction may fail even when the portfolio total looks sufficient.
Does redelegating MANTRA send it back to the wallet first?
No. Redelegation changes the validator assigned to bonded MANTRA without first returning that amount to the spendable balance, while undelegation follows the separate unbonding path that eventually releases principal to the wallet.
What happens if I switch accounts before a pending action confirms?
The pending transaction remains tied to the account that signed it. Switching the connected account changes what the interface displays, not the submitted transaction. Reconcile the hash and resulting state under the original signer before deciding whether the newly selected account needs any action.
Are displayed staking APR figures fixed for the life of a delegation?
No. A displayed annual percentage rate is an estimate rather than a locked return. Network reward settings, total delegated stake, validator commission and validator performance can affect realized rewards. Use the delegation record and claimed amounts to reconcile outcomes instead of treating the initial display as a guarantee.
Why can a pool withdrawal return a different asset mix from the deposit?
Trading changes the quantities held by an automated liquidity pool. A provider owns a share of those changing reserves, so withdrawing that share can return a different mix from the original deposit. Fees may add value to the position, while reserve changes can alter its composition.
Do I need to claim rewards before adding more MANTRA to a validator?
No. An existing validator position can receive an additional delegation without first claiming accrued rewards. The added principal and the unclaimed reward balance remain separate records. Claim-and-stake is another action because it first handles eligible rewards and then increases delegated principal.
Updated