The current tests don't check for all revert cases. These are the most important tests as they can point us to critical bugs. Come up with new test cases/scenarios such that those cases shouldn't occur in real world contracts. It's suggested to write or document the test cases before writing the tests for the same.

Each dHEDGE market works differently. To provide updates such as de-listing of deposit assets, APY changes and so on, a notification system is necessary. The notification system can be a Telegram/Discord bot providing information for each dHEDGE market to which a user is streaming to.

Another kind of a bot can be made to manage streams or to notify a user regarding their streams. For example, if a stream was closed or re-opened, the user can be notified of the same. Maybe the bot can allow a user to manage their streams directly from Telegram instead of going to SF dashboard or our dashboard ? This is highly experimental and can be a hackathon project in itself but I believe it's worth doing.

When a user runs out of funds/supertokens, they tend to expect a service that will close their streams. We are in a good position to provide such a service because of our experience with Stroller Protocol. We can create a Gelato resolver contract which will close the streams of a user when their streams are gonna run out of funds in less than 12 hours or so. We can start with closing the streams to our cores of a user. Other streams will still go on but that's not our concern. A similar contract is already live which utilises the emergencyCloseStream function of a core contract. We need to create a new contract which uses Superfluid's new ACL features.

The contracts currently aren't upgradeable. Multiple bugs have been found and should some bug be found on mainnet version, it will become very difficult to fix and deploy a new set of contracts and tell all the users to change their streams. Although upgradeable contracts are controversial, particularly in our case as we intend to keep the control to ourselves initially, it would be helpful in having a set of upgradeable contracts which we can deploy when we choose to hand over the reigns of the project to the community.

It's possible that a dHEDGE pool can disable a deposit asset i.e., the asset will no longer be allowed to be deposited into the dHEDGE pool. However, the streams of all users will still exist. In case the asset is disabled for a long time, the streams need to be stopped as they are not generating any yield for the users. When the asset is re-enabled, the streams should be re-started. However, this process should not take place frequently. This is because we will be unable to cover the gas costs associated with such frequent stream modifications. We should only close streams if the fees that we will get is more than the costs to manage every users' streams. Maybe we can only service those markets which actually generate enough profits to make stream management possible ?

Currently, most tests use mainnet forking to interact with dHEDGE contracts on Polygon mainnet. This makes the testing process slow and reliant on good internet connection. Ideally, we would like to test the contracts locally. This would involve mocking various contracts especially the dHEDGE ones. Instead of actually creating mock contracts, Waffle mocks can be used.

However, this issue is of low priority as the solution would involve a week or two's worth of dev time. Instead, I will write new test cases.

dHedgeMathTesting.test.js contains all the tests some of which can be placed in a new test file. The test cases should be grouped in a relevant manner. For example, if the test cases are for the keeper related functionality then they can be put into a separate test file and do the same if the test cases are for the mathematical aspect (calculation and validation of various amounts) of the contracts.