The report below suggest an efficient implementation of the DXdao redemption floor part of the new token model. A brief live demo was given on last Friday’s strategy call: DXproductstrategy Call [2022-12-09] - YouTube
This model suggests the following 4 tech implementations:
a simple redemption smart contract, which takes an oracle price feed
an oracle aggregator
a validator oracle implementation
basic front-end UI to do the redemption
ELI5:
A user goes to the redeem front-end, and inputs the amount of DXD they wish to redeem. This sends a request to the oracle aggregator, which based on the amount of DXD the user inputs performs a live calculation and prepares a quote for the user. This quote then has to be validated by all validating oracles, which perform the same operation at the same block to ensure the oracle isn’t being manipulated. Once validated, the validation oracles sign the quote cryptographically and return the signature to the aggregator which will then return that quote to the front-end displaying the redeem amount and allowing the user to do so.
Access to funds would be done through token approvals from the DAO to the redemption smart contract. The approvals can be managed by DXdao to decide which tokens and amounts it wants to allow for redemption.
My main concern on the use of oracles to calculate the right NAV is how to implement in a safe way the calculation when using assets that are on other chains and even more how we can protect that against flash loans. We would need to think carefully about on a time frame for an oracle quote to be valid, and I would suggest adding a maximum on the total amount that can be withdrawn from the redeemer contract, example: not more than 100 DXD can be redeemed in an hour.
The flash loan risk only exists for SWAPR, but it is a relatively small risk because it accounts for a small percentage of the adjusted NAV (less than ~2%). I’m sure there can be better solutions than a cap per hour.
So a few things here - like molo said flash loan risk exists only for SWPR less than 2% of NAV so im not super concerned on this front - maybe we can convert this to eth or a stable if so worrysome?
Also the DXD cap per hour is does not seem like a productive fix… surely there are other solutions to this right?
We are still making some changes, so it’s not in final shape - but we wanted to allow the community to review and follow the progress of this project transparently.
What we would need to move ahead:
green light from DXdao
an address to own the redemption contract (i.e. can add and remove signers)
whether 3ac should initially run the aggregator node, and a validation node
a list of contributors interested in running a validation oracle
