# Order Validity Checks

## Context

Ethena conducts several validations to ensure both the user and the protocol can honour the signed order before it is submitted to the blockchain.

When users **mint** or **redeem** *USDe*, after the user has signed the order with their wallet, Ethena retains "last-look" ability. This enables Ethena to be sure the price agreed between Ethena & the user wouldn't impose a loss on the protocol. *This is principally motivated to ensure neither Ethena nor the user is adversely affected in highly volatile markets.*

{% hint style="info" %}
Ethena cannot change the user-signed EIP712 order as a result of the blockchain.
{% endhint %}

## Validations

<table data-full-width="true"><thead><tr><th>Validation</th><th width="239.33333333333337">Description</th><th>Purpose</th></tr></thead><tbody><tr><td><ol><li>Cryptographically Valid Signature</li></ol></td><td>The user-provided signature is cryptographically valid.</td><td>This ensures the user has the necessary ability &#x26; permissions to request this operation.</td></tr><tr><td><ol start="2"><li>System health check</li></ol></td><td>A health check of Ethena hedging &#x26; pricing internal systems</td><td>This is to ensure Ethena can manage the delta of the operation.</td></tr><tr><td><ol start="3"><li>Whitelisted trader</li></ol></td><td>The user's Ethereum address is whitelisted. </td><td>Only KYC/KYB'd users are able to directly <strong>mint</strong> &#x26; <strong>redeem</strong> <em>USDe</em> with Ethena.</td></tr><tr><td><ol start="4"><li>Approved beneficiary</li></ol></td><td>If the beneficiary of the mint is different than the benefactor, the benefactor must have approved this beneficiary onchain.</td><td>Ensures benefactors or their delegates do not accidentally or maliciously redirect proceeds to another wallet.  Benefactors can approve beneficiaries by calling <code>setApprovedBeneficiary</code> once.  <a href="https://etherscan.io/address/0xe3490297a08d6fC8Da46Edb7B6142E4F461b62D3#writeContract#F20">Etherscan offers a UI for doing this.</a></td></tr><tr><td><ol start="4"><li>Sufficient balances and approvals</li></ol></td><td>The user has provided sufficient approvals and has sufficient funds to honour the request. </td><td>Prevents time and gas wastage and ensures transaction success at the smart contract.</td></tr><tr><td><ol start="5"><li>Timeliness of order return</li></ol></td><td>The user has returned a signed order within an acceptable time period of Ethena sending a response to their initial RFQ request. </td><td>Keeps prices relevant by ensuring prompt order response.</td></tr><tr><td><ol start="6"><li>Order expiration check</li></ol></td><td>The user's signed order expiry attribute is at least 30 seconds in the future</td><td>The user's signed order expiry attribute is at least 30 seconds in the future to ensure the transaction is able to reach finality in almost all gas environments.</td></tr><tr><td><ol start="7"><li>RFQ and order match</li></ol></td><td>The user's signed order <code>collateral_amount</code> and <code>usde_amount</code> attributes are an exact match to the RFQ payload Ethena returned to them.</td><td>This ensures users and protocol positively affirm the terms of the agreement.</td></tr><tr><td><ol start="8"><li>Last look</li></ol></td><td>The present system price compared to the signed order's price is within the acceptable tolerance the user and Ethena have agreed to.</td><td>This ensures that the price hasn't moved outside of tolerance bands adversely against the protocol.</td></tr><tr><td><ol start="9"><li>External price check</li></ol></td><td>That the signed price is within a specific tolerance of another external pricing source, such as <a href="https://pyth.network/">Pyth</a> and Redstone. </td><td>This operates as one of many sources of redundancy and fail-safes to ensure the system is functioning correctly at all times.</td></tr><tr><td><ol start="10"><li>$N per block limit check</li></ol></td><td>The order will not exceed the defined maximum capacity that is available per block for <strong>mint</strong> and <strong>redeem</strong> <em>USDe</em> requests.</td><td>Contributes to protocol stability.</td></tr><tr><td><ol start="11"><li>Multiple orders check</li></ol></td><td>The user does not have another order to be processed in this block. </td><td>Users are only allowed to successfully submit one <strong>mint</strong> / <strong>redeem</strong> <em>USDe</em> request per block.</td></tr></tbody></table>