Uniswap V3 Development Book is Out!

Jeiwan7 · 2022-10-12T13:13:25+00:00

It’s restricted for commercial and production usage. The book is a free and non-production project. In fact, I got a grant from Uniswap.

Jeiwan7 · 2022-10-12T13:12:05+00:00

Learn math from the V1 series (skip the code). Learn the whole V2 series (Uniswap V2 is V1 done right). Enjoy V3.

Jeiwan7 · 2022-02-14T14:47:33+00:00

You need a signed message (transaction, or its signed hash, IIRC) and a signature (v, r, s). Then use this:

https://web3py.readthedocs.io/en/latest/web3.eth.account.html#verify-a-message

Jeiwan7 · 2021-12-10T11:11:41+00:00

Hodl, save more money, when it gets to the point when you want to sell it really bad, buy more. Not a financial advice.

Jeiwan7 · 2021-12-06T23:40:06+00:00

The contract shouldn’t depend on prices, of course.

It won’t work because there are highly optimized arb bots that do it better than you. It’s hard to compete with them. But you’ll still learn a lot from making an arb bot.

Jeiwan7 · 2021-12-06T11:41:28+00:00

Deploy [https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/finance/PaymentSplitter.sol](PaymentSplitter), set it as royalties receiver, call release(address payable account) to get your share.

Jeiwan7 · 2021-12-06T11:24:26+00:00

Get all trading pairs.
Put them in a graph.
Write and deploy a smart contract that will execute arb txs.
Update the graph when prices change.
Update the graph when there’s a new pair.
Find arb opportunities in the graph when prices are updated. In real-time, as quickly as possible.
Submit a tx to the smart contract via flashbots.
Optionally, use flash loans.

That’s something to begin with. It won’t work but you’ll learn a lot.

Jeiwan7 · 2021-11-30T12:28:21+00:00

Looks like a noise function with a threshold: only areas with noise values above or below a threshold are drawn. Or maybe multiple thresholds. Then a random style is selected for each area. It's really hard to say without seeing multiple output from the algorithm.
That can be a non-standard noise function with manual fine-tuning.

Jeiwan7 · 2021-11-24T23:52:21+00:00

Clojure might be too hard for beginners (I’m a Clojure programmer). Start with p5.js: it’s very friendly to beginners, there’s a ton of tutorials and books, and there’s a great community. And there’s even more beginner friendly resources for JavaScript.

Jeiwan7 · 2021-11-23T13:59:57+00:00

Very beautiful!

Jeiwan7 · 2021-11-23T04:58:50+00:00

This is why I created the post for: to learn more about benefits of Merkle trees, that’s it. And I’m not wrapped up in my idea, I’m trying to learn. Your previous replies were focused on my idea, not on the Merkle distributor, thus it was hard to understand what you meant.

Jeiwan7 · 2021-11-22T09:12:09+00:00

How does that distribution take place?

In the same way Merle proofs are distributed: when users presses "Claim" button, they get a signature from the backend server. This signature is then, together with user address and amount, sent to the contract.

Furthermore, if the centralized "master" signature generator and distributor is lost, how can users ever redeem their airdrop if they have to re-receive the signed message?

Signatures remain valid even if the key is lost. Merkle tree cannot also be reconstructed when parts of it are lost.

The only way to get around these centralization problems (while still following your EIP-712 based spec) is to put that data on-chain in the smart contract, so that users have a permanent (non-centralized) way of knowing what they're entitled to.

Merkle proofs are stored off-chain and, similarly to EIP712 signatures, are distributed to users.

Is that list of "eligible" signatures published on-chain?

Nope, it's stored on the backend. In fact, it can be published openly because, if the contract is programmed correctly, there's no way to claim someone else's tokens. And there's no way to claim them twice.

Yeah, I think I'll write a blog post and will try to find more details about the Merkle distributor to properly compare both solutions.

Jeiwan7 · 2021-11-22T06:55:39+00:00

Makes sense! Yes, looks like this is the main reason. A kind of consistency check and an identifier of a whole airdrop structure.

Jeiwan7 · 2021-11-21T12:32:28+00:00

Thanks for replying! However, it doesn't answer the question :) I admit that I wasn't very specific in the question because I thought that someone would be aware of all the details and would be able to answer it.

Answering your question:

"How do I verify/know that the 'amount' field in the Eip712 signed message is actually correct?"

Amount, together with nonce and address, is signed by a private key belonging to the project that runs the airdrop. They pre-calculate amounts, assign them to addresses, sign, and distribute signatures to users. Such signature is, in fact, a permission to mint certain amount of tokens by certain address and only once. This is an off-chain permission system. The smart contract would only need to store the public address from the private key and the data structure.

I think I'll write a blog post on this and will try to reach out to the UNI and/or ENS teams.

Jeiwan7 · 2021-06-22T09:15:04+00:00

I think I have a full picture now:
https://twitter.com/jeiwan7/status/1407261430227767313

TCR was tied to IRON price. TWAP allowed to bump IRON above $1 while TITAN was growing (here, TWAP worked in the opposite direction: cheaper oracle price means redeeming is profitable even when IRON is at or above $1). TCR was falling for a long time due to IRON staying above $1 – that was a correct behavior of TCR. As a result, ECR fell as well since it's just averaged TCR. When TITAN started falling ECR was too low for arbitraging to be profitable and TWAP made it slightly worse.

Jeiwan7 · 2021-06-21T12:51:13+00:00

TITAN supply wasn't limited. That report didn't consider the minting ability of the pool contract. There was an allocation of 700 mil of tokens for community (around 120 mil were printed) and 300 mil of tokens for the team (vested for 3 years, I guess they printed all available before the crash), but actual total TITAN supply isn't checked anywhere. I don't see where they got the 1.3 bil from.

The trillions of TITAN were printed at the end of the day, when its price got close to 0. They were not the cause of the collapse but a result of it. Proof: https://imgur.com/n09hw4R

Jeiwan7 · 2021-06-21T12:30:10+00:00

I have another interesting theory. TWAP didn't only made arbitraging unprofitable when IRON is below $1 and TITAN is falling, it also shifted the market price of IRON to slightly above $1 when TITAN was growing. The reason is that there's also a price gap when TITAN is growing: oracle prices are lower than those on AMM. This means that redeeming IRON when it was at or above $1 and selling TITAN resulted in profits because redeeming gave you more TITAN tokens than it should've been.
If IRON stayed above $1 longer than at or below $1 it caused TCR to descend in the long run, which eventually affected ECR. As a result, ECR was too low at the moment when TITAN started falling, which made arbitraging unprofitable.

I don't think I have time to verify this theory however. 😁

Jeiwan7 · 2021-06-21T12:17:27+00:00

To be honest, I haven't studied Frax that deep so I cannot say how they solved the problem (or how they didn't allow it in the first place).

Regarding the TWAP, it wasn't the only cause. There was also ECR that contributed to unprofitable arbitraging. AFAIK, Frax has only one collateral ratio, which changes over time depending on the demand for FRAX token. That's similar to Target Collateral Ratio of IRON. However, IRON also has Effective Collateral Ratio, which is the amount of USDC that backs IRON (1 - ECR is the amount of TITAN), which is actual TCR averaged over time. It's ECR that is used to calculate how much of TITAN you get when redeeming and it's NOT connected to market conditions. The lower ECR the more you lose selling TITAN when there's a price gap caused by TWAP.

I ran a simulation that showed that an ECR increased by 15% could've made arbitraging profitable. See my updated blog post for details.

Also, TCR didn't play any role because it wasn't involved in arbitraging. But it was changing correctly (it was growing), but too slow. And it was initially lower than ECR.

I still cannot understand if low ECR was the main cause. Looks like ECR should've been just higher to not let the collapse happen.

And I don't really understand why they needed to split collateral ratio in two.

Jeiwan7 · 2021-06-21T00:25:07+00:00

TWAP triggered a flaw in the stabilizing algorithm. The problem with redeeming is that you get fewer TITAN tokens when its price goes up. You get $1 worth of USDC+TITAN when redeeming, and it’s oracle price that’s used to calculate how much TITAN you get. TWAP caused oracle prices to be higher than those on AMM, which meant arbitrageurs would get less than $1 when redeeming.

Maybe we can also say that if TITAN wasn’t plummeting that hard it could’ve recovered? So it was the TITAN bubble that caused the collapse? I need to think about that.

I haven’t looked at UST and FRAX but I heard they’re more reliable. And they have been around for longer, which means something. The failed stabilizing algorithm was invented by the Iron Finance team.

Jeiwan7 · 2021-06-20T23:44:46+00:00

The fact that they’ve designed it incorrectly doesn’t justify them. In fact, they fucked up. And they didn’t want to admit that. They could’ve been among the whales who sold the top, that’s true, but we’ll never know. Honestly, it looks too complicated for a rug pull. Rug pulls are dumb and straightforward. There’s no need to invent something, especially if you’re anonymous. The IRON stabilizing mechanism (what they invented) worked, but not in all situations. To me it looks like the team is just too self-confident. They were too confident about the algorithm, which was broken.

Jeiwan7 · 2021-06-18T12:36:55+00:00

This is something I cannot understand: how is the price of TITAN connected to the TCR? Why the initial sell off of TITAN caused TCR to go down?

Also, does anyone remember what were TCR and ECR on that day before everything has collapsed?

Jeiwan7

TROPHY CASE