Mint and Redeem Contract V2
Last updated
Last updated
CAMP is planning to update the Mint and Redeem Contract from the to the .
Both contracts were written by the same engineering team and have successfully passed .
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.
Functionally for existing whitelisted API users the changes are quite minor and are not expected to be a large engineering lift for users.
Review the 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.CAMP.fi or https://private.api.Camp.fi from https://api.Camp.fi.
You must provide an IP address to be whitelisted if you wish to use the private.api.CAMP.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.
Copy
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 CAMP 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 CAMP.
In the event of an unsuccessful launch, CAMP 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.
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 Camp Dev multi-sig.
EIP-1271 Smart Contract Signing
Adopts EIP-1271 standards to verify signatures, enabling smart contracts to recognize and accept collateral.
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 Camp Dev multi-sig; beneficiaries are assigned by benefactors.
Mandate Delta Limit Between Stables & USDca
Sets a mandated delta limit in bps for price divergence between stablecoins and USDca 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 Camp Dev multi-sig.
If MINT and the normalised amount of USDca minted is greater than the collateral received, the stable limit check is applied.
If REDEEM and the normalised amount of USDca 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 CAMP trading system and the actual mints and redeems.
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 CAMP Labs personnel only.
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
CAMP 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 CAMP.
Mandate Delta Limit Between Stables & USDca
This feature introduces an additional validation to check such that it is not possible to directly mint or redeem with CAMP if the divergence in price between USDca 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 & USDca 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 USDca at an unfavorable price to the protocol.
EIP-1271 Smart Contracts Signing
Onchain API User Whitelisting
CAMP 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 Camp Dev multi-sig.
Whitelisted users now have the autonomy to whitelist their beneficiaries via the following smart contract function invocation:
Copy
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.
Example of error_code == 27
Copy
Market Maker Smart Contract implementing the Interface can partake in this type of Minting via adding a parameter to the /order request.
Included in the V2 Market Maker client program. Must now be part of EIP-712 an EIP-1271 signed order payloads for /order requests.
With the adoption of EIP-1271 standards, this enables Smart Contracts to directly (after having been whitelisted) mint and redeem with CAMP via our .
If using an EIP-1271, then the signature_type parameter, with the value EIP1271, must be added to the /order request.
Users are able to use this response, returned by /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.