www.cryptonative.ch Open in urlscan Pro
80.74.154.155  Public Scan

Submitted URL: https://www.bankless.ch/
Effective URL: https://www.cryptonative.ch/
Submission: On September 04 via automatic, source certstream-suspicious

Form analysis 2 forms found in the DOM

POST https://www.cryptonative.ch/wp-login.php?action=postpass

<form action="https://www.cryptonative.ch/wp-login.php?action=postpass" class="post-password-form" method="post">
  <p>This content is password protected. To view it please enter your password below:</p>
  <p><label for="pwbox-1159">Password: <input name="post_password" id="pwbox-1159" type="password" size="20"></label> <input type="submit" name="Submit" value="Enter"></p>
</form>

GET https://www.cryptonative.ch/

<form role="search" method="get" class="search-form" action="https://www.cryptonative.ch/">
  <label for="search-form-1">
    <span class="screen-reader-text">Search for:</span>
  </label>
  <input type="search" id="search-form-1" class="search-field" placeholder="Search …" value="" name="s">
  <button type="submit" class="search-submit"><svg class="icon icon-search" aria-hidden="true" role="img">
      <use xlink:href="#icon-search"></use>
    </svg><span class="screen-reader-text">Search</span></button>
</form>

Text Content

Skip to content


CRYPTONATIVE

Crypto since 2011

Menu
 * Home
 * About Us
 * Our Services
 * Contact


POSTS

Posted on August 26, 2021August 26, 2021


“VAMPIRE ATTACK” 1 YEAR ANNIVERSARY


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!

Posted on October 14, 2020October 31, 2020


A NEW METRIC TO MEASURE PERMANENT LOSS/WIN IN AAM PROTOCOLS

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

Posted on September 21, 2020September 21, 2020


YAM 3 – A SUPPLY ELASTIC MONEY WITH A TREASURY


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

Posted on September 15, 2020September 15, 2020


INSURANCE STREAMING IS THE WAY TO GO


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

Posted on September 8, 2020October 30, 2020


LIQUIDITY IN CRYPTO HAS A MARKET ANOMALY BY PRICING LONG-TERM LIQUIDITY EQUAL AS
SHORT-TERM LIQUIDITY AND THIS LEADS TO OPPORTUNISTIC LIQUIDITY.


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

Posted on September 2, 2020October 14, 2020


AVERAGE LIQUIDITY COIN AGE (ALCA) AND LIQUIDITY COINDAYS DESTROYED SMA (LCDDSMA)
– A NEW METRIC FOR STICKINESS OF LIQUIDITY IN A LIQUIDITY POOL


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

Posted on September 2, 2020September 3, 2020


PROTECTED: SUSHI WRAP – A GAS EFFICIENT LIQUIDITY MIGRATION ALGORITHM

This content is password protected. To view it please enter your password below:

Password:

Posted on August 28, 2020October 1, 2020


CELL – AN AUTONOMOUS EVOLUTIONARY PRIMITIVE FOR A NEW FINANCE

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.

Posted on August 25, 2020November 9, 2020


VAMPIRE ATTACK – AN ATTACK ON LIQUIDITY DEPENDENT PROTOCOLS


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.

Posted on August 21, 2020September 16, 2020


MIGRATION MINING (MM) – A NEW FORM OF INCENTIVE FOR CRYPTO PROJECTS TO GET
LIQUIDITY INTO A LIQUIDITY DEPENDENT PROTOCOL


MIGRATION MINING (MM), A NEW MINING VARIANT

Migration Mining (MM) - a new form of incentive for crypto projects to get
liquidity into a liquidity dependent protocol.


EXECUTIVE SUMMARY

Migration minings (MM) goal is to suck liquidity from project A to B. It has 6
main purposes:

 1. Minimal cost for project B to get a lot of liquidity rewarded by project
    token B
 2. Lock-up migrated liquidity in project B for an extended time
 3. Have a clear target group with existing liquidity provider on project A
 4. Make migration more easy, because it only needs 1 tx (and no waiting time
    for get several tx to get mined)
 5. Allow small pool owner to migrate with minimal cost, because migrate is
    rewarded by project token B and payed by others.
 6. Meme Power, because its something new! Migration mining woke - Liquidity
    mining broke!


USER STORY FOR MIGRATION WITH MIGRATION MINING

User visits migration page of target project B and will see a list of liquidity
token he/she owns from project A. Now he/she selects one or several token and
makes an approval tx to every liquidity token from A and can individually set a
lock-up period from 60-360 days.

Reward in project token B is calculated and shown. He/she makes an approval tx
to liquidity token and makes a tx to set the lock-up period. Then he/she waits
until migration is completed.


UNDER THE HOOD

 1. User approves liquidity token from A with one tx
 2. User set a lock-up period with another tx
 3. Somebody calls migrate for the contract and pays for the gas, (this person
    gets project token B for paying eth needed for the migration)
 4. migrate:
    * withdraw liquidity from project A -> get liquidity from project A
    * supply liquidity to project B -> put liquidity to project B with a lock-up
      period
    * send dust of unused liquidity back to owner
    * send reward token to owner


MIGRATION MINING ADDS A LOT OF COMPLEXITY TO MIGRATION

 1. rewards in project token B should be based on $ value
    
    * for $ stablecoin pools this is easy to calculate (2x the stablecoin)
    * for eth pools an oracle is needed
    * for other pools without $ stablecoin or eth at least 1 oracle is needed

 2. To prevent migration washing a lock-up period must be applied for a time
    range from 60 to 360 days. This also has the very important side effect not
    only to migrate liquidity but also to hold!

 3. To prevent people adding liquidity to project A for migration mining to
    project B a whitelist/snapshot has to be done (But how? And why should
    project B care about this?)

 4. How to make this fair? Is it a fixed pool of project token B to distribute
    or is bound on migrated value? How long do we allow migration mining?
    Maximal duration is the minimum lock-up period. If we pay people calling
    migrate and pay them in project token B how do we adjust changing gas price?


RISK

 * It opens up a liquidity war with project A (And ad lot of additional stress
   for ethereum)
 * If successfull, other projects will make migration mining too and this time
   project B may lose liquidity
 * How does-lock up work? This has to be implemented in project B and adds
   complexity and additional risk to the protocol.


FURTHER THOUGHTS

 * If standard liquidity mining is done, an incentivize lock-up period may be a
   good idea anyway, if reward is adjusted accordingly!

 * To do this right, it's a lot of work, needs audit and UX has to be slik!
   
   by martin krung 2020-08-23


SIMPLE MIGRATION, AS IMPEMENTED BY HTTPS://1INCH.EXCHANGE

https://twitter.com/1inchExchange/status/1297182579829936128?s=20

Code here:
https://github.com/CryptoManiacsZone/1inchProtocol/blob/feature/mooniswap-migration/contracts/OneSplitMooniswapMigration.sol


USER STORY FOR SIMPLE MIGRATION

User visits migration page of target project B and will see a list of liquidity
token he/she owns from project A. Now he/she selects one or several token and
makes an approve tx to every liquidity token from A. Then he/she waits until
migration is completed.


UNDER THE HOOD

 1. User approve liquidity token from A with one tx
 2. Somebody calls migrate for the contract and pays for the gas
 3. migrate:
    * withdraw liquidity from project A -> get liquidity from project A
    * supply liquidity to project B -> put liquidity to project B
    * send dust of unused liquidity back to owner


POSTS NAVIGATION

Page 1 Page 2 … Page 12 Next page

Martin Krung and Fabian Thommen are two crypto natives (2011). We share our
researches and knowledge here. For more info about us read on here or hire us
,if you need some help.


CRYPTONATIVE NEWSLETTER

If I publish things, once in a while, you will get it to your inbox first!


RECENT POSTS

 * “Vampire Attack” 1 year anniversary August 26, 2021
 * A new metric to measure permanent loss/win in AAM protocols October 14, 2020
 * Yam 3 – a supply elastic money with a treasury September 21, 2020
 * Insurance streaming is the way to go September 15, 2020
 * Liquidity in crypto has a market anomaly by pricing long-term liquidity equal
   as short-term liquidity and this leads to opportunistic liquidity. September
   8, 2020

Search for: Search


ARCHIVES

Archives Select Month August 2021  (1) October 2020  (1) September 2020  (5)
August 2020  (3) July 2020  (2) June 2020  (13) May 2020  (12) April 2020  (1)
December 2019  (1) July 2019  (3) June 2019  (3) May 2019  (6) April 2019  (2)
March 2019  (2) November 2018  (1) May 2018  (4) February 2018  (1) January 2018
 (6) December 2017  (11) November 2017  (6) August 2017  (3) June 2017  (2) May
2017  (6) March 2017  (17) February 2017  (5)
 * E-Mail
 * Twitter

Proudly powered by WordPress