Switzerland dos not have captial gains tax for private persons. Selling tokens crypto to fiat or to a different token this is not a taxable event.

This is a collection with links talking about How to tax crypto holdings and revenues in Switzerland:

https://www.finews.ch/news/finanzplatz/49391-crypto-tax-steuern-estv-ico-token#:~:text=Sogenannte%20Airdrops%2C%20also%20den%20Erhalt,der%20Einkommenssteuer%2C%20mahnen%20die%20Steuereintreiber.

https://www.estv.admin.ch/estv/de/home/direkte-bundessteuer/fachinformationen-dbst/kryptowaehrungen.html

Intro

First, I talk about the new stuff I'm working on: I start a new project, called GenesisDao, it's about NFT, fractalized NFT, scarcity, trust and art and will run at least over the next 13 years, follow here: https://twitter.com/genesisDA0

Currently, I'm also involved in bootstrapping Aladdindao (https://twitter.com/aladdindao)

Now back to the Vampire Attack

One year ago, I published my article about the vampire attack, at this time a theoretical issue.

As I wrote this idea down, in parallel the sushi chef already started coding in real life, inspired by a tweet from Larry Cermak.

I hit a spot, and the merit was that the name "vampire attack" stuck for this kind of attack. https://twitter.com/martinkrung/status/1298363320270032897

If you read this backround article, migration mining article carefully, then you see that the vampire attack in fact is even more aggressive, more than what sushi did. Until today, we did not see such an attack in the wild. As blockchains are going to be faster and the capacity to move liquidity higher, I guess we will see more aggressive version of vampire attacks in the future.

The base of the vampire attack is that in crypto short-term liquidity has mostly the same price as long-term liquidity, which leads to mercenary liquidity. I name it here here as opportunistic liquidity:

https://www.cryptonative.ch/pricing-long-term-liquidity-at-the-same-value-as-short-term-liquidity-results-in-opportunistic-liquidity/

Mercenary liquidity is still big issue in crypto, to my knowledge, only bancor has fixed this with their 100 day impermanent loss insurance, and they also found a way to limit the liquidity of BNT further by making a voting vBNT which you can generate from BNT in one of the pools.

Sushi swap was an instant success, people deposited their uniswap liquidity provider token to farm sushi. But then sushichef was unable to stand the heat in the kitchen and run taking thetreasury with him. This was a major blow. After some days the guy returned the treasury and appointed sam to take over the migration. Sam took lead and the forming sushi community did a superb job with the migration. Today sushi is one of the corner stone of DeFi and is still driven by a loyal community. Sushi has been able to ship constantly new products and grown into a DeFi power house.

Some month later, uniswap made a token too, and did airdrop 400 UNI to every one who used uniswap more than once. Going public this way was a clear response to sushis vampire attack.

Sadly, uniswap failed to be a community driven project and the governance is in a bad shape. With the V3 it's clear that uniswap is going b2b regarding liquidity providing, quite a different approach then sushiswap.

I'm sure these days we will see a lot articles about the sushiswap saga!

Discussion about Impermanent Loss (IL) is one of the biggest topic surrounding AMM protocols and different design exist to offset or try to limit IL.

What's astonishing for me is that nobody until now is try to measure permanent loss/win, resulting if you withdraw liquidity as a liquidity provider (LP).

This info is available on-chain and can be calculated for every LP on withdraw and for every pool.

My suspicion is that the result will be devastating and show that most pools and most LP lose money.

How to use this new Metrics?

• Show LP on withdraw if they are going to be in permanent loss and if yes, how long they have to wait until enough fees are earned which possible offset the impermanent loss. (Thanks for 0xMaki for this idea)
• Allow LP provider to limit permanent loss by auto-withdraw like a stop-loss order
• Allow LP provider to maximize permanent win by auto-withdraw like a take profit order
• Show LP Permanent Loss/Win of pools pre supply

How to measure Permanent Loss/Win for one LP

1. On withdraw of liquidity
   Withdraw Value: save the token ratio and total value in ETH or $

2. Look for the supply transaction
   Supply Value: save the token ratio back then and the value in ETH or $ back then

3. Calculate Permanent Loss/Win
   Calculate Permanent Loss/Win = Supply Value - Withdraw Value

4. Do some kind of normalization to make the it comparable to others LP

5. Variation would be to calculate the Supply Value with the present value to compare it to Hodl

How to measure Permanent Loss/Win for a pool

1. Sum up all Permanent Loss/Win from the start of the pool

How to measure virtual Permanent Loss/Win for a pool

1. Sum up all Permanent Loss/Win from the start of the pool
2. Sum up all Impermanent Loss/Win from the start of the pool until now
3. Add these two Sum

How to measure Permanent Loss/Win and Impermanent Loss/Win for a LP

1. Look for every AMM Protocol used
2. Calculate Permanent Loss/Win
3. Calculate Impermanent Loss/Win
4. Sum up all PL/W and IL/Win for a LP

More Info

Dap: https://yam.finance/
Medium: https://medium.com/@yamfinance
Twitter: https://twitter.com/YamFinance
Discord: https://discord.com/invite/nKKhBbk

Addresses

YAM 3 token address:

https://etherscan.io/token/0x0aacfbec6a24756c20d41914f2caba817c0d8521

yUSD token tracker:

yUSD is also named yyCRV or YAM-yyDAI+yUSDC+yUSDT+yTUSD

yUSD: https://etherscan.io/token/0x5dbcf33d8c2e976c6b560249878e6f1491bca25c

yUSD token adress:

yUSD is also named yyCRV or YAM-yyDAI+yUSDC+yUSDT+yTUSD

yUSD: https://etherscan.io/address/0x5dbcf33d8c2e976c6b560249878e6f1491bca25c

Uniswap Pool YAM - yUSD:

https://etherscan.io/address/0xb93cc05334093c6b3b8bfd29933bb8d5c031cabc

Analytic:

https://uniswap.info/pair/0xb93cc05334093c6b3b8bfd29933bb8d5c031cabc

Other Pools with YAM Pairs:
https://uniswap.info/token/0x0aacfbec6a24756c20d41914f2caba817c0d8521

Buy or sell on Uniswap

https://app.uniswap.org/#/swap?inputCurrency=0x0aacfbec6a24756c20d41914f2caba817c0d8521&outputCurrency=0x5dbcf33d8c2e976c6b560249878e6f1491bca25c

Add liquidty

https://app.uniswap.org/#/add/0x0aacfbec6a24756c20d41914f2caba817c0d8521/0x5dbcf33d8c2e976c6b560249878e6f1491bca25c

First

I'm a long-term member of Nexus Mutual for around one year and this is pretty long for crypto these days. I'm not involved in the governance/community and things I describe may be underway.

The creation of yInsureNFT from yearn and the possibility to buy/sell cover on an open market is a development in the right direction.

I also do write this with yieldfarming.insure in mind because they are fresh and want to move forward. I do not hold or farm $safe right now.

To stream money, not send, is the nature of crypto.

The idea of sending money in large chunks is outdated. I assume that in the future money is not sent, but continuously streamed. I strongly see blockchain technology itself as a medium and every medium has some sort of natural properties and will eventually diverge to this properties. The natural way for the medium blockchain is that money is streamed, not sent.

Nexus Mutual cover model is not cryptonized

So if you look at Nexus Mutual, you have to buy a cover for a certain time, and when you don't need the cover anymore because you decide to move one, you just have to keep it. At least everyone can make a claim holding an insurance for a protocol. If you make a claim no proof having actual money in the protocol is required.

Yinsure.finance did change that: With yNFT you can sell the claim if you don't use it anymore.

Money streamed leads to insurance streamed

But we want a stream insurance model anyway, that's what the costumer in me wants. I'm imaging the following product:

If I have the need for a cover for a protocol, I give the insurance trusted access to my account, and they just stream the needed payment to them. If my risk level changes on that protocol the stream is adjusted the payment accordingly. Depending on my risk tolerate level and my funding I can set a percent of cover and adjust this anytime.

Final goal is to auto-balancing insurance cover for all my holdings

If this works, it's effortless to create the product I really want: A auto-balancing cover for all the protocols and values on my ethereum address which I can manually adjust anytime without to make any payment, just streamed.

Disscuss here

https://twitter.com/martinkrung/status/1305900781724471296?s=20

Links:

Nexus Mutual https://nexusmutual.io
yNFT: https://yinsure.finance/
yNFT Stats: https://stats.finance/yinsure
Farming $safe: https://yieldfarming.insure

Liquidity in traditional finance

In traditional finance illiquid liquidity is more valuable than liquid liquidity: If you deposit your money for a longer and fixed period, you will receive more interest than if you only keep it as cash in our bank account. For traditional banks this is key, because if people could withdraw their complete money anytime, a bank as a liquidity dependent institution, can go bankrupt very quickly.

Miss-pricing of long-term liquidity vs short-term liquidity

These rules also apply to crypto but have been neglected until now: Most liquidity dependend protocols act like liquidity for a day is the same as liquidity for month and do not reward long-term liquidity over short-term liquidity.
If you deposit your money into a protocol for a week you get the same ratio from the fee, as you will deposit for a month. So cost the move liquidity from one protocol to another is just the transaction cost.

Opportunistic liquidity

Together with the fact that liquidity has the same value regardless of where it is located, this leads to opportunistic liquidity.

Because opportunistic liquidity has only the transaction cost to move from one protocol to another protocol, and except security risk, no other risk. The liquidity can just flow back to the old protocol if not successful. Liquidity wars will only stop if protocols start pricing long-term liquidity higher than short-term liquidity. Leaving with your liquidity and coming back has a price tag then and as a result movement of liquidity will be reduced greatly.

Possible solutions

I see this solutions to give long-term liquidity a higher value than short-term liquidity:

1. A lock-up period free to choose to immobilize liquidity gets a higer reward (like in legacy banking)
2. Extra reward for long term provider increasing over time, some form of compounding
3. Short-term liquidity provider pay long-term liquidity provider on leaving

Real world

Sushiswap vs Uniswap

Sushiswap, a Uninswap fork, startet on August 26 2020 and did implement a basic form of migration mining. Opportunistic liquidity inflow had a value of almost 1.2 Billion $ at the peak. The main dev did cash out the treasurey on September 5 and ruined the project.

https://medium.com/sushiswap/the-sushiswap-project-c4049ea9941e

More about the sushi chef ruining the project: https://twitter.com/ameensol/status/1302395863709351936?s=20

curve.fi vs swerve.fi

Ongoing! (8.9.2020)
https://twitter.com/lawmaster/status/1303221190593581056?s=20

Feedback?

I would like to hear any feedback on this, please use my tweet: https://twitter.com/martinkrung/status/1303307557226917890?s=20

Or drop me a mail at contact@cryptonative.ch or DM me on twitter.

More to read:

Vampire attack, a attack on liquidty dependent protocols
Migration Mining/Vampire Mining

How to measure liquidity flow

Liquidity is flowing into AMM pools and is flowing out again. How to measure this flow?

Average liquidity coin age (ALCA)

To represent the stickiness of liquidity in one pool I came up with average liquidity coin age. Coin age metric is well-known for full block chains, but I never did see this calculated for AMM Pools. To make this simple, we use days to measure the duration of this.

1 liquidity coin for 30 days = 30 LCA
2 liquidity coin for 10 days = 20 LCA

Average LCA would be 25 LCA for this pool.

Liquidity coindays destroyed SMA for outflow measurement

Another metric is liquidity coindays destroyed. This metric would measure the outflow more accurate. On every withdraw the coin age value of this withdraw is measured and a simple moving average calculated over 1day/1week.

Example:

Withdraw for 1 liquidity coin which has stayed in the pool for 30 days will result in 30 LCAD
Withdraw for 2 liquidity coin which has stayed in the pool for 10 days will result in 20 LCAD

Now calculate a sum of all LCAD over a timeframe of 30 days and divide this with 30 you will get Liquidity coindays destroyed moving average.

Feeback over Twitter please: https://twitter.com/martinkrung/status/1301177253687185412?s=20

References:

• https://blockchair.com/bitcoin/charts/coindays-destroyed?interval=3m&compare=
• https://www.wikiwand.com/en/Moving_average

Trying to fall into sleep yesterday a had another spark of insight into the future of finance and crypto. After almost 10 years of spending time researching crypto stuff, my brain just keeps spitting out this stuff.

Normally coins are passive matter, they can't move for themself, they are being moved from A to B from outside. If you look on an algo trading system, the algo is trading the coins or the connected pairs. With crypto this can be very different.

Will write this down in the futur (Next 10 years). It's quite complex and I don't think it's possible to implement this with the stage of crypto right now.

Vampire Attack (Vampire Mining) - an attack on liquidity dependent protocols

Here we have dark scenario for liquidity dependent projects called the vampire attack. In the interest of keeping DeFi projects secure and behaving as intended, liquidity lock-up or sufficient time-based rewards for locking up liquidity provider should be implemented. This attack uses migration mining.

Simple Vampire Attack

1. Clone a project A (from its smart contracts to even its front-end). Project A has no token yet, but earns fees on token volume.
2. Implement migration mining from project A to project B. Simply, give $b to people who migrate liquidity from A to B.
3. Implement governance and start sharing revenue to tokenholders holding $b.
4. Attack will be successful if Project A is drained of sufficient liquidity.

Advanced Vampire Attack

A combination of migration mining, leverage shorting Project A's tokens ($a) and going leverage long Project B's tokens ($b).

1. Capital accumulation: sell $vampire over a bonding curve end get $usd into treasury.
2. With 1/2 of the treasury you go to a lending market and lend as much $a as you can.
3. With the other part you buy $b and put it into lending to leverage long (buying more $b)
4. Implement migration mining from project A to project B. Simply, give $vampire to those who migrate liquidity from A to B. In parallel start selling $a to lower the price. With a portion, leverage up by lending more $a on a lending market and sell this too. With the other portion, buy more $b from project B.
5. People start migrating liquidity from project A to B to earn $vampire. The price of $a is expected to crash (because without liquidity, the project is worthless and has no revenue). Expect the price of $b to start rising.
6. Now buy back the now worthless $a, pay off the incurred debt, and get your initial $usd with leverage back and put it into the treasury.
7. Distribute the $usd and $b to the people having $vampire

A Vampire Attack is a simple "hack" but has wide implications:

• The era of free liquidity flow is over. Liquidity migration itself has to be rewarded as migration mining.

• Projects will have to pay for liquidity lock-up rather than contend with free floating liquidity

• Liquidity owners can become protocol owners with no or little risk

• Shorting/Longing entire projects are now possible with this strategy (Advanced Vampire Attack)

• Advanced Vampire Attacks share characteristics with flash loan attacks but is slower

• Private owned projects who are liquidity dependent have a high risk of vampire attacks

• Every liquidity dependent project needs lock-up periods or a form of compounding rewards for long-term liquidity provider

Executive Summary for non crypto people

Imagine two traditional banks (A and B) which have similar services.

B is very new and has no liquidity. So B decides to distribute shares and a reward for the liquidity you bring in. B knows that A is dependent on liquidity, as is every bank. So B takes out a loan somewhere, buys shares of A (with leverage) and sells these on the market.

Then B tells every customer of A that it has a plan to suck out A's liquidity, distribute its own shares, and offer a reward as incentivization. If successful, people will start to migrate liquidity from A to B. (Incoming liquidity would have a lock-up period and you would receive more shares the longer you lock-up)

A cannot stop liquidity outflow because customers can do this electronically without permission. This results in A going bust and the value of A's shares drops to zero. To finalize the scheme, B pays back the now worthless shares from A and distributes the profits as rewards for its own shareholders.

Tweet from 2020-08-25 about the vampire attack: https://twitter.com/martinkrung/status/1298363320270032897?s=20
Many thanks to Daniel Hwang for corrections.