For the one who are following our project, you may know that we have forked the perpetual contracts implementation of UMA and proposed an UMIP to integrate it within the DVM. We called this contract PerpetualPoolParty. The UMA’s governance approved this fork earlier this year, allowing us to launch our mainnet.
The PerpetualPoolParty was a “broker contract” allowing only a smartcontract (the broker and its liquidity pool) to be the sole Token Sponsor.
Now we are about to launch our “bank contract” which allows anyone to be a Token Sponsor, pretty much like the EMP. Yet, we could not use the EMP due to some specification of our protocols (multi-collateral synth, minting limits, etc.). So we forked PerpetualPoolParty.
We will create a UMIP but before I wanted to answer all your questions here.
The goal of this UMIP is to integrate selfMintingDerivativeFactory in the DVM.
The PerpetualPoolParty has been audited by Halborn and is now being audited by Ubik. These new contracts have not been audited yet.
List of modifications
Transaction fees : we have added functions to calculate and to transfer fees that are being paid when a user mint, redeem and repay. Fees are paid with the collateral. Fee calculation = the number of tokens to mint, redeem or repay * GCR * fee (in %).
Deposit collateral ratio (DCR) is capped : this is the ratio between the deposited collateral and number of tokens minted. It comes in addition to the GCR: the latter sets a collateral ratio limit below which it is not possible to mint; the DCR sets a limit above which it is not possible to mint; this is done in order to prevent someone to manipulate the GCR. Like the GCR, the DCR is used in the mint, deposit and repay function.
Minting is capped : it limits the number of tokens that the derivatives can mint so we can scale according to the demand, liquidity and security. Caps will be increased as security audits are being completed, and as liquidity on our Broker contracts (PerpetualPoolParty) deepen. Under certain conditions, limiting the cap has a downside: if there is not enough synthetic asset on the secondary market to buy them to liquidate a position, it is possible that the limit prevents minting enough synthetic to do so.
Make the contract permissionless : the PerpertualPoolParty contract was permissioned (only whitelisted contract can be a Sponsor). We changed this so anyone can become a Sponsor, like it is now in any UMA derivatives of course.
Remove the liquidity pool logic : the current PerpetualPoolParty contract works with liquidity pools.
The derivatives values are now stored in a comptroller contract: this allows us to change the logic of how we calculate these variables while keeping the same derivatives. In the factory smart contract, we can only link the derivative contract to an existing synthetic asset, which have been previously deployed using PerpetualPoolParty.
Fees, deposit ratio, mint limit are upgradable.
No change for the liquidation.