Mantra zone separates action inputs from signing authority and recovery ownership

Start with the action's real inputs

Each route builds a different transaction from the account, assets and choices supplied through the interface. Those inputs determine the requested state change. A wallet signature authorizes that request; it doesn't correct an unsuitable validator, reversed asset direction or unintended pool selection. Check those inputs before opening the wallet prompt.

Validator delegation

A delegation request combines a MANTRA amount with a selected validator. The available balance must cover both the delegation and its network fee. Commission, displayed annual percentage rate and existing delegation size can inform the choice, but they aren't part of a fixed return promise. The expected result is a delegation recorded for the signing account and chosen validator.

Swap instructions

A swap request needs an offered asset, an amount and the asset to receive. Its execution conditions may also include a minimum received amount or maximum spread. The displayed quote is an estimate before execution, while the signed message contains the enforceable transaction terms. A reversed input and output changes the trade rather than merely changing how it appears.

Liquidity contributions

A liquidity request identifies the pool and the assets entering it. Slippage limits affect whether the transaction can execute. An optional position lock affects when the resulting position can be withdrawn. Supplying liquidity creates a pool position rather than a simple token exchange, so ownership is evidenced by the recorded position or LP shares assigned to the account.

Connection, approval and signature boundaries

Wallet connection and transaction authority are separate permissions. A connection lets the interface identify a public account and read its visible on-chain state. It doesn't move funds by itself. The seed phrase and private key remain wallet secrets and shouldn't be entered into a website connection prompt.

On MANTRA Chain, a Cosmos signature covers the entire Cosmos transaction while an EVM signature covers the EVM transaction itself. That difference matters when reviewing a prompt. A Cosmos request may contain multiple messages, while an EVM transaction stands alone. If an EVM route uses an ERC-20 token, a separate approval may grant a contract an allowance before the requested contract action can use that token.

An allowance isn't the same as a swap or liquidity deposit. It authorizes token spending up to the displayed scope, while the later contract call requests the actual state change. The signing account owns the decision to approve, reject or reduce that permission where the wallet supports editing it.

What does each wallet request authorize?

Each transaction request asks the selected account to authorize an encoded transaction on the selected network. Its displayed details must match the intended action; if the wallet doesn't expose enough detail to verify that match, reject the request. A staking prompt should identify a delegation operation, validator and amount. A swap prompt should reflect the offered asset, route conditions and recipient. A liquidity prompt should identify the relevant pool, supplied assets and position terms.

The network fee pays for execution and is separate from the amount committed to the action. Contract addresses, recipients and token allowances deserve their own review because they define who or what receives authority. If the prompt describes a transfer when the intended job is delegation, signing it won't produce a staking position.

View full-size image

How can you tell whether an action changed the chain?

A transaction hash identifies the submitted transaction, but its final status determines whether the requested change executed. Pending means the network hasn't yet produced a final result. Success should be followed by the expected delegation, received balance or liquidity position. Failure means the requested state change didn't complete, although the attempt may still consume a network fee.

The connected account and network should match the transaction record. A successful record under another account won't update the intended account's position. Likewise, an interface that hasn't refreshed may lag behind confirmed on-chain state. Reconnecting or refreshing can fix presentation, but it can't alter the transaction that the network already processed.

Recovery ownership follows the failure point

The point of failure determines who can act next and which remedies remain possible. Before broadcast, control stays with the wallet holder. After broadcast, the network decides execution. Once a transaction succeeds, any reversal must use a supported on-chain operation or depend on the recipient's cooperation. The interface can't erase a confirmed record.

Before broadcast

An unsigned or rejected request hasn't changed on-chain state. The account holder can correct the amount, select another validator or pool and request a new wallet prompt. If the displayed account or network is wrong, changing it before signing avoids creating a transaction under the wrong identity.

On-chain failure

A failed transaction needs diagnosis before another attempt. Insufficient spendable MANTRA, an expired execution condition or a contract rejection can leave the intended result absent. The transaction record and wallet account establish what happened. Repeatedly signing the same request can repeat the same failure and spend another fee.

Confirmed but unintended input

A confirmed action can't be cancelled by disconnecting the wallet. A delegation may later be managed through redelegation or undelegation, subject to staking rules. A completed swap has already exchanged the assets under its signed terms. Funds sent to an unintended recipient don't gain a portal-level recovery path merely because the transfer began in the interface.

Trade-offs between staking, swaps and liquidity

Staking, swapping and supplying liquidity differ on the same decision dimensions: required inputs, signed authority, observable result and exit constraint. Staking assigns MANTRA to a validator and produces a delegation. A swap exchanges an offered asset for a requested asset under execution limits. Liquidity provision commits assets to a pool and produces a position tied to that pool's state.

Unstaking starts an unbonding period, and the affected MANTRA doesn't earn staking rewards while that period runs. Redelegation changes the validator relationship without first returning the delegated amount to the spendable balance. These rules make staking a poor substitute for a job that requires immediate access to the same funds.

Swaps finish with a new asset balance and don't preserve a claim on the original input. Liquidity positions remain exposed to changing pool reserves until withdrawal, and an optional farm lock can add an unlocking condition. Choose the route whose resulting state, dependencies and exit rules match the intended job.

What changes when another application handles the next step?

Another application changes the permission and recovery boundary because it can introduce a different interface, contract and support path. Following a link from the ecosystem area doesn't grant the destination a wallet permission. Any existing token allowance remains tied to its original token, spender and network. The destination may request its own connection, token allowance or transaction signature.

The wallet prompt remains the last review point before authority is granted. After execution, the network record shows what the account authorized, while the destination's contract rules govern any position created there. If Mantra zone lacks the required action or prerequisite, a specialized application may fit the job, but its permissions and recovery options must be assessed on their own terms.