Skip to content

DEFI Brainstorming

eprbell edited this page Mar 21, 2022 · 6 revisions

Objective

The objective of this document is to capture requirements + specs and or workarounds for missing features related to DEFI (see issue #4 for details).

There is ongoing debate on how to handle some of the new scenarios opened up by DeFi from a tax perspective. RP2 has expressive primitives that allow users to capture different scenarios in multiple ways, however the following are just proposals, not definitive solutions. Check with your tax professional if these situations apply to you (and feel free to participate to the discussion if you have insight).

The CryptoTrader.Tax DeFi Guide offers useful tips on how to deal with DeFi from the tax perspective.

Fee-only Transactions

  • Use cases:
    • transaction that calls a smart contract function that executes and costs some ETH or BNB
    • invest in a DeFi project where say 10% of invested tokens are "burned"
  • this is captured using an out-transaction with transaction type set to Fee, see relevant FAQ for more.

Fees Denominated in a Third Currency (Neither Fiat Nor Currency of Transaction)

  • Use case: send 100 CAKE from one BSC wallet to another then the fees are paid in BNB not CAKE
  • this is captured using a fee-only out-transaction denominated in the "other" currency, as discussed above.

Bridging

  • Use case:
    • Buy ETH/Matic, bridge it over to Poligon/Matic (which burns gas in ETH)
  • Possible solutions:
    • if ETH/Matic and Polygon/Matic are considered two different tokens from the tax perspective:
      • Sell-typed out-transaction disposing of ETH/Matic
      • Fee-only out-transaction to capture gas fee
      • Buy-typed in-transaction acquiring Polygon/Matic
    • if ETH/Matic and Polygon/Matic are considered the same token from the tax perspective:
      • Intra-transaction between two Matic accounts (the from and to amount are the same, the gas fee is captured as a separate fee-only out-transaction)
      • Fee-only out-transaction to capture gas expense

Liquidity pools: lock currency + rewards

  • Use cases:
    • lock say 100 DRIP forever and then you get 1 DRIP per day back for a max of 365 days
    • buy a "node" that consumes 10 STRONG from your wallet, but after that the node produces 0.1 STRONG per day, forever.
  • Possible solutions:
    • Intra-transaction to the "locked" account (to fund it)
    • Intra-transactions from the "locked" account, until the original amount is repaid (yield)
    • Stake-typed in-transactions afterwards (also yield, but it's actual income, not just recouped locked coins)
    • Possibly, fee-only out-transactions to capture fees in third currency (if applicable)
  • Notes: not entirely sure what the official tax treatment of this whould be. @Westofpluto says that CPAs disagree and adds: "A 'reasonable' assumption is that if you invest 100 XYZ coins and get 1 back per day, the project is returning your 100 coins back to you every day, so your taxable income on the first 100 is just the price on the day it is returned minus the price you paid for it on the day you invested. After that, all coins are like a STAKING reward and are fully taxable.".