Mint and Redeem Contract V2
Overview
Ethena upgraded the Mint and Redeem Contract from the first version to the second version 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 was written by the same engineering team and have both successfully passed Audit.
The updates to the Mint and Redeem Contract were principally motivated by:
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.
Action Items for API Users
Functionally for existing whitelisted API users, the changes were quite minor and not a large engineering lift for whitelisted users.
Review the #changes-in-detail 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
orhttps://private.api.ethena.fi
fromhttps://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 Mint and Redeem Smart Contract.
Updating to use the new Minting Contract ABI.
The [POST]
/order
submission remains the same, except for the following changes:rfq_id
is no longer required in the [POST]/order
parameters. Instead, it must be included inside the signed object body object asorder_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 valueEIP1271
to the [POST]/order
request. The default isEIP712
so the former is only required if you're using EIP-1271.Supporting the new
error_code
value27
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:
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.
Only the USDT/USDe pair will be available for minting and redeeming for the initial V2 rollout. Other pairs are available at the protocol's discretion.
Changes
Overview
Details
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.
Distinct Asset Mint/Redeem Max Per Block Limits
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.
All block limits are measured in USDe terms. The global block limit can never be surpassed regardless of the individual USDe limits, per asset, per block.
Mandate Delta Limit Between Stables & USDe
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 stablesDeltaLimit
with 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.
EIP-1271 Smart Contracts Signing
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.
Onchain API User Whitelisting
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:
If the benefactor and the beneficiary are the same, there is NO need to whitelist the beneficiary onchain beforehand.
Hot (Graceful) Upgrade on Deployment
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
Last updated