> For the complete documentation index, see [llms.txt](https://docs.ethena.fi/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ethena.fi/solution-design/minting-usde/order-validity-checks.md).

# 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>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.ethena.fi/solution-design/minting-usde/order-validity-checks.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.