The genesis of USDe
"Minting" USDe refers to the creation of new synthetic dollars. "Redeeming" USDe is the reversal process, of exchanging synthetic dollars for the assets that collateralize them.
The methods of minting vary depending on the type of stablecoin/synthetic dollar. Here we will explore the novel Ethena synthetic dollar minting process.
The Ethena synthetic dollar minting system encompasses the following design principles:
Users request a price from the Ethena Pricing API.
Users can generate a signed order and optionally submit it to Ethena's minting server.
Note: at this stage, users have complete control over their assets - they have the freedom to create, hold, and sign the price at their discretion. The approval to transfer assets only happens when the user willingly signs the order.
By blending centralized and decentralized elements in this way, Ethena achieves a relatively high level of trustlessness. Users always retain control over their assets prior to mint and their orders will be processed exactly as specified. And while Ethena has some control over order acceptance, the blockchain's transparency and cryptographic guarantees mean users can confidently engage with the protocol, knowing their transactions are secure and unalterable.
Slippage occurs when the price at which a trade is executed differs from the expected price, usually due to market volatility or trade size.
Ethena has designed its minting process to minimize slippage for users. Before submitting a minting transaction, users receive a "price" from the Ethena Pricing API that includes a predefined slippage range. The user then signs this price, confirming their acceptance of the potential variation within the specified range.
When the transaction is executed, the smart contract logic ensures that the final minting settlement price falls within the signed slippage range. This approach provides users with a level of certainty about the price they will receive and makes the transaction predictable.
Slippage management is a key part of Ethena's minting design strategy, aiming to provide users with a more stable and transparent transaction experience.
The Ethena Minting Contracts are regularly audited. See the section for up-to-date information.
Q: Am I only able to get USDe via minting USDe with Ethena?
No, you can acquire USDe initially via decentralized protocols such as Curve and Uniswap as well as buy & sell USDe on Centralized Exchanges such as Binance, OKX and Bybit.
Once the signed order is received, Ethena's server checks that the user has the required asset balance and signed approvals and that the dynamic hedging server can currently handle the order. Part of this involves communicating with the OES solution to prepare for the incoming mint or redemption request.
Note: Ethena does have the ability to reject an order based on these conditions. However, even in this centralized part of the process, the protocol could never alter the contents of the signed order due to the immutability of blockchain cryptographic signatures. This design ensures that the user's order - the backing asset, its size, any included slippage, and the synthetic dollars to be minted - remains as the user intended.
The order is sent to the blockchain with the atomic mint function called when these checks are passed. As above both the transfer of the user's assets and the minted synthetic dollars happen in a single transaction.
Upon success the hedging system actions the mint events to ensure the delta neutrality of the protocol's overall backing. Read more about these concepts in the Hedging SystemandBacking Asset Custodysections.
Ensures only orders at fair prices are submitted on chain
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.
If the beneficiary of the mint is different than the benefactor, the benefactor must have approved this beneficiary onchain.
Ensures benefactors or their delegates do not accidentally or maliciously redirect proceeds to another wallet. Benefactors can approve beneficiaries by calling setApprovedBeneficiary once.
Sufficient balances and approvals
The user has provided sufficient approvals and has sufficient funds to honour the request.
Prevents time and gas wastage and ensures transaction success at the smart contract.
Timeliness of order return
The user has returned a signed order within an acceptable time period of Ethena sending a response to their initial RFQ request.
Keeps prices relevant by ensuring prompt order response.
Order expiration check
The user's signed order expiry attribute is at least 30 seconds in the future
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.
RFQ and order match
The user's signed order collateral_amount and usde_amount attributes are an exact match to the RFQ payload Ethena returned to them.
This ensures users and protocol positively affirm the terms of the agreement.
Last look
The present system price compared to the signed order's price is within the acceptable tolerance the user and Ethena have agreed to.
This ensures that the price hasn't moved outside of tolerance bands adversely against the protocol.
External price check
That the signed price is within a specific tolerance of another external pricing source, such as and Redstone.
This operates as one of many sources of redundancy and fail-safes to ensure the system is functioning correctly at all times.
$N per block limit check
The order will not exceed the defined maximum capacity that is available per block for mint and redeem USDe requests.
Contributes to protocol stability.
Multiple orders check
The user does not have another order to be processed in this block.
Users are only allowed to successfully submit one mint / redeem USDe request per block.
Cryptographically Valid Signature
The user-provided signature is cryptographically valid.
This ensures the user has the necessary ability & permissions to request this operation.
System health check
A health check of Ethena hedging & pricing internal systems
This is to ensure Ethena can manage the delta of the operation.
Whitelisted trader
The user's Ethereum address is whitelisted.
Only KYC/KYB'd users are able to directly mint & redeem USDe with Ethena.
Approved beneficiary
Several measures have been taken to ensure the integrity and resilience of the deployed smart contracts. These measures are designed principally to ensure the safety of protocol assets, but also to ensure reasonable governance occurs.
Below is a list of some, but not all, of the user security measures Ethena has implemented across the deployed smart contracts.
Only whitelisted user wallet addresses are able to successfully mint & redeem USDe. This seeks to ensure that only non-malicious actors are able to call the aforementioned functions.
Provided backing assets are only able to be sent from the Ethena Minting contract to whitelisted wallet addresses of our OES provider partners. This ensures protocol backing is not able to be diverted to improper wallets and protocol funds enjoy the legal and governance protections without interruption.
Updating the whitelisted addresses in the Ethena Minting contract requires a multi-sig transaction by members of both Ethena & external responsible parties.
Mint/Redeem Smart contract keys are generated in an air-gapped secure manner whereby a single person is not able to access these keys.
A small proportion of the protocol's total assets are kept in EOA wallets. Secure multi-sig approval process is required for major fund transfers.
Internal pricing sourced from multiple centralized exchanges is constantly validated with external sources such as Pyth and Redstone to ensure integrity.
Numerous Order Validity checks are performed throughout the system + workflow to ensure the integrity of the system.
Separate GATEKEEPER_ROLE roles across the smart contract exist to detect unusual mint/redeem transactions and immediately disable the mint/redeem functionality upon unexpected behavior.
The DEFAULT_ADMIN_ROLE and owner smart contract roles are all multi-sig keys and are securely stored in cold wallets.
Accurate pricing is essential, ensuring users get the best value and protocol remains stable.
Hedging Processes
Robust checks and balances for hedging, including block number validations and system health checks.
Ensures orders are handled correctly and reliably, minimising potential order execution errors.
Protecting against Adverse Selection
Employ a last-look architecture, whitelist market makers, and set tight windows for quote validity.
Priorities giving users the best pricing and protects against potential manipulations or unfair play.
Gas Estimation
Maintain a limited ETH balance for transactions and monitor gas fees to prevent overpayment.
Ensures users are not overcharged due to gas estimation errors, preserving user funds.
Security Measure
Action Taken by Ethena
Purpose & Benefit
Handling of Mint/Redeem Keys
Ethena securely generated mint/redeem keys are stored safely in AWS secrets manager. Exist on production machines upon deployment only which has critically restricted access.
Ensures no unauthorized access, safeguarding users and the protocol from potential mint/redeem key compromises.
Address Validity
Only whitelisted addresses can receive backing assets. Withdrawals restricted to whitelisted custodian addresses.
Minimises risk of sending funds to incorrect addresses, ensuring targeted and secure end to end mint/redeem flows.
On-Chain Fund Management
Avoid keeping large sums in EOA wallets. Secure multi-sig approval process for major fund transfers.
Safeguards protocol assets and protects from unintended fund movements.
Ensuring Correct Pricing
Strict Order Submission
Only whitelisted users can submit orders, which must meet Ethena’s validation criteria.
Protects the system against malicious public internet orders, only genuine requests are processed.
Robust Role Management
Distinct gatekeeper roles for monitoring and managing unusual mint/redeem transactions.
Specialised roles allow for targeted oversight and faster response to potential security threats.
Cold Storage of Multi-Sig Keys
Admin and owner multi-sig keys of all contracts are securely stored in cold wallets.
Enhances security by reducing exposure of essential keys to online threats.
Validate internal pricing consistently against third-party sources. Real-time checks and balance measures.
Minting: Minters can mint USDe by providing assets and receiving USDe tokens in return. The backing assets are transferred to "Off-Exchange Settlement" providers based on a predefined route. The minting process is subject to a maximum limit set by the contract.
Redemption: Redeemers can redeem their USDe by providing them as input and receiving the underlying assets back USDe in return. The redeemed USDe tokens are burned from the user's balance. The redemption process is subject to a maximum limit set by the contract.
Signature Verification: The contract cryptographically verifies the signature provided by the user to ensure the authenticity of the minting or redemption order.
Supported Assets: The contract maintains a strict list of supported assets that can be used as backing assets for minting and redemption.
Custodian Addresses: The contract maintains a strict list of custodian addresses to which backing assets can be transferred during the minting process.
Max Mint/Redeem Per Block: The contract sets a maximum limit for the number of USDe tokens that can be minted or redeemed per block.
Roles in smart contracts are what control lower level operations and function calls. It's a security feature, like AWS IAM, that allows the authors of smart contracts, and the users using them once deployed to the blockchain, to be certain of how they can operate.
There are five roles in the Ethena Minting contract. You can view the deployed Ethena Minting contract on the Ethereum blockchain here.
ADMIN
Multi-Sig
Ethena Labs
1
Transfer Ownership
Add/remove supported collateral asset
Add/remove custodian addresses
Grant/revoke Minter, Redeemer, Gatekeeper roles
GATEKEEPER
EOA
Shared between
Ethena Labs
External Security Firms
Ethena upgraded the Mint and Redeem Contract from the to the on the 8th of July 2024 at approximately 10am UTC.
Ethena gathered feedback from all key stakeholders, requested buy-in, and scheduled the deployment at a date & time that was optimal for whitelisted API users. This upgrade represented a breaking change to existing whitelisted users' trading systems.
Both versions of the contract were written by the same engineering team and have both successfully passed .
The updates to the Mint and Redeem Contract were principally motivated by:
Set max/mint mint/redeem per block
Reenable mint/redeem
3+ internal 3+ external
Disable mint/redeem
Disables when they execute at incorrect prices on chain
Limits damage on mint/redeem roles compromise
MINTER
EOA
Ethena Labs
20
Mint
Transfer to approved "Off-Exchange Settlement" providers
REDEEMER
EOA
Ethena Labs
20
Redeem
Improvements to the protocol's security and continuing to reduce potential risk surfaces.
Adding features requested by existing and potential users to support new workflows.
Introducing additional controls around specific risk configurations.
Functionally for existing whitelisted API users, the changes were quite minor and not a large engineering lift for whitelisted users.
Review the Mint and Redeem Contract V2 between the existing & second versions of the Mint & Redeem Contract.
Prepare required updates to your trading system to accommodate the second version of the contract, including:
Updating your connection URL to either https://public.api.ethena.fi or https://private.api.ethena.fi from https://api.ethena.fi.
You must provide an IP address to be whitelisted if you wish to use the private.api.ethena.fi connection URL. There is no difference in priority, performance, or rate limits between the two connection URLs.
Ensuring new approvals are added to your whitelisted addresses given the new .
Updating to use thenew .
The /order submission remains the same, except for the following changes:
rfq_id is no longer required in the /order parameters. Instead, it must be included inside the signed object body object as order_id. This is because the rfq id is now stored onchain, and thus requires you to sign it.
For EIP-1271 users, you must add the signature_type parameter with the value EIP1271 to the /order request. The default is EIP712 so the former is only required if you're using EIP-1271.
Supporting the new error_code value 27 that enables you to perform a hot upgrade if you would like during the deployment. If you receive this code from V1 then it is time to begin minting/redeeming with your V2 client.
During deployment, prepare for approximately 15 minutes of downtime.
The Ethena Labs team will proactively confirm to users if the deployment has been successful.
API users will be required to meet the new API specifications & requirements to be able to mint & redeem directly with Ethena.
In the event of an unsuccessful launch, Ethena Labs will:
Change
Description
Operation / Outcome
Distinct Asset Mint/Redeem Max Per Block Limits
Implements asset-specific block-by-block minting and redeeming limits for stablecoins versus assets/LSTs, with a global cap.
Limits can be adjusted using the .
EIP-1271 Smart Contract Signing
Adopts EIP-1271 standards to verify signatures, enabling smart contracts to recognize and accept collateral.
Market Maker Smart Contract implementing the Interface can partake in this type of Minting via adding a parameter to the /order request.
Onchain API User Whitelisting
Introduces multi-sig whitelist for benefactors and a self serve beneficiary whitelist directly within the Mint and Redeem Contract.
Benefactor addresses are onboarded via ; beneficiaries are assigned by benefactors.
Mandate Delta Limit Between Stables & USDe
Sets a mandated delta limit in bps for price divergence between stablecoins and USDe in specific cases, mainly to protect protocol from blackswan events like stablecoin collateral de-pegging events or private key compromise.
The value of the limit is configurable via the .
If MINT and the normalised amount of USDe minted is greater than the collateral received, the stable limit check is applied.
If REDEEM and the normalised amount of USDe is less than the amount of collateral returned, the stable limit check is applied.
The section below is not an exhaustive list of the aforementioned changes but rather expands on particular areas of interest. Please reach out if you have any questions or feedback.
Ethena is now able to set specific direct Mint/Redeem global limits per ETH block by:
Asset
Groups of Assets, such as Stablecoins and LSTs
This enables greater specificity around which assets whitelisted users are able to directly mint & redeem directly with Ethena.
This feature introduces an additional validation to check such that it is not possible to directly mint or redeem with Ethena if the divergence in price between USDe and USDT/USDC exceeds a defined limit in an adverse way to the protocol. The limit is defined via the field stablesDeltaLimitwith a default of zero.
The Distinct Asset Mint/Redeem Max Per Block Limits feature in combination with the Mandate Delta Limit between Stables & USDe feature means, that when only stablecoin minting is enabled, a theoretical compromise of the Mint and Redeem Contract private keys can NOT lead to protocol losses. This unique pairing removes the risk surface that would enable an attacker to ever possibly be able to mint or redeem USDe at an unfavorable price to the protocol.
With the adoption of EIP-1271 standards, this enables Smart Contracts to directly (after having been whitelisted) mint and redeem with Ethena via our API.
If using an EIP-1271, then the signature_type parameter, with the value EIP1271, must be added to the [POST] /order request.
Ethena is moving from offchain to onchain whitelisting of users able to interact with the API. Newly requested addresses to be whitelisted will be added by a request from the Ethena Dev multi-sig.
Whitelisted users now have the autonomy to whitelist their beneficiaries via the following smart contract function invocation:
An Error Code has been added to the API specification to notify when the migration has successfully occurred.
Users are able to use this response, returned by [POST] /orders, to automatically swap trading systems to meet the requirements of the second version of the Mint and Redeem Contract. In the event of an unsuccessful deployment, users could also use this to swap their settings back to the original version 1.
Example of error_code == 27
function setApprovedBeneficiary(address beneficiary, bool status){
"error_name":"Incorrect USDe minter. Switch Minting API",
"error_code":"27"
}Communicate proactively with all API users.
Immediately roll back to V1 of the Mint & Redeem Smart Contract enabling the existing V1 systems to continue functioning without change.
Coordinate another deployment date in the future for all API users.
Gas Optimizations
Uses Solidity structs to optimize gas usage and rearranges declaration for efficiency.
Implements optimized gas usage through efficient memory management of variables like order_type, and expiry.
Mints and Redeems occur normally but with less ETH burned by minters and redeemers over time.
RFQ ID on chain
Enables further reconciliation between the quoted RFQ ID from the Ethena trading system and the actual mints and redeems.
Included in the V2 Market Maker client program. Must now be part of EIP-712 an EIP-1271 signed order payloads for [POST] /order requests.
AES cipher encryption
Implemented advanced key encoding mechanisms using AES encryption and a rigorous key ceremony protocol involving multiple participants and secure storage methods.
Operations no longer rely upon AWS secrets. The secure process startup and interaction with the cryptographical of the system is strictly managed and executed by authorized Ethena Labs personnel only.
url = {ethena_url}order?signature={signature_hex}&signature_type=EIP1271