 I'm Oran, I'm from Starquare. Our mission at Starquare is to use proof systems to bring scalability and privacy to blockchains. We are a team of slightly over 30 based in Israel. We've raised slightly over $40 million to equity rounds plus a generous grant from the Ethereum Foundation. And the first product we're focusing on right now is a Starquare-based scalability engine for exchanges. And what I'm going to talk about today is how Starquare could help solve the blockchain scalability problem. And then I'm going to describe the Starquare-based exchange engine that we've developed. So in January 2018, in the middle of the US government shutdown, President Trump took his first state of the union address. And for some reason, he neglected to mention two of the most important things that happened right about then, which is that the Starquare paper was being published. And Starquare, the company, was incorporated. We started working. At last DevCon, we demonstrated for the first time working implementation of a Stark Prover and Verifier running in a browser on a smartphone using Web Assembly. This was the first time this was demonstrated. Up until then, Stark was widely regarded as a very promising technology, but one that would take years until any practical implementations come out. In January this year, we demonstrated a first demo of a Stark exchange Stark, which for the first time had a Verifier running as an Ethereum smart contract. At that time, the scale of the system was 10x that of Ethereum. The throughput of the system could support is 10x that of Ethereum. We're constantly working on improving that. And two months later, that jumped from 10x to 200x. In June, we ran in collaboration with 0x on Robson on the Testnet, the Alpha version, an Alpha version of Stark exchange, Stark Powered Exchange, which ran a few weeks of actual live traffic from Binance. Only last month, we hosted in Tel Aviv the Stark Work Sessions Conference, which also included a Stark 101 open workshop for developers where participants could build a Stark Prover from scratch. And we're constantly working on improving the system scale, as I said before. The best running implementation we have today is 700x, the throughput of Ethereum, which brings us to over 2,000 trades per second that we could run, which means that the average cost in terms of gas per trade is under 200 gas. Now, this is always going down, and specifically with the AP2028 coming in Istanbul, which we're very proud to have shepherded through. It's going to go significantly lower than that. And our next milestone, and this is in large part what I'm going to talk about today, is to deploy on Mainnet to launch first commercial release of a Stark Powered Exchange come January with a partner. But first, what's Stark? So Stark is a zero-knowledge proof protocol with specifically nice characteristics. The main ones are that both verify running time and the proof size itself are only logarithmic with regards to the original computation. The prover running time is nearly linear and with nice constants, actually against any other protocol that we've compared it against to date, it's at least one order of magnitude faster. Stark is also applicable to any general computation. So generally anything you could code, Stark could also prove. And then there are two cherries on top of that. One is that Stark requires no trusted setup. And the other is that Stark has hardly any cryptographic assumptions. So the only thing you need to work for Stark to work well is the existence of cryptographic hash functions, which makes it very future-proof in two aspects. One is that it rests on the same lean and battle-hardened crypto as pretty much the rest of e-commerce that's been around since the 70s really. And two, it also makes it plausibly post-quantum secure. So how can proof systems in Stark's in particularly help with scaling blockchains? So permissionless blockchains are often referred to as a distributed system. But actually if you look at them more closely, you can see they're actually more of a duplicated system. You have a large number of nodes, but each and every one of these nodes actually performs all the computations and stores the full state of the entire network. So this boils down to a very low glass ceiling in terms of the amount of operations the network could actually carry. For instance, in the case of trades that we're handling right now, typical on-chain trade today cost something between 150,000 and 200,000 gas, which means the network can't do more than three or four trades per second, the theory. But what if we shift this balance? And for a given computation, we'll have one party run the heavy computation. And on top of running the computation itself, we'll also do some extra work and produce a proof, a Stark proof, a testing to the validity of those computation. Now what the rest of the parties need to do is just to verify that proof, which like I said before is a whole lot less work than the original computation itself. Note that with proof systems, there is no trust assumption with regards to the prover, as the verifier never accepts invalid proofs. So you only need to trust the verifier, and it would never accept any false claims. So this is not a fraud proof mechanism where false claims may be accepted and hopefully later overturned. In this case, only valid statements, only valid states will be updated on-chain. So in the blockchain case, instead of running all these heavy operations many times on-chain, you could basically take the heavy lifting computation-wise off-chain. It'll still be heavy, but it'll be done at AWS cost rather than at blockchain costs. And all that's left to do on-chain is just the verification. This requires very little resources. Now Stark is especially a good fit for this because of these nice attributes that I mentioned before. This way, you could actually increase the network throughput by several orders of magnitude while still enjoying the security of the main chain. But you may say, well, this is nice, but this is good for big computations. And there aren't any big computations on Ethereum today. And you'd be right. Actually, the network scale limitations actually prevent big computations from being run on it today. So to this, I say two things. One is that using a Stark-based system, you can have big computations. So if you're a developer who's not developing some DApp today because you're concerned the network won't be able to carry it, then you're highly welcome to come and talk to us. And the second thing is that for simpler computations, such as trades, for instance, what we could do is we could batch a large number of small operations together in a big batch and prepare one proof attesting to the validity of the entire batch and get the same scale effect that way. Because again, it's the same logarithmic quality of the verifier. So verifying a proof for a very large batch hardly costs more than verifying one for a smaller batch. So up until now, I describe how proof systems in Stark could help scale blockchains in general. Now I turn to the engine that we've built on top of this, which is a scalability engine for exchanges. And I'll briefly explain how that works. So these are the main players in this drama. At the top left, you have Alice and Bob. They're stars in pretty much any presentation here. They're moving from room to room. So they're the users. You have the exchange itself. Then you have the Stark scalability engine that includes the prover. All this is off-chain. And then on-chain, you have two main contracts. One is the Stark verifier. And the other is the Stark exchange main contract that keeps the system state. So users trade on the exchange pretty much as they would today on any centralized exchange. The main difference is that they need to sign each in every order with their own private key. Now this is an important feature, because this is basically the core of this system being non-custodial, which means that neither the exchange nor the Stark exchange engine can actually move people's funds around without their signatures. So if the exchange is hacked, nobody could actually touch the funds of all the people that are there. The exchange also pretty much the same as today does the matching. And then it sends the Stark exchange engine all the trades to be settled later on-chain. So the users on the exchange are pretty much as any exchange today. The users don't need to wait for anything coming later. They could continue trading immediately. What the Stark exchange does, first it batches a large number of transactions of trades, like I said before. And then for each of these trades, it inserts within the proof that the trade itself was valid. So we'd need to prove things like the orders were signed correctly. And the users had enough tokens to transact. And the transaction balances each other out, things like that for every trade. Once the proof is ready, it's sent on-chain. And then the on-chain verifier accepts that proof if and only if it's valid. And once accepted, it also updates the Stark exchange main contract and updates the state. Now, this would be a good time to explain how we don't just take most of the computation work off-chain, but actually also most of the storage. So instead of keeping the up-to-date balances of all the users on-chain, which costs a lot, we take that off-chain. We store that as part of the Stark exchange engine. We organize that as a Merkle tree. And only the root of that Merkle tree is updated on-chain. So this means that within the proof, in addition to attesting to the validity of each individual trade, we also attest to the validity of the change in states. So the state before the batch, the state after the batch, correctly depict the actual changes that are part of the batch. One of the nice things about a Stark power exchange is that users can now trade on the exchange from their own private wallets. So the way this works is when the user, let's say Alice, wants to trade on the exchange, she first deposits funds to the exchange. This is a regular theorem transaction to deposit it to the exchange contract. And then it's picked up and ridden on-chain as well under her private key. So this is pretty quick, hence the rabbit in the picture. And then while on the exchange, everything is very fast. It's, again, the same as any centralized exchange today. Hence we have three rabbits here. But here we have a small issue. What if Alice needs this money on-chain now? For instance, to pay Carol for something. So paying Carol is also a regular theorem transaction, which is pretty fast. But to get her funds off the exchange, she'd need to withdraw. And to withdraw is a slightly longer process, because she'd have to wait until the proof is actually accepted on-chain. Hence the turtle. So what we need here is a fast turtle. So luckily we've found one. By the way, turtles actually walk very, very slowly, but they swim quite fast, almost as fast as Usain Bolt runs. So the equivalent of the turtle is this neat mechanism that we've devised that we call conditional transaction. So a conditional transaction is something that happens off-chain, only if something else occurred previously on-chain. And I'll give an example with this case of a fast withdrawal. So Alice wants her money fast on Ethereum. So the first thing she does is she signs a conditional transaction, transferring money from her off-chain account to the exchange's off-chain account, pending the exchange did a similar transfer on-chain earlier. So she signs that and provides that to the exchange operator. The operator first checks that she has enough funds off-chain to do this. And if she does, it just moves the money on-chain to her account. So Alice now got the money within one Ethereum block. Now the exchange could actually submit this off-chain operation to the proof. And since the on-chain operation it relies on has already happened, this will now be accepted. So the transaction will be executed, and now the exchange will get the same funds off-chain. So Alice could use this mechanism to get a quick withdrawal. Another thing she could do is she could actually ask the exchange to transfer the money on-chain directly to Carol. And then the conditional transaction will rely on that on-chain transaction. So what happened here is that Alice actually paid Carol on-chain directly from her off-chain account. This could actually work with anything, not necessarily just paying Carol, but anything you could actually do on-chain, on-layer one, or that could be attested to on Ethereum. So it could even be things like paying Dave on the Bitcoin network. Since a Bitcoin transaction is something that could be attested on Ethereum, or it could be open to CDP on Maker, or any other DeFi application that relies on layer one, Alice could actually directly access that directly from her off-chain account at the exchange. OK, so far I was talking with my engineer hat on, but now let's all put our business hats on and take a look at crypto trading today from the perspectives of both the exchange and of traders. And I want to briefly touch what a stark powered exchange can provide them with. So today, when people trade, they pretty much trade on centralized exchanges. A centralized exchange being fully custodial is basically just one big honey pot of tokens, which is highly risky. Now what a trader could do with this risk is one thing they could do is they could just accept it as part of the cost of doing business and take the risk. Note, this is not just a theoretical risk. It's estimated that last year somewhere between one and one half billion dollars worth of token were hacked off exchanges. Another option for traders is to limit their exposure to any one specific exchange and split their funds between several different ones. This is not necessarily capital efficient and it basically boils down to both trader and exchanges leaving money on the table. But with a stark powered exchange, you have other options in terms of custody. You could do self custody like I explained before. You could have your custodian trade for you on the exchange. You could have even more complex schemes in terms of custody. All these boiled down to this honey pot being eliminated and the risk being greatly lowered. Another benefit of a stark powered exchange is that it's much easier in this scenario to move funds to an exchange, off an exchange and between exchanges. So this will also greatly help traders from a capital perspective. So today if you trade crypto, you have the option you could choose between risking your money at a centralized exchange or enjoying low liquidity in a poor user experience at a decentralized one. With a stark powered exchange we essentially break this trade off and you can enjoy the scale, the liquidity and user experience of a centralized exchange without taking this honey pot counterparty risk. Now note that what we've been building these last few months is a production grade system. It's not just a stark stack. It's a heavy duty system that could actually handle a large scale in production and could be integrated to any exchange. So we already already saw that in addition to this, using these neat mechanisms such as conditional transaction and some others that I haven't described here, users can also seamlessly move between their off-chain account at the exchange and all the wealth of the DeFi application that's currently exist on Ethereum. They could use them direct. We also talked about how in addition to trading, the system also supports payments to Ethereum or even to other blockchains. But it doesn't stop here. Stark is a generally applicable protocol, like I said before. So pretty much anything, any financial feature the exchange would want to offer, we could also include in a stark proof. So we can, for instance, include things like interest bearing accounts and margin trading and do that at scale while still remaining trustless. But this is not the end of it. On top of this, you could also add front-running protection. I won't have time to go into that right now but you can come and talk to us later. And notice that up until now, we haven't even used yet the zero knowledge quality of Stark. Add that to the MISC, mix and things start getting really interesting because you could start having privacy. Now today as far as privacy goes, you have the exchange operator basically telling you, trust me, I'm not gonna use this to your disadvantage. Now with a Stark based system, you could actually have real privacy, including privacy from the operator himself. So from this perspective, Stark could do to privacy the same thing that it did to custody before. Now you don't need to trust the operator because they're good, because they're a good guy, but you can trust them not to cheat because they can't. Even more importantly, you could have regulated privacy. So you could have privacy, including from the operator while still ensuring that all regulatory requirements are being met. So things like truly dark pools suddenly become possible. Note that with these features, that actually makes a Stark powered exchange, not just the best crypto exchange. It actually has features that don't currently exist on any traditional exchange as well. So with this, an exchange powered by Stark will not just be the best crypto exchange out there, but actually the best exchange out there. Crypto or non-crypto. So one more thing, we are very happy to announce our first commercial partnership. We have partnered with Diversify to bring a Stark powered exchange to real users on production come January. And I'm very glad to invite Dan Yanov, the CEO of Diversify to talk about our cooperation. Thank you, Orin, for the fantastic introduction. Here at Diversify, we believe that users should always have control of their funds. Accessing applications through the safety of their choice of wallets. Now, when it comes to trading, so far this has come at the cost of a great trade-off. As Orin mentioned, the trade-off with speed, liquidity, user experience, and even gas costs. Now, over the last 12 months, we have worked hard to bring our users to great user interface, getting feedback from our lovely users. We have developed a way to match against the external liquidity pools to bring traders fantastic markets. And now, with the help of our friends from Starkware, we have the last piece of the puzzle. Instant settlement, low fees, and high scalability. So the days of trade-offs when it comes to non-custodial trading will soon be over. Now, I'm going to do a quick demo to show you what this looks like practically. This is a pre-recorded demo. Those of you who have tried using the internet will probably understand why. So here we have the Diversify trading interface. On the right-hand side, we can see our balances. So here we have our on-chain balances and our off-chain balances locked in Stark in green. So we have just under 1,000 bucks ready here. We're gonna do a trade to show you what that looks like. So the green is basically what we have available to trade. Now, so we're gonna be placing a trade. Let's have a look at the order book. Now, you can see this order book is incredibly thick. So we can place a trade of over 100 ETH without moving the price at all. And the reason why we're able to do this is because since the user's funds are locked in Stark, we can guarantee settlement, i.e. everyone has to hold up their end of the deal, so we can match against an external liquidity pool. In this case, a centralized exchange which allows us to bring this to our traders. Now let's go ahead and actually place a trade. We're gonna be buying some ETH, which this is from a few days ago, so this person is happy that they did this probably. And so we're gonna do a simple order just to execute quickly at market price. And we're going to select the amount and we're going to buy. Now, we're going to sign this with our signature, and it's already executed actually, we missed it. So it's been executed. We can see it in our history instantly. And more importantly, it has been also settled instantly. So again, if we look at our balances, we have our new balance available to trade. So as we mentioned earlier, the trade-offs in experience when it comes to non-custodial trading will soon be over. Now, this has been a demo. However, this will be live the beginning of next year. So please stay tuned and give it up for Starquare. I think we have some... Yeah, that's it. I think we do have time for questions if anybody wants to ask. Yeah. Oh, sorry. Yeah, just step up to the microphones if you want to ask. Yeah, great talk. I'm curious, what do you see as the advantages of Ethereum for Starquare to build on? What got you all to build on this and what do you see as potential downsides to Ethereum that make you want to move this technology elsewhere if either they're present today or if they became present? So Starquare is not specific to Ethereum. It's a general technology, it's not even specific to blockchain. The reason we chose to focus on Ethereum is because it has a few things we need. One is it has a rich enough language for us to be able to build a verifier that can run on chain. For instance, Bitcoin doesn't, but other chains do have it. And also it has a very big developer community. So there are a lot of applications being developed. There's a lot of, there are exchanges running on top of Ethereum, there's a bigger ecosystem. But like looking forward, we're not gonna stop specifically at Ethereum. We could build similar things and other chains as long as they have a rich enough language. Cool, thanks. Can you tell us about the data availability problem for the miracle tree that holds the state of the exchange? So at this first phase, the way we're gonna handle data availability is that we're gonna have basically a committee of a few trusted parties that's gonna accept all the data. And for each proof that we submit on chain, the proof will only be accepted not just if it's not valid, but also it needs to be signed by enough committee members that have indeed attested to the fact that they have the data and that they have indeed calculated and saw that this data maps to what we've submitted as part of the proof. Thanks for the talk. Did I get it right that the match agent is centralized and it just can say I don't want to execute this order? That is true. At this phase, we're just, we're starkifying the settlement process. The matching is centralized. Now this has ups and downs. The main benefit that you have here is that it's a lot quicker and you can't front run it. The downside is yes, it's still censorable. Do you have any kind of solutions for it or? So we have thoughts about how we could start to fight the matching as well, but we're not there yet. Got it, thank you. That will be coming sometimes late. Thank you for talk. It sounded very bright and shiny, like kind of without disadvantages, solving a lot of problems. And even for me, it sounded like it's going even into layer two territory by problems it solves. So there should be some drawbacks. First of all, it is the layer two solution, you're right. The reason it's like it's a lot simpler than many of the other layer two solutions. Like in layer two, you have, I referred to you briefly before, you have two major concepts. You actually use fraud proofs or validity proofs. So fraud proofs is where you say, okay, let's say we have some channels or something in layer two. We update that on chain and we're optimistic about it. So we may update things that are false, but we expect somebody to catch that and contest that and then overturn it. That's a much more complex system of what we're doing here and it has a lot more drawbacks. What we have here is since we have the power of Stark or proof systems basically, this means that whenever we submit a proof, only valid proofs will actually be accepted and only valid states will be updated on chain. So it makes things actually a lot simpler because there are a lot less cases to consider. It's not a simple system altogether, that's why we were working hard on it for the last few months and slightly more than that. And we believe that the user experience at the end of the day is pretty seamless. Won't feel that you're running on top of something complex. Then one more quick question. Do you need some kind of set of validators or some separate network that will be doing some things or it just works completely on normal smart contracts in Ethereum? So on chain, it's just a regular smart contract. There's a verifier contract. There's a main contract of the exchange all on chain. Off chain, we have this Stark engine that we're operating that runs as part of the diversify in this case. And the only thing you have on top of that is this committee that I mentioned before that you're gonna have several other parties that are not us that will actually need to get the data and the test to the fact that they've seen it and it's valid. Thank you. That's all. So how do you compare yourself with IDEX? With IDEX? Yeah. Well IDEX today, as far as I know, don't yet have any such scalability solutions. So they actually do the settlement on chain. I think they're planning to. Well, it did announce a layer two solution yesterday. Okay, I'm not too familiar with the solution. As far as I know, it's not proof system based, which means it's like in this category I just referred to that's called fraud proofs, which means you could actually update false things on chain and hopefully later overturn them, which makes it a bit more prone to attack and complex, but I'm not too knowledgeable about exactly what they do. What does StarDex require KYC? And also, would you open like margin trading in the future or it's on the roadmap? So KYC is really a question to you. It's not a matter of StarDex, it's. Yeah, so yeah, KYC I guess depends on the exchange itself. And in our case, we don't require KYC because all the assets traded on diversify are basically crypto to cryptos, it's only digital assets. And we don't include securities and certain jurisdictions are excluded to be able to create this kind of friction, this connection, the exchange. And now margin trading from the stock perspective, we're definitely planning to handle that, which means that the stock engine will be able to support it. Again, it's a matter of, it's up to the exchange of when and how exactly they support any future. I know if you have a statement on that. Yeah. So thank you very much.