Problem: Contributing liquidity with ETH is unattractive to those who hold ETH that has significantly appreciated in value over time from a tax efficiency perspective, because it triggers taxable events for unrealized capital gains.
(In reality this point is debatable, but e.g. TokenTax treats these as taxable events IIUC.)
Simplistic example: OG bought into ETH at $1, now is at $341. OG is in a jurisdiction where providing liquidity to Uniswap is considered a taxable event, and capital gains are taxed at 20%. If OG wants to provide liquidity to farm, the short term impact is they owe $68 to the taxman for every ETH pooled (20% of the $340 appreciation). The absolute certainity of taxes must be compensated with steady high returns, which in practice seldom exist, so OG is likely to not go for it.
Proposal: provide stabletoken-only versions of the existing jars. For example, for a 0.69a type jar, 1/2 of the input DAI is converted to ETH possibly using uniswap itself, then pooled on uniswap. When releasing funds, the reverse process is followed. Thus, the user never sells their original ETH and therefore only triggers a taxable event for the final gains of pooling, which is much more tax efficient.
Advantages (“big if true”):
- One could instead borrow stabletokens against their ETH (using ETH as collateral does not trigger a taxable evt.) then seek max returns on the stabletokens using the above mechanism, without triggering capital gains for said ETH.
- Per above, it seems to me that OGs in tax-unfriendly jurisdictions and ETH that has appreciated a ton would most benefit from this, so if I’m right, it may unlock big sources of capital for the protocol, ultimately resulting in revenues that make Pickle sustainable token economics wise.
Caveats/points of discussion:
- Inefficiencies to deal with: tx fees can be huge, the interface should control for slippage.
- This proposal needs to be fact-checked by someone who knows more about taxes than I do, to make sure this can be structured in a way that really is tax efficient. E.g., converting DAI to ETH straight away in the same transaction may be problematic.
- It would be ideal to validate the proposal with some large holders who are facing this issue. If noone cares then this proposal is a waste of precious dev time.
So admittedly a few weak points in the proposal, looking for feedback.