Zaps to Farms on Alchemix
- Edited
Looks pretty cool to me, +1. I wonder if a fee model could be built that's sublinear, might be more attractive to larger deposits.
Hource well the Li.Fi SDK we're using for bridging assets has a minimum and maximum fee, although the maximum fee afaik is always 0.1% of the bridged amount. But ye I agree, the overall economics must be sound enough for users to opt-in to use this feature over manually swapping their assets and then depositing. A small extra on top for being a convenience-layer should be okay tho.
We will closely monitor usage after launching. Users will have the ability to avoid paying fees by depositing directly. Monitoring the conversion rate on Zaps will give us good insight into whether users are willing to pay for convenience. We will see whether larger deposits require different fee mechanisms from the data.
0.2% is our initial proposal, as it makes things simple to start. We will use usage data to reevaluate after launch.
roman-wido This would immediately have to be integrated into the Alchemix front end right? I fully support something like this existing, would defer to N4n0 if it's secure. Ie, I would vote "yes pending security review from core team". If we simply have to add some code we control to tie into an immutable smart contract, then it seems pretty straightforward.
ov3rkoalafied bit of context maybe, so Roman and I were talking a while ago in Discord DMs about this and he said his team were eager to build this. Basically they'll write the code, open a pull request against our staging branch, get a proper vetting through code review and if all is well we'll merge it.
5 days later
Thank you to everyone for your comments and feedback.
We will start work on the PR this week. I will follow up here as soon as it is ready for review.
Sounds cool!
7 days later
- Edited
While building Zaps for the following three farms on Alchemix — ALCX, Saddle alETH and ALCX/ETH v2, we noticed none of the farms currently produces output tokens that would be sent back to the user.
It looks like those three farms also do not support deposits on behalf of a user. It is necessary that either the farm returns a receipt token or takes deposit on behalf of the user so that Zaps can attribute the deposit to the user.
We also noticed a wrapper contract called gALCX that wraps the ALCX farm. This wrapper contract does return receipt tokens to the user.
Building Zaps into gALCX is straightforward because it produces a receipt token that can be sent back to the user.
Building Zap for the other two farms — Saddle alETH and ALCX/ETH v2 — needs adjustments in how those farms operate.
It would be good to understand the reason behind the wrapper contract of gALCX and if a similar one would be appreciated for the remaining two farms — Saddle alETH and ALCX/ETH v2, to ensure the output tokens are in place. In such a case, we would build Zaps into the wrapper contracts.
Alternatively, would Alchemix consider adding an option to deposit on behalf of a user into the existing farms?
cc @n4n0
Yeah right now the farms are pretty basic; there's no receipt token and no delegated deposit. I'm not sure what the consensus on updating the contracts for the farms is, seeing how they are v1 spawned.
The gALCX wrapper for ALCX was made to enable auto compounding for users that want to stake their tokens in the ALCX farm. Not sure if this can be done for the other farms.
I'll ask around tho.
10 days later
roman-wido In certain jurisdictions receipt tokens could be viewed as taxable events. It's debatable, but we'd definitely need to understand which of our users could be affected by a change like this. I was unaware that there were many reasons for receipt tokens other than composability (ie, rechypothication out the butt)