Open Valdorff opened 8 months ago
Hey @Valdorff -- sorry to hear you lost funds using swapper, do you think there's somewhere in the docs we can make this functionality more clear?
Given the single recipient nature of swappers we believe they should almost always have an owner for this very purpose, although in some situations you might want it to be a multisig or DAO. Would it have helped to add more warnings in the UI when a swapper is being created without an owner?
We will look into having more optionality for non-oracle-supported tokens in v2 -- thank you for your feedback and sorry for the loss of funds
Would it have helped to add more warnings in the UI when a swapper is being created without an owner
There are no warnings. I see now that hovering over the little (i) icon says that the owner has that special benefit, which implies that no owner means stuck tokens are possible. In common log levels, that's where I'd go for INFO or even DEBUG level. WARNING is more like the yellow box you use for discount incentive. I can switch to/from No Owner without any yellow/red text or popups or other standard warning methodologies.
Note also: If you start the new contract creation without a wallet connected in the UI, "No Owner" is the default and doesn't update upon wallet connection.
we believe they should almost always have an owner for this very purpose
I don't think the front end reflects that belief. Could require checking an option in the "Advanced" section to select No Owner, eg.
We will look into having more optionality for non-oracle-supported tokens in v2
I'm unclear on any scenario where the beneficiary shouldn't be able to access these tokens. I can see why you might allow the owner to retrieve them (eg, if the beneficiary doesn't have the ability to use that token), but that doesn't really give a reason to prevent the beneficiary from retrieving them.
Worth noting -- love 0xsplits. The modular stuff you can do here is my go-to example of things you can do in web3 that tradfi can't replicate effectively.
Ah I see what you're talking about -- we will update the FE asap to handle this more appropriately. Thank you again for reaching out
Note also: If you start the new contract creation without a wallet connected in the UI, "No Owner" is the default and doesn't update upon wallet connection.
yeah I remember debating this internally and we were worried about updating something that the user may have already "set" without them realizing it (if they're connecting at the end of the flow just before submitting)
I'm unclear on any scenario where the beneficiary shouldn't be able to access these tokens.
will add this to list of v2 improvements
First I'd like to confirm my understanding.
There's a swapper with an ERC20 token in it. The swapper is using a univ3 oracle. Using getPairDetails between that token and the target token returns
[[0x0000000000000000000000000000000000000000,0]]
. getQuoteAmounts reverts. I believe there is currently no way to recover these tokens forever. If the oracle had an owner, setPairDetails might provide a path, but that's not the case here. The swapper also has no owner.If that's accurate, I'd like to suggest adding a
forwardUnpricedToken
function or similar. That would take in a target token, check that getPairDetails yields 0x0...0 as the pool from pair details, and then simply send the full amount of the target token on to the beneficiary. This might not always work (eg, the recipient may be unable to use that type of token), but it would certainly have prevented a loss in my case, and it seems unlikely this is the only time that's happened.