Use an oracle to profit from arbitrage about v1-contracts

[gundas]

@Choicethoery - once the price ratio is set, the liquidity providers cannot change it. Every subsequent significant price move will incur loses for the liquidity providers. The only rational choice for the liquidity provider is to remove liquidity once the rate becomes incorrect or to do arbitraging himself (thus, taking the assests from other co-providers on that contract).

Ok, was not correct in my statement above. If there is only one liquidity provider, to avoid losses he/she can adjust the price ratio by transferring directly Tokens or Ether (selfdestruct(uniswap_contract) ) to the contract :)

[Choicethoery]

Using the MakerDAO oracles would be a good way to reduce the risks associated with centralization.

The gas cost increase might be substantial.

The incentive is there for liquidity providers to provide an accurate price so I'm not sure how much the possible arbitrage is so much the primary problem as much as simply increasing liquidity participants.

[haydenadams]

@gonchs It's an interesting thought but... I'm not particularly interested in adding points of centralization. At least not to the base system. Custom pools - exchange contracts that integrate the same interface but are not deployed from the factory - are the best place to experiment on this. Custom pools are able to trade against the public pools using the tokenToExchange functions.

@Choicethoery Maker price oracles are not particularly decentralized yet. Once Uniswap gets a large enough liquidity pool it could become a good MakerDAO price oracle.

[gundas]

@haydenadams - the problem is, that if only rational (arbitrage) traders are using the UniSwap, the UniSwap will always loose funds on any price movement. UniSwap can only work if there is enough "end user" trading who need the token exchange, but do not care about the price too much.
But in this case, one should wonder if the 0.3% fee is enough. The fee should depend on the price volatility of the assets traded (the higher volatility, the higher the fee) - one could take historical price movements of assets pair and simulate the losses from arbitrage, and decide what kind of fee would cover for those losses.

The only solution I could think to fix this is using an Oracle to set the price - it would be much cheaper than the services of arbitrage traders.
I also created an alternative proposal for an Oracle - see issue #19

[gundas]

The incentive is there for liquidity providers to provide an accurate price so I'm not sure how much the possible arbitrage is so much the primary problem as much as simply increasing liquidity participants.

@Choicethoery - once the price ratio is set, the liquidity providers cannot change it. Every subsequent significant price move will incur loses for the liquidity providers. The only rational choice for the liquidity provider is to remove liquidity once the rate becomes incorrect or to do arbitraging himself (thus, taking the assests from other co-providers on that contract).

[haydenadams]

@gundas One thing I'm interested in setting up is a smart contract that allows a swaps + liquidity deposits to be made synchronously to allow liquidity providers to deposit liquidity at an exact specified rate.

[deacix]

Centralization is no way!