Persistent Asset(s) - Feedback

Ecosystem
#1

I am currently working on a project to integrate Superfluid into dHedge protocol. The project will allow dollar cost averaging use-cases (DCA). Superfluid allows for streaming tokens into a contract/EOA.

The issue that I am facing is that currently, a manager can choose to change deposit assets at his/her will. This would mean that people who have opened a stream of a particular deposit token will have to change the token. Reminding them or informing them of the change of deposit token is not possible to do on-chain (unless one uses something like EPNS).

I would like exploring the idea of having a persistent asset or assets in every pool. By persistent asset I mean that this token will always be accepted for deposits. This way, I can warn users that deposit assets are subject to change except for a persistent asset. I understand that managers might not prefer a token in large quantities as this would mess up their pool balances and they might have to rebalance often and hence I think a stablecoin would be the best option for such a kind of persistent asset. If someone has a different opinion/solution to my problem, I am happy to discuss the same !

1 Like
#2

Really cool.
As you say, having a persistent deposit asset (eg USDC) may not be ideal for the manager and their pool balances.

I can see your problem though as the manager could disable the asset you’re trying to deposit.

Was there any specific pool you wanted to DCA into, or would it be any pool?

#3

I think for DCA, I’m assuming it’d be a contract. We’d need to add a function to delegate pool share to another address than is depositing as well, otherwise, the pool tokens would be sent back to the contract that’s sending the stream.

Unless the contract deposits, then transfers the tokens to the user address as part of a multicall or something.

1 Like
#4

The way it works now is that I deploy contracts for a pool. In the future I plan to provide managers the ability to deploy the contracts for their respective pools with some custom parameters. Once this is achieved, it would be exactly same for anyone i.e., anyone can deploy these smart contracts permissionlessly and build upon them if required.

#5

It’s a set of contracts yes. The way it works is that tokens are accrued due to streams from users and these tokens are then deposited into the dHedge pool represented by the contract. Now, the LP tokens received are kept in the smart contracts but in the future, I plan to integrate Instant Distribution Agreement provided by Superfluid. It enables distribution of an asset to multiple users based on pre-defined share amounts. Right now, users have to call a function in my contract to withdraw their share. Delegate pool share as you mentioned can be useful if the user wants to redeem their share directly from my contracts rather than withdrawing the LP tokens from my contract and calling another function to dHedge pool contracts via your front-end.

#6

Ok got it - we can add a withdrawTo function as discussed on the Discord