• Each call’s Energy usage recovers linearly over 24 hours from when it was consumed.
• For a quick check, compare EnergyLimit with EnergyUsed; the difference is the available Energy at that moment.
• A rental or delegation supplies capacity, but its expiry or reclamation can change your limit before your used Energy has fully recovered.

Recovery follows each transaction, not the calendar

TRON tracks used Energy across a rolling recovery period: consumption starts recovering as it occurs, and that usage is cleared over 24 hours. If a contract call consumes 60,000 Energy at 14:00, that amount is fully recovered by about 14:00 the next day, assuming no intervening calls or changes to the account’s resource limit.

This is not a daily allowance that refills at midnight. At 02:00, about half of that example’s consumption has recovered; at 08:00, about three quarters. The figures are illustrative: actual availability also depends on later transactions and whether the account’s Energy capacity changes.

If you need the mechanics behind contract consumption and fees, read what TRON energy pays for. For this timing question, the key distinction is between the account’s capacity and how much of that capacity is still counted as used.

Repeated calls combine with recovery already in progress

A later transaction does not restart a clean 24-hour timer for all Energy. Its consumption joins the account’s existing recovery state, which the protocol recalculates by merging the old recovery progress with the new usage. In practical terms, repeated calls keep part of the resource pool occupied until the corresponding consumption has recovered.

For example, suppose a call uses 60,000 Energy, and another uses 40,000 six hours later. At the second call, about 15,000 of the first call’s usage has recovered, leaving roughly 45,000 still used; the new 40,000 adds to that ongoing usage. The second call’s contribution then recovers over its own following 24 hours. Treat this as a planning illustration, not an exact wallet forecast.

The distinction matters when a call fails. A normal contract REVERT still consumes Energy for instructions executed before the revert. A timeout or unexpected execution failure can incur a larger penalty. The used Energy follows the same recovery process afterward; a failed call does not instantly restore it.

Check the account after the transaction is confirmed

After a call is confirmed, inspect EnergyLimit and EnergyUsed in the account resource data; TRONSCAN can show the same resource state. Subtract usage from the limit to estimate what is available: for example, a limit of 100,000 and usage of 72,000 leaves about 28,000 Energy.

Read both numbers, because EnergyLimit can change independently of recovery. Staked capacity depends on your share of the network’s Energy allocation, while delegated or rented resources can be added or removed. So a higher available amount may reflect added capacity rather than recovered usage, and a lower one may reflect a reduced limit.

Bandwidth is separate: a USDT transfer also consumes it, but Energy recovery does not refill Bandwidth. If you are planning a call, confirm that the Energy estimate covers the likely contract cost and remember that the same contract can cost more when its dynamic energy factor rises. An estimate is not a guarantee of execution cost.

Choose between waiting and supplying more Energy

For one occasional transfer, waiting is usually the simplest choice if the next call can be delayed and your balance is already recovering. If it cannot wait, you can obtain additional capacity through staking or delegated Energy. TRON energy can also be rented for a wallet, allowing you to cover a call without staking TRX yourself; compare the available capacity with your transaction’s estimated need and timing.

Keep a modest TRX balance as a fallback: if available Energy does not cover a contract call, the network can burn TRX for the shortfall, subject to the transaction’s fee_limit. That limit caps the caller’s TRX contribution; it does not replenish consumed Energy or guarantee the transaction will succeed.

FAQ

Does a failed USDT transfer recover Energy?

Energy used before a normal contract revert remains consumed and recovers over the following 24 hours. Unexpected failures such as a timeout can incur a larger Energy penalty. Check the confirmed transaction result and your account’s updated resource values; do not assume that a failed transfer leaves the resource balance untouched.

Does rented Energy recover after the rental ends?

Recovery applies to used resources, while rental expiry or resource reclamation can reduce the EnergyLimit. If capacity is removed before usage has recovered, the available balance can change accordingly. Check both EnergyLimit and EnergyUsed after the resource period ends, and before relying on the wallet for another contract call.

Before acting, ask yourself: do I need to wait for used Energy to recover, or do I need more capacity for the next call?

Why does the quote move when reserves change?

Most simple token pools use an automated market maker (AMM), a contract that prices trades from the tokens it holds. In a constant-product pool, the reserve amounts multiply to roughly the same value: x × y = k. Buy one token, and its reserve falls while the other rises.

The ratio of the reserves gives the pool’s spot price, meaning its current starting price for a tiny trade. A larger trade shifts that ratio as it uses more of the pool. The resulting gap between the starting price and your average trade price is called price impact.

For example, imagine a pool holding 100 BNB and 10 million tokens. Its starting rate is 100,000 tokens per BNB. Before fees, swapping 1 BNB returns about 99,010 tokens, because the pool has less of the token after the trade; that is roughly 1% price impact.

How do you inspect the quote before trading?

Start with the exact token pair and the amount you plan to swap. Check the reserves and quoted output together: a quote based on a deep pool may change little, while the same order against a shallow pool can move the price sharply. Pool fees also reduce the output, so the example above is not a final trade amount.

If you are checking a BSC token chart, PooCoin is a charting and trading tool for exploring token activity and making a swap. Treat its quote as a snapshot of pool conditions, then compare the token pair and current reserves with on-chain data from BscScan. The Uniswap developer documentation explains the reserve-based constant-product mechanism behind this kind of quote.

Suppose another trader buys tokens after you check the quote. The token reserve drops, so your original BNB amount now buys fewer tokens. A refreshed quote reflects the changed reserves; the earlier screen value does not lock in that rate.

What if the quote changes before the swap lands?

A quote can change again while your transaction waits to be included on the blockchain. Slippage is the difference between the expected output and what the pool can provide when the trade executes. Set a minimum output you would accept, and proceed only if the refreshed quote still meets it.

This check matters most for thin pools, where one trade can take a sizable share of available reserves. Token taxes or unusual contract rules can also make the received amount differ from a basic pool estimate. If the output falls below your minimum, the swap should fail instead of completing at a worse rate.

Takeaway: Check reserves, trade size, and refreshed output together; the quote depends on all three.

Move the asset you plan to pledge onto Mantle, then supply it before borrowing. A lending protocol can only use collateral that is in the right network and accepted by its market. This guide takes you from funds on Ethereum to collateral ready for a position.

What do you need on Mantle first?

You need an asset the specific lending market accepts as collateral, plus a little ETH on Mantle for transaction fees. The asset you want to borrow is separate: supplying collateral does not automatically open a loan.

Check the market’s collateral list and its loan-to-value (LTV) limit before moving funds. LTV is the maximum loan value relative to your collateral value, and the protocol sets it per asset. For example, if a market’s LTV were 60%, $1,000 of collateral could support at most $600 in borrowing; that is an illustration, not a current market setting.

If your funds are on Ethereum, they must reach Mantle before you can supply them to a Mantle lending market. Mantle Bridge is the official route for transferring ETH, MNT, and supported tokens between the networks. For the full transfer walkthrough, see how Mantle Bridge moves assets; then return here to prepare the lending position.

How do you supply collateral before borrowing?

Follow these steps in order. The exact asset choices and limits depend on the lending market you use.

1. Choose the lending market and collateral asset. Confirm that the market accepts your token as collateral, and note its LTV and liquidation threshold. The liquidation threshold is the point where the protocol may sell collateral to cover a risky loan.
2. Move the required tokens to Mantle. Bridge the collateral amount and enough ETH for network fees. If the collateral is ETH, check whether the market requires ETH or wrapped ETH (WETH), a token representation used by some applications.
3. Wait until the funds arrive, then verify the network and balances. Make sure the wallet is showing Mantle and that both the collateral token and fee ETH are present. A deposit on Ethereum is not yet available to a Mantle lending market.
4. Supply the collateral to the market. Use its supply action for the chosen token, review the amount and transaction details, and approve the token if the protocol requests permission to use it. Supplying deposits the asset into the protocol; it does not by itself mean the asset is enabled as collateral.
5. Enable collateral use and check the position. If the market has a separate collateral setting, turn it on for the supplied asset. Before borrowing, review the displayed borrowing power and leave room below the maximum: a price drop or accrued interest can push a position toward liquidation.

For a before-and-after example, suppose you hold 1 ETH on Ethereum and your chosen market accepts WETH. Before bridging, it cannot back a Mantle loan; after the transfer, wrapping if required, and supply, the market can count it as collateral. The decisive check is that the lending market recognizes the deposited asset as usable collateral, not simply that it appears in your wallet.

Before borrowing, check:

• The collateral token is accepted.
• The deposit arrived on Mantle.
• Collateral use is enabled.
• You have ETH for fees and a buffer below the borrowing limit.

A restore height tells a Monero wallet where to begin its transaction scan. Choose a block before the wallet’s first incoming payment, and it can find the payment without scanning older blocks. A block is one recorded batch of Monero transactions.

• Set the height at or before your wallet’s first incoming XMR.
• If unsure, choose an earlier height; scanning takes longer, but funds won’t be skipped.
• A high restore height can hide older payments until you scan again from lower down.

Restore height sets the start of the wallet scan

Why does a wallet need this setting? Monero transaction details are encrypted, so a wallet scans the blockchain with its private view key, which lets it find transactions for that wallet. The restore height tells it where to start looking.

If you are restoring a wallet to receive XMR from another cryptocurrency, prepare the Monero wallet to scan from before its first incoming payment. An XMR bridge is one way to swap value into Monero; the restore height determines whether a restored wallet can find the XMR it receives.

The height refers to Monero’s blockchain, not the chain used by the coin you swap from. A height on BNB Smart Chain, for example, cannot tell a Monero wallet where to start scanning.

Choose a height before the first incoming payment

What number should you enter? Use the block that contains your first incoming transaction, or an earlier block. If you know the transaction ID, a Monero block explorer can show which block included it. Otherwise, use the wallet’s creation date as an estimate and choose a date slightly earlier.

For example, suppose you created a wallet in 2022 and first received XMR in 2023. Set the restore date near the wallet’s 2022 creation date, not the later payment date. Starting earlier may add scan time, but it gives the wallet a chance to find every incoming payment.

The common mistake is entering the date of a recent payment because it is the only date you remember. If the wallet was used earlier, that setting skips older transactions and can show a lower balance than expected. Lower the restore height to before the earliest possible payment, then let the wallet scan again.

Use the seed type and scan result to decide what to do

Does your recovery phrase already contain the wallet’s birthday? Some newer Monero wallets use Polyseed, a seed format that stores an approximate creation month. Older 25-word seed phrases generally do not include that date, so you may need to supply an estimate when restoring.

For a command-line restore, Monero’s wallet software accepts a start height with the --restore-height option. In a wallet app, look for its restore date or height field. If the restored wallet finishes scanning but misses an expected payment, set an earlier height and rescan; a high starting point is the key thing to check.

In practice, I’d choose a safely early date over a precise guess that might be too late. The extra scan covers older blocks, while a height after the first payment can leave it undiscovered. Keep the recovery phrase private: it can restore access to the wallet.