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:
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:
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)
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:
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.
On withdraw of liquidity
Withdraw Value: save the token ratio and total value in ETH or $
Look for the supply transaction
Supply Value: save the token ratio back then and the value in ETH or $ back then
Calculate Permanent Loss/Win
Calculate Permanent Loss/Win = Supply Value - Withdraw Value
Do some kind of normalization to make the it comparable to others LP
Variation would be to calculate the Supply Value with the present value to compare it to Hodl
Dap: https://yam.finance/
Medium: https://medium.com/@yamfinance
Twitter: https://twitter.com/YamFinance
Discord: https://discord.com/invite/nKKhBbk
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
Add liquidty
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.
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.
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.
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.
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.
https://twitter.com/martinkrung/status/1305900781724471296?s=20
Nexus Mutual https://nexusmutual.io
yNFT: https://yinsure.finance/
yNFT Stats: https://stats.finance/yinsure
Farming $safe: https://yieldfarming.insure
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.
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.
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.
I see this solutions to give long-term liquidity a higher value than short-term liquidity:
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
Ongoing! (8.9.2020)
https://twitter.com/lawmaster/status/1303221190593581056?s=20
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.
Vampire attack, a attack on liquidty dependent protocols
Migration Mining/Vampire Mining
Liquidity is flowing into AMM pools and is flowing out again. How to measure this flow?
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.
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:
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.
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.
A combination of migration mining, leverage shorting Project A's tokens ($a) and going leverage long Project B's tokens ($b).
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
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.