On April 22nd, we hosted a live AMA Spotlight with Ohad Barta from StarkWare and Brendan Chou from dYdX. Ohad and Brendan discuss:
Their backgrounds and experiences moving into the crypo industry
dYdX’s decision to move to Layer 2 and comparison to Layer 1
dYdX’s decision to pick StarkWare as a partner
How StarkEx works and different data availability modes
Centralized vs. Decentralized parts of the technical stack
The vision behind StarkNet and futures plans
Nuances on the Stark Key and how it is used in the Layer 2 system
Oracle performance on Layer 2
ZK Rollups vs. other Layer 2s like Optimistic Rollups / ZkSync
The relationship between spot and derivatives
And more...
A redacted transcript is available below:
David (dYdX): Thanks everyone for joining in. My name is David Gogel. I'm on the growth team at dYdX. I'm excited to be joined today by Ohad from StarkWare and Brendan from dYdX. We'll be discussing community questions relating to dYdX's technical implementation of StarkEx for cross-margin perpetuals on Layer 2, powered by StarkWare. Brendan, Ohad, can you share more about your backgrounds and how you joined dYdX and StarkWare respectively?
Brendan (dYdX): I'm a software engineer by trade. I went to Princeton and then went to Bloomberg and then Google, so just really monolithic, large software companies, where I learned some skills, how to code, what it looks like at a larger company, and was looking for something different. I was roommates with Antonio in college, and so I knew what he was doing. He went to Coinbase right after college so I'd always ask him to explain to me what Bitcoin was, and how it worked, and I never quite got it, but I started looking into things more during the height of 2017.
I knew he was starting his own company. So eventually we have this event each year where all the ex-roommates get together for New Years, and we were talking over that period of time and that's when I decided to join. I was in New York at the time, but it definitely helped knowing someone personally to make that leap to move across the country and change jobs and get into this crazy crypto thing. That's how I got into everything.
David (dYdX): And Ohad, how did you join StarkWare?
Ohad (StarkWare): I've known Eli Ben-Sasson, one of the co-founders of StarkWare, since 2011. I wrote for him part of the first PCP Prover and Verifier, which were old parallels of STARKS and SNARKs that are used today. I then spent six years gaining programming experience in the Israeli intelligence. I later got my Masters degree in crypto with Prof. Yuval Ishai. We had a paper in crypto last year. After that, I contacted Eli, and asked how things are at StarkWare. I decided to join Eli after seeing how the space of proof systems became so much more mainstream in the last six years.
David (dYdX): dYdX launched cross margin perpetuals on Layer 2 publicly a few weeks ago. Brendan, you can give more context on why dYdX decided to move to Layer 2 and the benefits of the new Layer 2 product versus the Layer 1 product?
Brendan (dYdX): There's a number of reasons. The most important is just the order execution piece of it. And previously that was taking a whole Ethereum transaction to settle each trade on chain. And that brings a number of challenges with it. First of all, it's not instant and can be front run in a number of ways. So that creates some uncertainty for programmatic traders, for basically everyone, if you have to wait for a block to be mined before your trade goes through.
Also it just costs a lot of gas that we have to send for our own transactions. So since it's costing us money, that's not sustainable for us. So a lot of that we have to pass on to users with either higher fees or higher minimum trading amounts and stuff like that. So basically it wasn't good for anyone as Ethereum scaled or as the number of users scaled, but Ethereum didn't. So I think that was the main motivation for us, was this order execution part.
And the other problem that we saw with Layer 1 was the speed at getting Oracle prices on chain as well. When the price changes dramatically, the gas costs go up, the Oracle prices get mined into Layer 1 a lot slower, then that creates some additional risk for users. So again, we have to pass that on in terms of offering lower leverage, having a more aggressive liquidation system that punishes users more for being liquidated, and again, costs a lot of gas and it's slow and contributes to less security overall for the system. So I think those were the main factors that we were looking at, moving to a Layer 2, to get more instant finality, which would just lead to a better experience and lower fees for everyone.
David (dYdX): Why did you pick StarkWare as a partner to build a Layer 2 system?
Brendan (dYdX): The main thing that we were looking for was to move fast, one we realized this was a problem. Things always take longer than you think they're going to take. We really wanted to go with something that we knew we could basically launch within a few months rather than something planning to launch in a few months, because that can turn into a year or more depending on finding the unknowns unknowns that come along the way. So we wanted to remove a lot of the risk and work with someone who had been doing it on Mainnet ideally for a while. And StarkEx had been doing that with DeversiFi and had a lot of success doing that, and had a really good reputation in general from people that we spoke to. So I think those are the main contributing factors there.
David (dYdX): Ohad, can you provide an overview of StarkEx? What is it and how does it work?
Ohad (StarkWare): StarkEx is the current scaling solution that StarkWare provides to apps on Ethereum. It gets a sequence of transactions from the sequencer, in this case dYdX, it runs them internally and makes sure that everything checks out and makes sense. Then it moves the transaction to the Cairo program, which is the magic beneath all that. Basically, the Cairo program can represent any statement (it is Turing Complete). The Cairo compiler takes the Cairo program and compiles it into a trace, that can be then transformed into a STARK proof by our prover. Then we send this proof on chain to be verified by a Verifier in Solidity. The magic is that the cost of verifying the proof of chain is now only polylogarithmic compared to the cost of actually running all of those transactions in Ethereum. In addition, you can be certain that if the Verifier accepted the proof, the proof is legal. So we have instant finality.
David (dYdX): Can you describe the different modes of StarkEx and their trade-offs?
Ohad (StarkWare): With Validium, we don't publish them via state, which is relevant to knowing users' balances, for example, on chain. This is because it's very, very costly to do so: even though it costs only a fraction of actually executing the transaction, it's still non negligible and grows linearly with the number of changes. Instead we say, "Okay, we have this trusted committee of servers,". This is the path taken by DeversiFi and Immutable, for example, which have several respectful committee members. In this approach, And as a condition to sign a batch, the committee members have to attest that they all know all the relevant data that users would use in case of, for example, the operator goes down.
In the ZK-Rollup we publish on chain the new balances every time they update. So you have more trust in the system but it also costs more.
David (dYdX): Brendan, dYdX's implementation of StarkEx is a ZK-Rollup, not Validium. Can you describe the thought process there of why ZK-Rollup was a better mode for dYdX?
Brendan (dYdX): Actually we didn't have super strong thoughts on this. I think Ohad described the trade-offs pretty well there. It basically just makes the data available for everyone, but the cost of publishing is that it takes more gas to do so. So we decided to keep it on chain for now and do a roll up because we felt like we could handle the costs. Currently we're not passing on the gas cost to users. There's no gas fees for trading. The price of ETH continues to increase or the usage of the network increases, then we can in the future cut out that piece where we're publishing all the data to the chain, and then perhaps bring in some additional committee members to verify that the data is stored in multiple different places and available to multiple different parties so that users don't lose track of what the actual current balances on the chain are. As Ohad mentioned, that's important. If they need to basically prove the position that they had and exit the system.
But it's something we'll just take a look at going forwards, because if it gets too costly to do then, as I mentioned, those costs have to be passed on to the users eventually, if it seems like it's in the interests of the community and other users, and that's a piece that we can cut out and move off chain and get even more gas savings to everyone.
David (dYdX): With the transition to Layer 2, there is less data that is available for people to see on a block explorer. Ohad, can you describe what data is available on Layer 1 for users to see?
Ohad (StarkWare): The data on Layer 1 that is available is the balances of all the users include the synthetic assets and the funding indices: everything which is relevant to know how much money we really had when the last batch got accepted. The transactions themselves aren’t published on chain, and this is both to save gas because balance changes are much less data than all of the transactions and also to keep trading strategies private.
David (dYdX): As a user, how can I trust that the transaction data that is kept off of Layer 1 is actually correct? What's the mechanism to ensure the validity of everything that happens off chain?
Ohad (StarkWare): Before when I discussed StarkEx, I said it's all based on the Cairo program that is the center of everything there. So what happens is that the Cairo program will get the sequence of transactions. In addition to the commitment on the new state outputs, it adds all the balance of the positions that were changed during the batch. And this output is linked to the proof. If you can't show me a transaction with this data on chain, then the proof won't get accepted.
David (dYdX): That's super helpful. Ohad, can you provide an update about the status of StarkNet and what the vision is there?
Ohad (StarkWare): Maybe I'll start with what StarkNet is, because so far we've talked only on StarkEx. StarkEx is cool. It really helps you right now, but it's not good enough in the long term. The reason it's not good enough in the long term is that currently StarkEx requires an operator to work with it, and this is bad both from a centralization perspective and from a technical and regulation perspectives. StarkNet means taking all this magic of Cairo and Prover / Verifier in the center of StarkEx, and instead working against one sequencer that will just build an entire side chain, where each block in the side chain will be proven by comparing to Cairo and then proved like we prove today, and even using the same verifier as we use today.
Of course, this will take some time, so we go in steps. So in the end of May we will release a demo on Ropsten of StarkNet that will allow writing custom contacts. We'll also have an AMM contract, as an example, but it wouldn’t allow Layer 1 to Layer 2 interactions yet.Then, a few months from there, we'll start expanding StarkNet to allow inter-communication between contracts and L1 to L2 interactions.
And then the next thing we'll work on is the decentralization of the operator. So instead of one sequencer that sequences all those smart contracts that users submit, we’ll indeed have a full side chain with miners and everything.
David (dYdX): Brendan, just stepping back, as part of the onboarding flow to dYdX, users connect their Ethereum wallets and sign transactions. But for the first time, users have to create a Stark Key. Can you describe what a Stark Key is and how it's used on dYdX?
Brendan (dYdX): Basically it's similar to an Ethereum private key. It's just a way to cryptographically verify that everything you sign is coming from your private key. You have to use a different private key or a different kind of elliptic curve basically to sign things that are compatible with the STARK system. I don't have a ton of technical details on it. I'm sure Ohad has a better idea of why that is. But essentially it's just another key that you're keeping track of to sign everything.
We didn't want to put that burden on users to have to remember a whole other private key. They're used to already guarding their Ethereum key. We don’t want them to worry about keeping track of this other thing, and if they lose it, that's bad. We came up with a system to allow them to derive it using their existing key. And that's basically from doing hashing on a fixed signature from them so that it's derivable as long as they have their Ethereum private key. So they can never lose their private Stark key as long as they have their private Ethereum key.
And that's really helpful because, as I mentioned, they don't have to keep track of two things. And also similar to how you can't really forge someone's Ethereum signature or find a hash collision, their private Stark key remains very secure as well.
David (dYdX): Do I have to safeguard my Stark Key in the same way that I safeguard my private key? If someone is able to get my Stark Key, are they able to access my funds?
Brendan (dYdX): That's kind of a complicated question. Yes, you should definitely keep it private. I'm just trying to think about the worst thing that someone could do, I guess in this case they could potentially sign orders on your behalf. However, if that's all that they have, then even if they were to withdraw your funds to Layer 1, they could not move them from the contract. They would still need your Ethereum key to do so. Additionally on our side, we also have API keys and secrets to prevent people from doing these things without explicit permission.
So similarly, if just your Stark Key is leaked, then basically on our dYdX side, we still don't accept requests unless you also own the API key. The API key is similar. It's another basically small set of private keys. That's also derivable from your Ethereum private key. So you can also have at least those, if you have your Ethereum private key. But also you would need basically all of these. All three are basically just the Ethereum private key in order to steal funds still. So it's not good if someone has your Stark private key, but there are still a number of safety mechanisms to prevent the damage that someone could do there.
David (dYdX): Ohad, can you describe which hardware or software wallets currently support Stark Keys and what is roadmap for greater adoption?
Ohad (StarkWare): Currently, the Ledger wallet natively supports Stark Keys and the application of StarkWare, and a couple of other wallets. I believe Authereum supports it, although it was deprecated recently. For any other wallets, we have a JavaScript library that asks the wallet to sign with the Ethereum key and derive from this signature the Stark Key, as Brendan mentioned. So this is how MetaMask and all the common wallets currently work. We plan to join more wallets in order to make them natively support Stark Keys. It's something we keep pushing for. With more and more projects like you coming along, I think it will happen quite soon.
David (dYdX): There was a lot of buzz over the weekend following the flash crash in the crypto markets. StarkWare published a blog post about Oracle prices on Layer 2, which seemed to be a big issue on other DEXs. Brendan, how does dYdX's StarkEx implementation use Oracle prices and how is it different from Layer 1 Oracles?
Brendan (dYdX): So right now we're just using Chainlink Oracle. We're talking with a couple other Oracle providers to see if it makes sense to do some collaboration there. But as I mentioned, we're looking to move really quickly and Chainlink, to their credit, was able to spin up just a ton of different trading pairs for us, that support Layer 2 keys or the Stark keys, as we mentioned before.
We're working with a sole Oracle provider right now. But basically, they're sending us cryptographically signed prices. We're able to cryptographically tell that they're coming from the signers or the people whose private keys that we trust. And then we basically aggregate those, and using the median of that, that can become the Layer 2 Oracle price. All the prices are signed with timestamps and stuff like that and the asset name. They are basically aggregated together into taking the median of some quorum there. So that's how we're doing it on Layer 2. It's a very similar pattern to what you see on Layer 1 with a lot of the Oracle providers there.
Except instead of requiring each Oracle to send a transaction, we're doing it similar to batching all the signatures together in that instead of requiring a transaction to be mined into Layer 1, they can basically go straight into the Layer 2 block and then eventually on chain when the whole rollup of block is published.
David (dYdX): Ohad, can you describe what happened this weekend and how Layer 2 Oracles helped maintain pricing on the dYdX exchange?
Ohad (StarkWare): Last weekend, we had a 20% drop in Ethereum prices, over not that many hours. And the big advantage of dYdX's over other DEXs is we're continuously getting all of those prices from Chainlink and can, in real-time, react to price changes without having to wait until a transaction is accepted on chain. Then immediately after we have the price from Chainlink and we use it, we can send followup transactions through this price, again, without waiting for anything happening off-chain.
And this is what allows the dYdX system to run. I think it was over 1,000 liquidations over 1 hour, which wouldn't be possible on Layer 1 with many competitors sending transactions at exactly this time for the same reason. So this is why the smaller latency improves the system stability.
David (dYdX): Ohad, can you describe the role of the ZK prover today, and what are future plans around decentralizing that part of the tech stack?
Ohad (StarkWare): Currently, of course, StarkWare runs the provers. The provers get Cairo programs from the StarkEx component and basically produces the proofs and then sends on chain. I'm sure that the provers would be decentralized in StarkNet somehow, but since this is the last step of StarkNet to take place next year, I can't really commit to the way we do it.
David (dYdX): From a user's standpoint, what are the risks today for the fact that the ZK prover is centralized? Can you censor my transactions? Does that prover have any downtime? How does that affect the overall stability of the system?
Ohad (StarkWare): Provers shouldn't have downtown. We use the best services Amazon can offer, and they should be live 24/7. And even if something happens and they are down for a short while, it wouldn't affect the system.
As for the censoring question, this is not related to the fact that the provers are centralized so much that it relates to the fact that the sequencing itself is centralized. So potentially your transactions could be censored. However, your withdrawals can't be censored.
If you send a transaction through the system and for some reason you see that the system ignored you, you can submit an Layer 1 request and withdraw, or even trade your synthetic assets so you won't have to pay the maintenance margin on the synthetic assets you have. Basically, using a sequence of such Layer 1 transactions, you can fully exit the system. And if the operator chooses to censor those requests backed up by Layer 1 proof as well, then you as the user that was censored by the system can now go to the Layer 1 smart contact and tell him, "Look, smart contract, I sent this withdraw request a few days ago and I'm still censored." And then: everything shuts down, so of course, it's not in our interest to ever do such a thing.
David (dYdX): Brendan, how is the dYdX team thinking about maintaining non-custodial trading on Layer 2? And what are some of the trade-offs that the team had to make relative to Layer 1?
Brendan (dYdX): Right now we're basically choosing, as Ohad mentioned, the ordering of transactions. That's a little different than Layer 1 where it's just whoever has the highest gas price usually is who the miners are going to select. So it's a little bit like we're the miner for every block. But as Ohad mentioned, there are certain protections in place to allow people to withdraw their funds, no matter what, so you can't censor all transactions.
People can agree to do a trade, send it back to Layer 1 and we're basically forced to include that in the Layer 2 block. Or submit a withdrawal request, which we're forced to give them as well. Yeah. So as long as people can get their money back, we run into the same issues that we have in Layer 1, which is it's still non-custodial in the sense that we can't steal the funds, but currently since everything is going through a more centralized matching engine, we can choose to not allow certain traders on the system.
So thinking further ahead in terms of our strategy and opening things up, that's one of the things we'll be focused on going forward, is the decentralization especially of the order execution. But the non-custodial nature is quite far ahead, but more of the decentralized nature, especially if the order execution is something that's going to be really tricky is all, I think.
David (dYdX): Do you have any preliminary thoughts on what a decentralized order book and matching engine could look like?
Brendan (dYdX): It's a difficult question, so I won't go too much into it here. There's a lot, in general, even in traditional finance, a lot of different kinds of trading systems that you see. We're using more of an order book strategy right now. I know 0x and some other people are using more of an RFQ system, or request for quote system, where you basically ask someone to quote you a price and then agree on it. So that's a little bit different than how an order book works.
So it might involve looking more into those kinds of models or even Uniswap, doing more of an AMM type model, could open things up. I think there are a lot of different ways it can go. I don't have anything super concrete right now.
User: My question relates to specifically the market and how the different assets are being added. You've got Link, Uniswap, Solana, and Sushi, if I remember off the top of my head correctly. Going forward, would dYdX be looking at ways to engage the community on which new projects to add or would it be done internally?
Brendan (dYdX): That's definitely something we're looking to engage the community more on and give people more of a say. We're here to be an exchange, and probably the most important part of that is to let people trade what they want to trade. And then also it's important to us to engage a lot of the community and figure out, give people a bigger say in what they want to see added. So definitely that that'll be a priority for us. I think probably in the next few months, in 2021, we're hoping to give people more of a voice in that. So definitely.
David (dYdX): I would add that one of the other benefits with moving to Layer 2 is that we can add a lot more markets, much more rapidly. In the last two weeks, we added four new markets and we're currently targeting adding one to two new markets every week for the rest of the year. We’re targeting 30 to 50 perpetuals by the end of the year. The decision making process around that is very focused on listing the tokens that our users want to trade. Our hypothesis is that people want to trade top DeFi tokens as well as your top Layer 1 tokens.
That's the initial framework that we're using around selecting what we want to list. Certainly we always value community input and if there are specific pairs that you're interested in, definitely feel free to share that with one of the admins here so that we can take that into consideration.
Brendan (dYdX): To answer the other part of your question, I think a lot of it is who is choosing right now. And yeah, it's basically the dYdX team choosing that right now. Just to be clear, yeah.
David (dYdX): There's a lot of discussion about different Layer 2 solutions, and there was a recent announcement from zkSync and their vision for zkPorter, which I guess is very similar in some ways to StarkWare's Validium mode. Ohad, do you have a view on zkSync and what their vision is, and how it's different from what StarkWare is trying to build?
Ohad (StarkWare): First, just to get the zkPorter part out of the way, zkPorter is this idea that combines between the Validium and the ZK-Rollups approach we discussed earlier. We at StarkWare call it Volition and discussed it even as far back as June 2020. We are very happy to see that others in the space are adopting some of our ideas, and that it will happen on many Mainnet soon.
Regarding zkSync in general, I think from a technological standpoint they are somewhat close to what we are doing in the sense that they are the other company that offers general purpose validity and proofs for scaling, starting with at least the next version, because currently they have only transfers.
I guess we have several advantages over them. For example, SNARGS need a trusted setup, which is a bit of a hassle that zkSync will have to do. And in addition, this now means that everything in the end boils down to automatic circuits where we have the freedom of using our Cairo language, which is much more convenient and also much more on Mainnet currently, we still wait for the zkSync language to be deployed on mainnet.
User: I like to live on the edge and find myself sometimes above 100% margin. And if it gets too high, I can't close positions because the closing action will result in still being over 100% margin. Is that intended or is that a bug?
Brendan (dYdX): That's currently known. I think we didn't quite anticipate how many people would be doing that. So we had deprioritized the ability to do that. But basically, eventually what we want is as long as you're closing your position, it should allow it through. There are several different validation steps in the entire flow to allow that to happen because, yeah, we basically don't want people opening positions over that limit or even in certain cases if we allow that through, it can cause the proof itself to be invalid because we're allowing somebody to take on an invalid position.
But I think right now we're probably being overly sensitive about that, and we have a few things, a few places that I think in our validation system where we're stopping that. So I think we're required people to come back down to their initial margin right now, but eventually we do want to allow that. I think a couple of people have messaged us about that recently, so I think we'll probably prioritize it going forwards. We do want to allow that to happen because, especially, I think people with large positions might not want to close all of it to go back down below 100. But yeah, thanks for the question.
David (dYdX): Ohad, can you transfer funds between different StarkWare solutions today, for example, from the DeversiFi to dYdX and back?
Ohad (StarkWare): So assuming you mean some kind of trustless or proven transfer, we don't support it yet. We intend to support it with StarkNet, which starting at the end of the year will have application communications between contacts. Then those transfers will be really easy to achieve.
David (dYdX): At some point, will users be able to transfer funds from an L2 application to another L2 application?
Ohad (StarkWare): If you consider Layer 2 applications operated by StarkWare, then for sure. I guess in the very long term we'd also like to cooperate with other Layer 2 solutions, but that's a very long timeframe.
David (dYdX): Ohad, can you describe at a high level what some of the main trade offs are between ZK-Rollups and Optimistic Rollups?
Ohad (StarkWare): So just to give a short context on Optimistic Rollups because so far we have only discussed ZK-Rollups. In Optimistic Roll-ups we get all the transactions to run off chain, and then we publish them also on chain. However, we don't publish a proof so people need to inspect all of the transactions and see whether they found something inconsistent or fraud, and if this is the case they submit a fraud proof. There are several disadvantages to this model for Optimistic Rollups.
First, you don't have instance finality and you'll have to assume that users are active in monitoring the state because the users need to have several hours in order to dispute a state update. And if no one did it because, for example they went to sleep or somehow you have a conspiracy between several verifiers that agreed to be silent about this state update, then you are doomed.
Intuitively it sounds like Optimistic Roll-ups make up for this downside by being cheaper because with them you don't have the proof.
But that's actually not true as well because for Optimistic roll-up you have to submit on chain ALL the data, i.e. all the transactions being made, when with ZK-Rollups we can with one proof prove many, many thousands of transactions (we'll soon be able to prove several thousands of transactions in one batch for dYdX). So if you take the amortized weight of transactions in a proof versus how much it costs to send it to the chain with on chain data, ZK-Rollups is also much cheaper in addition to being more secure.
I guess that the downside currently of StarkWare versus Optimism, for example, is the easiness of onboarding because Optimistic is EVM compatible. You still have to modify some stuff here and there when onboarding to Optimism, but it's much less than moving to Cairo. But with the work on StarkNet, we expect this downside to no longer exist in the very near future.
David (dYdX): Brendan, can you describe the experience building in Cairo?
Brendan (dYdX): So we didn't actually write in Cairo for this, since StarkWare has a lot more understanding and expertise in how that works. We have looked at writing some of the Cairo contracts ourselves, but just in the name of expediency, and security, and correctness of the contracts, we basically worked with them to come up with a whole new logic system that was distinct from our L1's, since we had to do stuff like cross-margining and stuff like that. So basically worked with them to come up with like the logic that needed to be coded.
And then it was mostly StarkWare who wrote those contracts this time. So we have looked with them at the current state of Cairo and given some feedback on how to make it better. But in this case it was written by StarkWare, so I can't comment too much on that.
David (dYdX): Ohad, do you have a view on StarkWare's strategy to onboard more projects onto Cairo/Layer 2? Is StarkWare working on a solidity to Cairo compiler and any ETA on when that would be available?
Ohad (StarkWare): Currently we are onboarding projects to StarkEx. We already onboarded DeversiFi, dYdX and Immutable, since June of last year and expect several more launches to be in the rest of this year. We tried to make it easy to onboard to StarkNet in many ways. Some of them maybe to improve Cairo. One year ago, writing in Cairo was like riting assembly and now it's much more like writing to C, and maybe even higher than that.
And in addition, we plan to work on transpilers from solidity to Cairo. We see it as just one of the several aspects of making working with StarkNet easy, so it's still left to be determined when that will happen.
User: I noticed there is the index price and the Oracle price and then the mid-market price. And you have a helpful page explaining the difference between those three. I'm still not totally sure why there needs to be an index price separate from the Oracle price. Do you have any disclosure or documentation about the different exchanges and Oracle sources that the platform is pulling from for those two prices?
Brendan (dYdX): So I'm not sure exactly on the help page stuff, we do need to get one up if we don't as soon as possible that contains this information. But essentially, we've talked a little bit about how the Oracle prices are much more performant on Layer 2, but they're still not up to the performance of an Oracle reporter signing every single price, every single second. So the index price is hosted mostly internally by dYdX, and it serves two purposes that are different than the Oracle price, and mostly because it needs to be more performant than the Oracle price.
So the first is, enabling things like triggerable orders. So these are like stop-losses or take profit orders, that sort of stuff. So if you have a trailing stop or a stop limit order in general, then that'll trigger off the index price instead of the Oracle price. And that's just because, as I mentioned, the performance of the index price is much faster. dYdX is basically pulling that from exchanges. So for Bitcoin, for example, we're pulling that from, I'm forgetting all the exact exchanges, but basically like six or seven spot exchanges, the Binances and the Coinbases of the world.
The other thing that it's used for is determining the funding rate. So the funding rate is determined basically based on whether the asset is trading at a premium or a deficit to the index price. So the index price needs to be really precise because you're comparing this fast moving order book to this fast moving spot price from all these exchanges. So something like the index price is able to be updated once a second, once every two seconds, but Oracle prices are typically not updated unless there's some real volatility in the market.
So you might see the Oracle price updated if the price moves by more than 25 bps or something like that, or a quarter of a percentage. But the index price is intended to update much more frequently than that, so it provides a better experience for the stop limit orders and then also it gives a more accurate funding rate. So, hopefully that's helpful and I think we plan on building out the help section and making all this information much more accessible, exactly which exchanges are used for each price feed.
User: And then it looks like according to whatever the liquidation is dependent on the Oracle price, not the index price?
Brendan (dYdX): That's correct. Yeah.
User: Why not just rely on the index price? Is it to prevent manipulation in some way?
Brendan (dYdX): The Oracle price is more secure because it's signed basically by all the Oracles. The index price is basically just maintained by dYdX ourselves. So it's basically one service that will keep track of this price. So I think it's a trade off, right? If we just liquidated based on that. So the index price is not included in the proof or anything. It's this off chain thing that we keep track of to provide a better experience in this way.
We could, for example, do everything off the Oracle price. The reason why the liquidations are not on the index price is because liquidations need to follow a certain rule set that's laid out in the smart contracts. So, we can't just liquidate people even if they're not at low margin, for example. So that all needs to be included in the roll-up proof itself.
User: The more academic question I have is with respect to this decision the average trader makes between using margin versus using perpetual futures, since dYdX offers both products, I'm sure you guys have thought about that. And I know that perpetual futures are extremely popular in the crypto market and that's one reason it looks like you guys have moved aggressively into focusing on perpetuals, which makes sense. One thing I'm wondering about is what impact the perpetual market has on the spot market and vice versa. I imagine there are studies done on this, and maybe it doesn't matter that much to the average trader, they just want to make money. But I'm wondering, I imagine that the market makers you work with are taking the market neutral positions, and if they're selling short, for example, they're buying spot on the other end. What kind of studies have you done, or research, or analysis on the differences between margin versus perpetual, with respect to the spot market and how they influence each other?
Brendan (dYdX): I think your theory is probably correct. I can maybe let David take the rest of this one, but I would say from my end, it's an open question, right? I don't know that we have any super solid ideas on macro trends like that. Personally, I might subscribe to some of the ideas around if the market is over leveraged then price crashes are going to be larger and stuff like that for the market in general. But yeah, I don't know that I have too much helpful information to share there. I'll let David take it away.
David (dYdX): It's a great question, and there's a little research on this. My view is that if you look at the history of crypto exchanges through the Mt. Gox era, you saw the rise of spot on centralized exchanges. Then you really saw the rise of leverage and margin trading on centralized exchanges with the rise of BitMEX and Bitfinex. In the last two years you then saw the rise of spot trading on decentralized exchanges largely led by AMMs like Uniswap. And then our thesis is that decentralized derivative exchanges are really going to take off.
Ultimately, if you look at both crypto markets and non-crypto markets, volumes on derivatives markets are orders of magnitude much larger than spot markets. And so that's already very much played out in the centralized crypto world. I looked at the data earlier this week. There was 300 billion plus in daily volumes on derivatives on centralized exchanges, and that's just multiple times what it is in spot.
A lot of price discovery actually happens in the derivative markets. And often it happens before the spot markets because that's where a lot of retail flow and institutional flow go to trade. So I think some people look at the derivative markets and how price in derivatives impacts spot. I think the other thing to be aware of is the amount of leverage that's used in the derivatives world. Large price spikes or large crashes often results in traders getting liquidated or traders having to cover their shorts.
And so I think looking at the amount of leverage in the derivatives space often is a leading indicator of how the market moves later in spot. And then I think to address your question around market makers, a lot of our more sophisticated retail users and then certainly a lot of our market makers look at derivatives as a way to get a market neutral position on crypto. So one popular trade is to go long in the spot markets and then go short in futures or perpetuals. Whether their price of the underlying goes up or down, that doesn't impact your overall position.
And ultimately then you're harvesting the funding rate, which depending on the market ranges anywhere from 40 to 80 percent annualized, which can be considered risk-free if you know how to manage your collateral appropriately. So that's where we see a lot of larger players take the other side of the popular bet and get paid to do that. And so traders look at funding rates around different exchanges and how that dynamically changes with market movements. A lot of people look at that as also a leading indicator of price movement in the spot markets.
User: So you mentioned derivatives exchanges and I was watching all of the analysis done by Dune analytics which showed about 3.5% of the ETH wallets actually interacted with some sort of DeFi protocols. So we have a small amount of individuals actually taking part in this process where they use their MetaMask to interact with a protocol, as such. So right now, I'm seeing dYdX numbers are quite good in terms of how they're doing, getting new users to try out the platform itself, but you've got other competitors, I'll use the word competitors because I don't want to name specific projects, but they're launching their own exchanges. So how is dYdX looking to adapt or are they going to focus on their own thing and see how it goes? What's the forward plan?
Brendan (dYdX): I can talk about it more broadly, but is there anything in particular that I can help answer or I can talk about?
User: Basically capturing users. So as new derivatives exchanges launch, the users will have more of a choice, right? So you need to be able to retain the new customers that sign up to dYdX. So has any consideration been placed on the competitors launching their platforms and how to retain users? Because it's a fixed amount of users currently. Hopefully they'll grow over time, but in the current timeframe payment is limited. So how is dYdX going to stay ahead of its competition, essentially?
Brendan (dYdX): It's a good question. I don't know that it's super specific to crypto markets in general. I think you're right. In some way you're competing against other exchanges for a fixed pool of users. But in a lot of ways, Defi and crypto in general is always increasing its number of users, especially during these bull round moments and years. But I would probably just give the same answer that I would for any other company that's trying to get users, retain users, find product market fit, which is just to basically, one, is find a niche and, two, is out-execute the competition.
I know it's a little bit of like a cop out answer and it's a little bit of not saying much, but I think just having a really high quality, reliable product, and then also offer features that we haven't seen before. So we have the opportunity to be one, I guess, like a non-custodial exchange, and the best non-custodial exchange in the world. And then also work towards that decentralization piece, which I think will be an even bigger paradigm shift there. But at the same time, the reason that people use dYdX is because it's a good exchange.
We just have to have the quality of exchanges people have come to expect. And I think for the past few years, we've kind of been, "Oh, you guys are really good for like a Defi exchange," whereas Defi has been in the pocket of being, okay, it's decentralized but it's second rate to how people interact on normal exchanges. And I think the next few years we'll just basically have to ramp up to be as good as the established exchanges, whether that's Binance, Coinbase, FTX, all these larger centralized exchanges.
I think overall, those are the people that we're going to have to start competing with. So as you mentioned, it's definitely a hot space right now, but I don't know that I can say too much more than we have had a better product that's more reliable and people enjoy using more than other products.
User: I definitely agree that it's a really good product, I was more looking in the sense of say, for example, what happened with Uniswap and Sushiswap forking the code. My understanding is dYdX is open source, is that correct?
Brendan (dYdX): So a lot of our stuff is open source and a lot of our stuff is not open source. For example, we just run the matching engine as a service in our backend, and that's not open source. Stuff like the smart contracts and stuff like that are open source. So I think in a lot of ways we do run a lot of services, and I think in some ways that gives us a competitive advantage over something like a Uniswap where you basically create the contracts, make them open source and then release them.
Brendan (dYdX): I think that makes Uniswap in particular a lot easier to copy. Whereas, I think we're running more proprietary backend systems and high throughput systems that mostly aren't just relying on people to read and write to the state of a Layer 1 blockchain. So, I think there's a lot of value add there that we have over doing software in a purely open source way. Those would be my thoughts on Uniswap being forked in particular.
David (dYdX): Just want to thank Brendan and Ohad for answering all of the great questions and hope this was helpful information. We'll recap all that was discussed in a blog post and hopefully run another one of these in a similar format in the future. Any other questions come up, feel free to just write them in our Discord. The team is always available to answer questions there as well. Thanks, everyone
About dYdX
dYdX is the developer of a leading decentralized exchange on a mission to build open, secure, and powerful financial products. dYdX runs on audited smart contracts on Ethereum, which eliminates the need to trust a central exchange while trading. We combine the security and transparency of a decentralized exchange, with the speed and usability of a centralized exchange.