In my mind we would need 3 things right:

- A smart contract to perform redemptions.
- A service to give out returned assets based on the input DXD and price feeds (feeds which can be taken using Chainlink where applicable).
- A frontend that takes the oracle-signed price feeds and performs redemptions at 70% of NAV based on user parameters.

The smart contract should be decently simple as in it would take in the signed oracle message, perform validation of the signature, and then give out funds based on the oracle data.
The frontend should also be decently simple.
Most of the work would be in the oracle, which will have to:

- Keep track of the treasury assets except DXD, converting them to USD value in various ways (we can use Chainlink oracles for ETH and stables for examples, and some specialized logic for Swapr LPs and other tokens). A nice thing about using Chainlink for ETH is that with it being onchain you can in theory even provide a storage proof to PROVE that at block x the Chainlink oracle provided a certain price feed, in order to further improve trustlessness. This can also be applied to the balances of the DAO's treasury. You can in theory provide proofs that these things are actually what the oracle claims them to be provided you know the storage slots at which the data is stored.
- Keep track of DXD total supply (should IN THEORY be as simple as having the total supply fetched from the mainnet smart contract to then remove any treasury direct and indirect holdings, such as Swapr LPs).

Once you have these 2 things we basically just have one formula to calculate DXD's USD price: `(treasuryNavUsd * 7000) / (10000 * dxdCirculatingSupply)` (some scaling might be necessary depending on decimal values returned here). Once wehave that we have a couple options to go forward:

- Give the user the possibility to have the tokens given "in the right proportions" as they are held in the treasury (not the best).
- Make the user choose between stablecoins (USDC or DAI) and ETH.

Second choice would be easier. In this option the oracle would calculate how much ETH or USDC the user should get based on the formula `treasuryNavUsd * 7000 * userDxdAmount / 10000`. That's it. This message could be forwarded directly to the redemptions smart contract which would simply have to perform checks and send an amount of ETH or USDC to the `msg.sender`.

The oracle's returned message could be structured in the following way:

{
    "dxdCirculatingSupply": 0,
    "treasuryNavUsd": 0,
    "dxdAmount": 0,
    "output": {
        "token": "0x...",
        "amount": 0
    },
    "r": "",
    "s": "",
    "v": "",
}

Plus all the other required EIP 712 data.

This solution will always be trusted as when running the server you would need to trust the operator not to have access to the oracle's signing account. Owning that, any message with any data can be crafted and it would be valid. The alternative would be to set up more infrastructure. But also, by giving storage proof for each applicable data and verifying it onchain could be a way (maybe).