Quotation and Slippage

Slippage protection

Due to the timing of Oracle updates, currently configured to 8 hours the actual ETH : mETH exchange rate experienced by users may differ slightly from the exchange rate quoted during user stake or unstake, which is unavoidable due to the nature of the way Ethereum works.

For example, if the user loads the website and sees the rate 1:1.2 and sends a staking transaction, it is possible that an Oracle update happens before their transaction is included in a block, adjusting the actual exchange rate. To ensure that users always get a fair price, the contract accepts a "minimumAmount" parameter for staking and unstaking, and the contract will reject the transaction if the amount returned would fall below this amount.

For simple UX, the Mantle LSP front-end sets this slippage amount for all users to X%. Advanced users can submit transactions with a custom minimum amount directly to the contracts.

Unstaking exchange rate

When a user wants to unstake, they must make an "unstake request", which signals their intent to leave the protocol. The amount of ETH that they will receive for their mETH is set using the exchange rate at the time they made the request.

Each unstake request goes into a queue, which is based only on time — i.e., it is "first-come-first-served".

Before an unstake request can be "claimed", two things must be true:

• There must be enough ETH allocated to the queue for the user's request

• The request must be "finalized"

Finalization happens when an Oracle report has been posted which covers the range that includes the user's unstake request time (plus some buffer).

For example, if a user makes an unstake request at block 1000, and the current Oracle report ends at block 800, the request is not final. When the Oracle updates and the end of the next report is 1600 (i.e. past 1000), then the request is considered final and can be claimed.

Cancelation of unstake requests

While any unstake request is not finalized, the LSP system reserves the right to cancel it. This ability exists to ensure that the protocol remains fair for all users in the unlikely event of a loss of funds due to slashing or penalties.

Consider the case where the exchange rate from mETH -> ETH is 1.2 i.e. every mETH is worth 1.2 ETH. If there is a slashing penalty where 25% of all ETH is lost, the resulting "true" exchange rate should be 0.9. However, until the Oracle updates to reflect that loss of balance (which could take up to 8 hours) on the Consensus Layer, the quoted rate would still be 1.2. All stakers would be incentivised to race to unstake and claim at the elevated exchange rate.

To ensure that the protocol cannot be exploited in this case, the protocol can cancel these requests that were made at the elevated exchange rate. This would mean that the users who requested to unstake after the slashing event would need to request again once the true rate is reflected in the protocol.

Every secure liquid staking protocol must include a mechanism similar to this to protect itself from the time discrepancies between an action happening on the Consensus Layer (e.g., slashing) and the effect of that action being reflected on the Execution Layer.

Cancelation vs Repricing

There are two different ways to handle what should happen to requests that are made at an "invalid" rate during this time delay. Some popular protocols (e.g. Lido) choose to use a "repricing" mechanism. This means that when the Oracle updates, the exchange rate for each request is forcibly updated to the new "true" rate based on when the request was made.

There is no better solution, but here are some pros and cons of each model:

Pros of repricing

• Users who requested to unstake will still receive some funds without needing to request again

Cons of repricing

• Users are quoted at one price and may receive significantly less than they expected.

• Users can't opt-in to possible resolutions to cover the shortfall of ETH.

Pros of canceling

• Users will always see the exact amount of ETH that they will receive for an unstake request if it finalizes. They will have the chance to determine if they should remain in the protocol.

• Unstakers who were unaware of the loss of funds, or who panicked, will have the chance to receive the full amount for their tokens if the protocol recovers funds through an insurance mechanism.

Cons of canceling

• Users must make a second unstake transaction, and there is no on-chain mechanism to notify them that their first request was canceled.

Overall, the Mantle team decided that cancelation was a fairer method, as it has a significantly higher chance of returning users a higher amount of money after factoring in insurance payments.