Mint and Redeem Contract V2

Overview

Ethena is planning to update the Mint and Redeem Contract from the existing version to the second version.

Ethena plans to gather feedback from key stakeholders before scheduling a deployment with whitelisted API users. This upgrade represents a breaking change for whitelisted API users.

Ethena would like to solicit feedback between Thursday the 27th of June 2024 and the 4th of July 2024. Assuming positive feedback, Ethena will tentatively schedule the deployment for the 8th of July 2024 at 10am UTC.

Both contracts were written by the same engineering team and have 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 are quite minor and are not expected to be a large engineering lift for users.

  1. Review the #changes-in-detail between the existing & second versions of the Mint & Redeem Contract.

  2. Prepare required updates to your trading system to accommodate the second version of the contract, including:

    1. Updating your connection URL to either https://public.api.ethena.fi or https://private.api.ethena.fi from https://api.ethena.fi.

      1. 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.

    2. Ensuring new approvals are added to your whitelisted addresses given the new Mint and Redeem Smart Contract.

    3. Updating to use the new Minting Contract ABI.

    4. The [POST] /order submission remains the same, except for the following changes:

      1. rfq_id is no longer required in the [POST] /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.

    5. For EIP-1271 users, you must add the signature_type parameter with the value EIP1271 to the [POST] /order request. The default is EIP712 so the former is only required if you're using EIP-1271.

      url = {ethena_url}order?signature={signature_hex}&signature_type=EIP1271

    6. 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.

  3. During deployment, prepare for approximately 15 minutes of downtime.

    1. The Ethena Labs team will proactively confirm to users if the deployment has been successful.

    2. API users will be required to meet the new API specifications & requirements to be able to mint & redeem directly with Ethena.

      1. In the event of an unsuccessful launch, Ethena Labs will:

        1. Communicate proactively with all API users.

          1. Immediately roll back to V1 of the Mint & Redeem Smart Contract enabling the existing V1 systems to continue functioning without change.

          2. 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

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 Ethena Dev multi-sig.

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 https://eips.ethereum.org/EIPS/eip-1271 Interface can partake in this type of Minting via adding a parameter to the [POST] /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 Ethena Dev multi-sig; 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 Ethena Dev multi-sig.

  • 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.

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.

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

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:

function setApprovedBeneficiary(address beneficiary, bool status)

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

{
   "error_name":"Incorrect USDe minter. Switch Minting API",
   "error_code":"27"
}

Last updated