Share Dialog

Share Dialog

<100 subscribers

<100 subscribers

Deep dive into Hackathon: Sphinx and Switch.

Deep dive into Hackathon: Sphinx and Switch.

Record of AMA please click here.

Host：Diamond and Leo

Guest：Remi and Park

Diamond:

Hello everyone，today we have Remi and Park here from Sphinx, which is the first CLOB DEX on StarkNet, and the Autumn Hackathon winners. And before this, their project Switch was the StarkNet House Hackathon winner, too. Today we're very happy to invite them to talk about the wonderful products, and they're going to share with us their special recipe. At first, Remi and Park, could you please have a short introduction of yourself?

Park:

Thank you guys for inviting us. It's great to have so many kind of people from the Chinese community interested in StarkNet. So quickly on my own backgrounds. I'm most recently from a crypto VC background, so I worked at Fabric ventures here in London, and then briefly at Google.

Since around July decided to focus more on the build an operator side, so over the past few months I've been exploring the StarkNet Ecosystem primarily, initially focusing more on the open source software and infra tooling side, type of projects. Then later partnering up with Remy, who I met at ECC in Paris on a couple of projects. So firstly it was starting of recovery service, which is the kind of trustless wallet recovery solution we worked on back in August. And then more recently, the. The on-chain DEX and couple other things. I'm actually also finish off a degree at LBS London. And we do a bunch of things in on-chain governance, including delegating for Maker, AAVE and so on.

Remi:

Hi, my name’s Remi, so I'm currently a web3 founder fellow part of South Park Commons. It's essentially a collective of builders based in SF and New York. I came into the crypto space in 2017 initially just trading and in 2018 I co-founded a blockchain studio basically we help entrepreneurs build wallets, team marketplaces, and social platforms. And in 2019 I also worked in crypto VC, and source deals, conducted research and help perform companies. And then I later joined Microsoft and Google as a software engineer. And last year I was one of the founding member of Parallel Finance which is a DeFi protocols on Polkadot and met Park over the summer, then we've been working together for a few months now.

Diamond:

Cool, let's look at the first work Switch which won the StarkNet House Hackathon. It's a very interesting project, could you tell us more about it? And how did you come up with this?

Park:

This was actually Remi's idea, so I might leave Remy more time to talk about this one. So I just to quickly introduce. Switch for those who don't know, it's a fully trustless wallet recovery solution using storage-proofs. So I guess with crypto, you kind of trade-off centralization with Self-Custondy, so get much better security. But then losing your wallets access, specifically private key, is much more painful because there's no way to recover those lost details. So we try to found the solution, like social recovery that's trying to solve this problem, but even these are not perfect, because not everyone has kind of a set of trusted parties that they can delegate access to. This is kind of an attempt to use novel technology that's native to StarkNet to solve the problem of Self-Custondy, by allowing users to basically recover their wallets after a kind of set condition has passed.

Remi:

Yes，so for this idea, I was originally explained this idea with some friends for a different Hackathon for Ethereum NYC. So basically we realize that it isn't a way to prove that you have been inactive for your EOA account. So EOA is your metamask public address. You can't rebuild any logic on top of it. So we're thinking if you could prove nonce has not increased for a set period of time. Then you can basically assume that you are not active or you're not able to make any new transactions, and therefore you won't this loss. So while we're trying to build this during the Ethereum NYC Hackathon, we realize that could basically prove the nonce if we can get the block Hash. Then from there you can inferred the state routes and then from there infer the different states of that specific EOA account.

But the issue with doing this on the Ethereum is that you can only go back 256 blocks from today backward, like from right now to backward which is roughly like an hour long. And so that was like a hard limitation on the amount of time you can prove inactivity. During ECC, I attended one of the workshops hosted by Snapchat Labs, and they're using this technique storage-proof to prove any states on Ethereum. But directly, you can’t read that state of Ethereum on StarkNet. And so as I look more into it, I realize that this is actually the solution that could help us actually build this previous hybrid project that we couldn't achieve directly on Ethereum. And so decide to give a second shot at this idea for the Summer House Hackathon. And it turns out that was the perfect solution because not only can read states the of Ethereum on StarkNet, given the cheap compute, you could also recurse backward.

So go from today's block all the way back to Genesis. Because you think of the way blockchain is like Linked List Structure. So the current block will contain the block hash of its parent block. So you can just basically keep on recursing backwards by recreating the block header and go back a year or 2 from now. This’s what Switch is for us to prove that your EOA account has not been active for 2 years. So we just compared the nonce from today and 2 years ago, and if that hasn't increased, then we can activate a recovery contract for you to get your funds back. And this whole process is fully trustless and on-chain, which is I think is the novelty part.

Diamond:

Okay. I think Switch and Sphinx also used the storage-proof which makes the blockchain interoperability, more easily. So what's the potential of storage-proof? Could you elaborate for us?

Park:

Storage-proof as the technology allows a couple of things. In the case of Switch what we used it for was kind of reading historical state. So accessing the block history on Ethereum, apart from that, or kind of more generally, it also allows you to prove state in a trustless manner. Basically, the way a blockchain is structure is they use a data structure called Patricia Merkel trees, and is actually a few different trees, kind of like a state tree, transaction tree, and receipt tree. So from these, you can extract information on things like account balances, smart contract storage, even emitted events and so on. Of course, this is not just limited to Ethereum, but also to other chains that use this data structure.

And I guess if you kind of apply these features to use cases, you can think of it as enabling things like trustless bridging. The bridging is something we use the first things for the crossing order book project, where we allow a user on one blockchain to trustlessly bring their funds to a DEX located on another chain, and trade on that DEX. More generally, I think you can also have things like trustless data stream, so calculating historical price feed data, and then calculating, like a volume-weighted average price on that and providing that as a data stream, like a decentralized The Graph alternative. You could do like trustless oracles, like a Chainlink alternative and so on. So I guess this is a pretty essential piece of infrastructure that has a lot of kind of cross-chain type use cases.

Remi:

And to add on that, if you want to build some application that's very expensive to build on the Ethereum, given that StarkNet has very cheap compute, you could also build that application on StarkNet. But what source proof here can help you do? If there any pieces that's required in your application that on the Ethereum, but you actually need to read some states and do the computational intensive part on StarkNet. This is where you can use storage-proof to fill that gap. It's almost like Chainlink alternative but more trustless.

Diamond:

Okay, let's move on to the second project Sphinx. Could you have a brief introduction to it? What's the idea behind it?

Park:

So for this project, we are really looking to tackle one main problem which is this issue of silent liquidity or silent crossing liquidity. When first I dating for the Hackathon, we realize there was an increasing number of AMM projects starting to build on the ecosystem, but no composable order book. Like a Serum on Solana for StarkNet. And so there's an opportunity to aggregate these liquidity and create this hub for trading. Building on top of that, given our previous experience with storage-proof with Switch, we decided to take this idea even further.

If we applied storage-proof to bridge assets cross-chains trustlessly, we can solve the problem of silent liquidity cross-chains. And this would improve on existing DEX like the dYdX, which have off-chain order books and therefore not composable either within StarkNet or cross-chains. So the product we ended up building is the first natively crossing composable order book on StarkNet. Our ultimate vision here is to use storage-proof and SNARK Proofs to trustseley bridge liquidity from any chain, and creating an aggregation layer for deep liquidity.

For those who've seen our demo, the MVP (Minimum Viable Product) we've built, but the Hackathon allows an Ethereum user to remotely trade on StarkNet using just their metamask. So this is demonstrating the cross-chain aspect of the DEX, where you don't even have to leave your ecosystem and wallet to trade on the StarkNet DEX. Let’s going into more detail, the way this works is the Ethereum user deposits their asset to smart contracts, and then signs a cross-chain message to credit the same balance to the DEXs. Then they can start to trade on the DEX by sending another EIP712 signature which is bridged cross-block and then executed by a paymaster. This was the flow we illustrated with MVP. The idea is we'll continue to build this out for different chains as the bridging infrastructure becomes more mature.

Diamond:

Next one is about the composability, how are you going to offer Composability by Sphinx? What’s composability mean to you with all the orderbook DEXs?

Remi:

That's a good question. In order to be composable, the basic requirement is to be on-chain, meaning order book on-chain. The alternative is order book out chain, like dYdX or ZigZag, if the order book is off-chain, then there's no guarantee liquidity, meaning that I don't mass I there's no guarantee way for me to see it on chain and also interact with it.

How to makes it more composable? If I have some ETH,USDC in the formal order book, that liquidity can be taken by anyone in a permissionless miner. For example, an aggregator or AMM integrating with us, if they wanna basically fulfill, like a swap, they could route some the order to our liquidity. Meaning that AMM slippage could potentially be reduced because then you're getting liquidity from two sources instead of one, which could be an improvement in terms of price execution for the end users.

If you want to build a money market and need some liquidation engine. That's not auction base, but I want able to directly on the liquid market. So liquidate some ETH into our buy order book. Another example of composability. But in the future we could also think of, for example, Flash Loans. So even if you provide liquidity order books that money, if it's not being traded could also be lent out a borrowed other people. And for you to generate some more passive income as well.

Diamond:

The last question, you guys have won twice on StarkNet Hackathon, so share any advice for Cairo developers and builders on StarkNet?

Remi:

I think StarkNet has different characteristics compared to the Ethereum. If you wanna build a project for Hackathon, it's more interesting to explore ideas that native to StarkNet. So you can think of some of the unique features like to Computes, storage-proof, abstract account, make multicalls, session keys, SHARP. If you see them as like different building pieces, you can try to mix them up and come up with some novel concepts. Generally I think there a lot of projects who are building existing concepts from other ecosystems, which I think is fair because they do have part market fits, but I think given StarkNet‘s unique characteristics, it's always more interesting to try to come up with something new based on these new features.

Park:

I know that. I totally agree with Remi, like try to leverage some of the unique characteristics. It's the change building on, it's always helpful to focus on user experience, like the perspective of user and solve an actual problem. For example, good tech is kind of cool and useful for Hackathon, but think on top of that, appealing to user experience and especially like, user pain-points is a good way to kind of communicate the usefulness of the project. Just to give couple examples, Switch was like a trustless recovery project. We really tried to focus on that feeling of losing private key, wallet details, get the pain of losing money. I think this is a very vivid emotion for a lot of people in crypto. With Sphinx is similarly, the process of having to bridge your assets cross-chains, that can be a very troublesome or painful feeling. Sometimes you never know if it ever reaches the other side. And with all the bridge hacks we've been hearing in the news, this is clearly a risky process. So that was more of the pain point that we tried to solve first thing, but more general, I think focusing on the user helps can build a project.

Remi： And the last thing I wanted to add is the StarkWare team is very responsive and very helpful. I know for a lot the new builders in this ecosystem, things can be a little bit intimidating at first, but I will say the committee members, Stark-team are all super helpful. So just always reach out, try to ask for help if you're blocked. And and I guess let's grow this ecosystem together.

Record of AMA please click here.

Host：Diamond and Leo

Guest：Remi and Park

Diamond:

Hello everyone，today we have Remi and Park here from Sphinx, which is the first CLOB DEX on StarkNet, and the Autumn Hackathon winners. And before this, their project Switch was the StarkNet House Hackathon winner, too. Today we're very happy to invite them to talk about the wonderful products, and they're going to share with us their special recipe. At first, Remi and Park, could you please have a short introduction of yourself?

Park:

Thank you guys for inviting us. It's great to have so many kind of people from the Chinese community interested in StarkNet. So quickly on my own backgrounds. I'm most recently from a crypto VC background, so I worked at Fabric ventures here in London, and then briefly at Google.

Since around July decided to focus more on the build an operator side, so over the past few months I've been exploring the StarkNet Ecosystem primarily, initially focusing more on the open source software and infra tooling side, type of projects. Then later partnering up with Remy, who I met at ECC in Paris on a couple of projects. So firstly it was starting of recovery service, which is the kind of trustless wallet recovery solution we worked on back in August. And then more recently, the. The on-chain DEX and couple other things. I'm actually also finish off a degree at LBS London. And we do a bunch of things in on-chain governance, including delegating for Maker, AAVE and so on.

Remi:

Hi, my name’s Remi, so I'm currently a web3 founder fellow part of South Park Commons. It's essentially a collective of builders based in SF and New York. I came into the crypto space in 2017 initially just trading and in 2018 I co-founded a blockchain studio basically we help entrepreneurs build wallets, team marketplaces, and social platforms. And in 2019 I also worked in crypto VC, and source deals, conducted research and help perform companies. And then I later joined Microsoft and Google as a software engineer. And last year I was one of the founding member of Parallel Finance which is a DeFi protocols on Polkadot and met Park over the summer, then we've been working together for a few months now.

Diamond:

Cool, let's look at the first work Switch which won the StarkNet House Hackathon. It's a very interesting project, could you tell us more about it? And how did you come up with this?

Park:

This was actually Remi's idea, so I might leave Remy more time to talk about this one. So I just to quickly introduce. Switch for those who don't know, it's a fully trustless wallet recovery solution using storage-proofs. So I guess with crypto, you kind of trade-off centralization with Self-Custondy, so get much better security. But then losing your wallets access, specifically private key, is much more painful because there's no way to recover those lost details. So we try to found the solution, like social recovery that's trying to solve this problem, but even these are not perfect, because not everyone has kind of a set of trusted parties that they can delegate access to. This is kind of an attempt to use novel technology that's native to StarkNet to solve the problem of Self-Custondy, by allowing users to basically recover their wallets after a kind of set condition has passed.

Remi:

Yes，so for this idea, I was originally explained this idea with some friends for a different Hackathon for Ethereum NYC. So basically we realize that it isn't a way to prove that you have been inactive for your EOA account. So EOA is your metamask public address. You can't rebuild any logic on top of it. So we're thinking if you could prove nonce has not increased for a set period of time. Then you can basically assume that you are not active or you're not able to make any new transactions, and therefore you won't this loss. So while we're trying to build this during the Ethereum NYC Hackathon, we realize that could basically prove the nonce if we can get the block Hash. Then from there you can inferred the state routes and then from there infer the different states of that specific EOA account.

But the issue with doing this on the Ethereum is that you can only go back 256 blocks from today backward, like from right now to backward which is roughly like an hour long. And so that was like a hard limitation on the amount of time you can prove inactivity. During ECC, I attended one of the workshops hosted by Snapchat Labs, and they're using this technique storage-proof to prove any states on Ethereum. But directly, you can’t read that state of Ethereum on StarkNet. And so as I look more into it, I realize that this is actually the solution that could help us actually build this previous hybrid project that we couldn't achieve directly on Ethereum. And so decide to give a second shot at this idea for the Summer House Hackathon. And it turns out that was the perfect solution because not only can read states the of Ethereum on StarkNet, given the cheap compute, you could also recurse backward.

So go from today's block all the way back to Genesis. Because you think of the way blockchain is like Linked List Structure. So the current block will contain the block hash of its parent block. So you can just basically keep on recursing backwards by recreating the block header and go back a year or 2 from now. This’s what Switch is for us to prove that your EOA account has not been active for 2 years. So we just compared the nonce from today and 2 years ago, and if that hasn't increased, then we can activate a recovery contract for you to get your funds back. And this whole process is fully trustless and on-chain, which is I think is the novelty part.

Diamond:

Okay. I think Switch and Sphinx also used the storage-proof which makes the blockchain interoperability, more easily. So what's the potential of storage-proof? Could you elaborate for us?

Park:

Storage-proof as the technology allows a couple of things. In the case of Switch what we used it for was kind of reading historical state. So accessing the block history on Ethereum, apart from that, or kind of more generally, it also allows you to prove state in a trustless manner. Basically, the way a blockchain is structure is they use a data structure called Patricia Merkel trees, and is actually a few different trees, kind of like a state tree, transaction tree, and receipt tree. So from these, you can extract information on things like account balances, smart contract storage, even emitted events and so on. Of course, this is not just limited to Ethereum, but also to other chains that use this data structure.

And I guess if you kind of apply these features to use cases, you can think of it as enabling things like trustless bridging. The bridging is something we use the first things for the crossing order book project, where we allow a user on one blockchain to trustlessly bring their funds to a DEX located on another chain, and trade on that DEX. More generally, I think you can also have things like trustless data stream, so calculating historical price feed data, and then calculating, like a volume-weighted average price on that and providing that as a data stream, like a decentralized The Graph alternative. You could do like trustless oracles, like a Chainlink alternative and so on. So I guess this is a pretty essential piece of infrastructure that has a lot of kind of cross-chain type use cases.

Remi:

And to add on that, if you want to build some application that's very expensive to build on the Ethereum, given that StarkNet has very cheap compute, you could also build that application on StarkNet. But what source proof here can help you do? If there any pieces that's required in your application that on the Ethereum, but you actually need to read some states and do the computational intensive part on StarkNet. This is where you can use storage-proof to fill that gap. It's almost like Chainlink alternative but more trustless.

Diamond:

Okay, let's move on to the second project Sphinx. Could you have a brief introduction to it? What's the idea behind it?

Park:

So for this project, we are really looking to tackle one main problem which is this issue of silent liquidity or silent crossing liquidity. When first I dating for the Hackathon, we realize there was an increasing number of AMM projects starting to build on the ecosystem, but no composable order book. Like a Serum on Solana for StarkNet. And so there's an opportunity to aggregate these liquidity and create this hub for trading. Building on top of that, given our previous experience with storage-proof with Switch, we decided to take this idea even further.

If we applied storage-proof to bridge assets cross-chains trustlessly, we can solve the problem of silent liquidity cross-chains. And this would improve on existing DEX like the dYdX, which have off-chain order books and therefore not composable either within StarkNet or cross-chains. So the product we ended up building is the first natively crossing composable order book on StarkNet. Our ultimate vision here is to use storage-proof and SNARK Proofs to trustseley bridge liquidity from any chain, and creating an aggregation layer for deep liquidity.

For those who've seen our demo, the MVP (Minimum Viable Product) we've built, but the Hackathon allows an Ethereum user to remotely trade on StarkNet using just their metamask. So this is demonstrating the cross-chain aspect of the DEX, where you don't even have to leave your ecosystem and wallet to trade on the StarkNet DEX. Let’s going into more detail, the way this works is the Ethereum user deposits their asset to smart contracts, and then signs a cross-chain message to credit the same balance to the DEXs. Then they can start to trade on the DEX by sending another EIP712 signature which is bridged cross-block and then executed by a paymaster. This was the flow we illustrated with MVP. The idea is we'll continue to build this out for different chains as the bridging infrastructure becomes more mature.

Diamond:

Next one is about the composability, how are you going to offer Composability by Sphinx? What’s composability mean to you with all the orderbook DEXs?

Remi:

That's a good question. In order to be composable, the basic requirement is to be on-chain, meaning order book on-chain. The alternative is order book out chain, like dYdX or ZigZag, if the order book is off-chain, then there's no guarantee liquidity, meaning that I don't mass I there's no guarantee way for me to see it on chain and also interact with it.

How to makes it more composable? If I have some ETH,USDC in the formal order book, that liquidity can be taken by anyone in a permissionless miner. For example, an aggregator or AMM integrating with us, if they wanna basically fulfill, like a swap, they could route some the order to our liquidity. Meaning that AMM slippage could potentially be reduced because then you're getting liquidity from two sources instead of one, which could be an improvement in terms of price execution for the end users.

If you want to build a money market and need some liquidation engine. That's not auction base, but I want able to directly on the liquid market. So liquidate some ETH into our buy order book. Another example of composability. But in the future we could also think of, for example, Flash Loans. So even if you provide liquidity order books that money, if it's not being traded could also be lent out a borrowed other people. And for you to generate some more passive income as well.

Diamond:

The last question, you guys have won twice on StarkNet Hackathon, so share any advice for Cairo developers and builders on StarkNet?

Remi:

I think StarkNet has different characteristics compared to the Ethereum. If you wanna build a project for Hackathon, it's more interesting to explore ideas that native to StarkNet. So you can think of some of the unique features like to Computes, storage-proof, abstract account, make multicalls, session keys, SHARP. If you see them as like different building pieces, you can try to mix them up and come up with some novel concepts. Generally I think there a lot of projects who are building existing concepts from other ecosystems, which I think is fair because they do have part market fits, but I think given StarkNet‘s unique characteristics, it's always more interesting to try to come up with something new based on these new features.

Park:

I know that. I totally agree with Remi, like try to leverage some of the unique characteristics. It's the change building on, it's always helpful to focus on user experience, like the perspective of user and solve an actual problem. For example, good tech is kind of cool and useful for Hackathon, but think on top of that, appealing to user experience and especially like, user pain-points is a good way to kind of communicate the usefulness of the project. Just to give couple examples, Switch was like a trustless recovery project. We really tried to focus on that feeling of losing private key, wallet details, get the pain of losing money. I think this is a very vivid emotion for a lot of people in crypto. With Sphinx is similarly, the process of having to bridge your assets cross-chains, that can be a very troublesome or painful feeling. Sometimes you never know if it ever reaches the other side. And with all the bridge hacks we've been hearing in the news, this is clearly a risky process. So that was more of the pain point that we tried to solve first thing, but more general, I think focusing on the user helps can build a project.

Remi： And the last thing I wanted to add is the StarkWare team is very responsive and very helpful. I know for a lot the new builders in this ecosystem, things can be a little bit intimidating at first, but I will say the committee members, Stark-team are all super helpful. So just always reach out, try to ask for help if you're blocked. And and I guess let's grow this ecosystem together.