Episode 126 of the Public Key podcast is here! Many in the world of DeFi have heard about Chainlink and Pyth Network, but there is a new protocol that has enshrined oracle directly into it’s EVM Layer 1 Blockchain. We speak with co-founder and CEO of Flare network, Hugo Philion who explains everything we need to know about the decentralized oracle ecosystem and how their solution is offering cost effective and secure oracle options.
You can listen or subscribe now on Spotify, Apple, or Audible. Keep reading for a full preview of episode 126.
Public Key Episode 126: Why Your Oracle Data Isn’t Secure and How Flare is Changing the Game
Many in the world of Defi have heard about Chainlink and Pyth Network, but there is a new protocol that has enshrined oracle directly into it’s EVM Layer 1 Blockchain.
In this episode Ian Andrews (CMO, Chainalysis) speaks with Co-founder and CEO of Flare network, Hugo Philion.
Hugo shares his transition from hedge fund trading to blockchain and emphasizes the increasing need for decentralized data in an industry that heavily relies on information from data providers.
He breaks down Flare’s architecture, offering cost-effective and secure data oracles, while being sure to differentiate their solution from existing systems that are vulnerable due to lack of decentralization and potential for collusion.
Hugo even explains how KYC and AML can be integrated by the developers building on Flare and how important regulation is to move the industry forward.
Quote of the episode
“Flare’s protocols are solving for cost, security, and flexibility by enshrining the oracles into the chain as in integrating both the infrastructure and the security budget that is staking into one role and having a single token.” – Hugo Philion (Co-Founder & CEO, Flare Network)
Minute-by-minute episode breakdown
2 | Hugo’s journey from hedge funds, skipping AI and ML to get into crypto
5 | Why Flare decided to build a L1 platform with enshrined oracles
8 | Examining why data in the crypto landscape is fundamentally broken
12 | What are enshrined oracles and why are they important?
17 | Introducing LayerZero and the solution to cross-chain interoperability issues
20 | Flare use cases with decentralized exchanges and DeFi projects
24 | Exploring huge oracle failures and lack of data providers in the industry
29 | The emergence of regulation, KYC and AML in a decentralized crypto ecosystem
32 | Flare announced new Flare Data Connector solution
Related resources
Check out more resources provided by Chainalysis that perfectly complement this episode of the Public Key.
- Website: Flare: The blockchain for data, providing developers with secure decentralized access to high-integrity data from other chains and the internet
- Blog: Use cases enabled by LayerZero’s integration of Flare
- Solution: The Flare Time Series Oracle (FTSO)
- YouTube: Chainalysis YouTube page
- Twitter: Chainalysis Twitter: Building trust in blockchain
- TikTok: Building trust in #blockchains among people, businesses, and governments
- Telegram:Chainalysis on Telegram
Speakers on today’s episode
- Ian Andrews * Host * (Chief Marketing Officer, Chainalysis)
- Hugo Philion (Co-Founder & CEO, Flare Network)
Mentioned Episodes:
Ep. 79: Web3 Adoption in Traditional Finance
Bringing real world assets on to the blockchain will need safe, reliable and accurate data points. In this episode Kemal El Moujahid (Chief Product Officer) at Chainlink, shows us how we can connect web2 and web3 applications in a seamless and secure way.
Ep. 121: Explore IPFS, Filecoin and Crypto Policy Developments
With the evolution of AI and the questioning of authenticity during the time of presidential elections, it is getting increasingly more important that data and files are unable to be corrupted and not controlled by a centralized party. In this episode, renowned cryptocurrency and civil liberties attorney, Marta Belcher (President & Chair, Filecoin Foundation) shares insights into decentralized storage, crypto policy and privacy in the digital asset age.
This website may contain links to third-party sites that are not under the control of Chainalysis, Inc. or its affiliates (collectively “Chainalysis”). Access to such information does not imply association with, endorsement of, approval of, or recommendation by Chainalysis of the site or its operators, and Chainalysis is not responsible for the products, services, or other content hosted therein.
Our podcasts are for informational purposes only, and are not intended to provide legal, tax, financial, or investment advice. Listeners should consult their own advisors before making these types of decisions. Chainalysis has no responsibility or liability for any decision made or any other acts or omissions in connection with your use of this material.
Chainalysis does not guarantee or warrant the accuracy, completeness, timeliness, suitability or validity of the information in any particular podcast and will not be responsible for any claim attributable to errors, omissions, or other inaccuracies of any part of such material.
Unless stated otherwise, reference to any specific product or entity does not constitute an endorsement or recommendation by Chainalysis. The views expressed by guests are their own and their appearance on the program does not imply an endorsement of them or any entity they represent. Views and opinions expressed by Chainalysis employees are those of the employees and do not necessarily reflect the views of the company.
Transcript
Ian:
Hi, everyone. Welcome to another episode of Public Key. This is your host, Ian Andrews. Today, I’m joined by Hugo Philion who is co-founder at Flare and CEO of Flare Labs. Hugo, welcome to the show.
Hugo:
Hey, Ian. Thanks for having me.
Ian:
Hugo, I’m fascinated to learn about Flare Labs. It’s a big project. Maybe since I’m guessing many of our listeners haven’t heard of that before, we can start with just a brief overview of what you’re building at Flare.
Hugo:
Absolutely. We are building what we think of as the best platform for data in the space. Flare, as a network, is an EVM layer one and it’s the first network to have enshrined oracles integrated into the network itself. Those are oracles for prices, oracles for Web2 proofs, oracles for Web3 proofs. So this allows developers to build very feature-rich applications which get their data directly from the network in a highly decentralized and heavily secured way.
Ian:
It sounds really exciting. I want to dive in. I have so many questions about the technical details, but before we jump to that, tell us a little bit about your background. How did you find yourself in this world of blockchain and cryptocurrency?
Hugo:
I was a trader at a number of about two hedge funds. I was a trader of derivatives, primarily commodity derivatives. And I got to the point in my career with 2015, 2016, where I decided I really didn’t want to continue in that career. I felt frustrated. I felt bored. I didn’t like having to chase returns. It can be quite soul-destroying, especially when you don’t feel like you’re really building anything. I also didn’t want to turn into mostly other people in my office, a sort of middle-aged alcoholic on their third wife. So I thought I’d leave and I did and I went back to university to study machine learning and that’s where I met my two co-founders.
Ian:
How did you go from machine learning into the world of blockchain and crypto? That doesn’t seem like necessarily a natural evolution, but I don’t think anyone finds theirselves in this industry on a straight line path.
Hugo:
I was interested in statistics. I suppose my undergrad was primarily risk management and financial engineering, so I had a strong background in statistics, simulation modeling, that kind of stuff, very close to machine learning as a thing to go study machine learning was a very interesting and highly related aspect to, I suppose, my undergrad and a lot of the work I was doing whilst I was at a number of funds.
I didn’t really want to go into machine learning AI after studying, because arguably at that time, and still to this day, AI and ML is really the preserve of very large tech organizations. Whilst crypto focuses on decentralizing banks and governments as their centralizing forces, really tech companies are also very heavy centralizing forces and not wanting to go back straight out of the frying pan and into the fire. I really didn’t want to go directly to AI.
Secondly, really, at the time then and, again, I would say still to this day, despite the advances and the hype in AI, AI, as it is today, isn’t that useful. I need to be careful what I say, but it’s not that useful, that there are not that many mission-critical things that you would want to use AI for. It’s still fairly early and there’s a number of reasons for this. From siloing of useful data within large and medium-sized companies that can’t and don’t use the data to the complexities of being able to rely on the outputs of singular probabilistic models for mission-critical tasks.
I think the use of blockchain to improve aspects of AI is real and could have a fundamental effect on the usefulness of AI in the future. I certainly couldn’t claim to be thinking about that back then, but I’m very glad I went into blockchain and not directly into AI.
Ian:
I think it’s an astute observation, this idea of… I’ve spent a lot of time thinking about recently is sort of the verifiability of data in a world where the marginal cost to create real seeming data, whether that’s video or audio or textual information, has sort of gone to zero. It starts to make sense to have systems that can verify authenticity and point of creation in a technically provable way. So I’m not sure if that was what you were alluding to or you have a different perspective on it that you’d like to share.
Hugo:
Well, I mean, I think we’ve been doing a lot of work on where blockchain and AI can intersect and we recently put out a paper called Consensus Learning, which is about collaborative AI. You have issues with probabilistic models that really they’re just drawing inferences from probability distributions. And when you want to make a decision, a really, really important decision like, “Does this person have cancer? Is this car about to crash? Do we need to take action,” you want a very high degree of safety. Today’s models don’t necessarily provide that, and so we think that there’s a form of collaborative machine learning or AI that can essentially mitigate the risks inherent in singular models. There’s also a lot of other areas where AI can be used with blockchain, like you say, the verifiability of things. That’s something, I think, we’ll probably come onto in this chat, but I think those are potentially big use cases. But I think I see the biggest use case for blockchain and AI as blockchain being able to make AI fundamentally better.
Ian:
Super interesting. Connect that to what you’re doing at Flare now. I’m always fascinated when I talk to someone that is launching a new chain, because I think the mass of people who interact with blockchains in some way sort of orbit around Bitcoin and Ethereum predominantly, and then a very long tail of layer one and layer two chains. Now we’ve got this kind of ecosystem of app-specific chains like what the folks at Celestia are doing. What led you and your co-founders down the path of saying, “You know what? We need to create a new L1.”
Hugo:
Fundamentally, we think that data in the space is somewhat broken and we wanted to build a platform and we actually spent, I think, two years before we… As an organization, we spent two years, really, before we hit what we wanted to do. Really, from late 2017 to about 2019, we were kind of thinking, researching, not necessarily jumping onto, “Let’s build something today.” We were just really exploring the spaces. We come out of a non-crypto background and we wanted to make sure that we were thinking in the right direction and we fundamentally think that data is poorly served in the industry.
We wanted to build a layer one. Well, we wanted to build a platform where oracle’s data are close to being as secure as the network itself. So we’re building Flare and Flare’s, really, the only major layer one with enshrined oracles and that is the oracle system is built into the network and derives its security in a similar manner to proof-of-stake. This means that a full validator set is needed if you want them staked, and so this rules out things like launching on Solana and rules out being an L2.
Even with these newer shared security models like icon layer, shared security would introduce to our mine’s intolerable risks to the data side that are very, very hard to get over. From our perspective, enshrining the oracles into the network has very, very substantial upsides beyond security.
Ian:
That makes sense. You made a comment a moment ago that data in the crypto landscape is sort of fundamentally broken. Can you be more specific? Maybe a couple examples that we can latch onto.
Hugo:
I mean, I think the biggest issue I have is that there’s billions being spent on infrastructure trying to achieve higher performance, decentralized compute. But if your data isn’t decentralized, there’s very limited reason to use decentralized compute to feed centralized data into decentralized compute. To me, that calculus doesn’t stack up.
Ian:
Okay. So if I think about the constraining factor in most blockchains is block space fairly limited. And so most people are offloading data related to whatever’s actually getting represented on chain. Maybe the easiest example comes to mind is with NFTs, where the actual art associated with most NFTs sits in a file system somewhere off the blockchain and the on-chain representation is just a pointer to a file location, a URI of some sort.
Some of those do use decentralized file storage like IPFS. We recently had someone from the Filecoin Foundation on the podcast, but a lot of it sits in Amazon S3. So am I tracking the point you’re making there that if we’re keeping all our data in something like S3, that we’re not really getting to the decentralization?
Hugo:
I’d go a lot further. I’d say that existing Oracle systems are not giving you decentralization. They’re not giving you safety. NFTs are one aspect, relatively small market cap relative to the amount of value that’s being transacted across protocols that are pulling data from existing oracle systems. To us, it doesn’t really compute that if you’re using essentially centralized data, you really don’t need to pay for block space. You can just do it all in Amazon S3 anyway.
Ian:
Right. Right. Yeah. I mean, I think that would probably be the critic of people that look at a lot of the application architectures that get built on blockchain. It’s like, “Wow, you’ve gone and done a huge amount of engineering work to make a blockchain inside of an app that probably would be fairly straightforward otherwise.” But let’s dive in on specifically, your critique of the status quo is that most of the applications running on blockchains today, so thinking about automated market makers or DEXes, they depend on pricing data, which is usually supplied by an oracle And that system is inherently not decentralized and so therefore less good than we would want it in an idealized system.
Hugo:
Just to pick you up on that, I mean, AMMs thankfully don’t depend on data, at least most of the versions we’re familiar with like USwap, but lending protocols do, perks DEXes do. Anything financial, real world assets that needs to have a price does. Anything to do with being able to do proofs from other chains or from Web2 into the space needs data. To give you an example, a really simple example of where this is falling down… The lowest number of data providers, if you take existing Oracle systems, the lowest number of data providers that is serving a particular price, there is five. It’s an incredibly low threshold for collusion.
Ian:
I think I understand the problem now fully, so let’s talk about the solution with Flare. What does it really mean to have an oracle embedded into the chain? What does that look like? And maybe you can compare and contrast against like an Ethereum architecture that people are probably familiar with.
Hugo:
Yeah. What are we solving for? Flare’s protocols are solving for cost, security, and flexibility by enshrining the oracles into the chain as in integrating both the infrastructure and the security budget that is staking into one role and having a single token.
Flare’s able to offer data at a much lower cost than a third party oracle like Chainlink or Pyth, because they ultimately are equal users of the chain like everyone else. Much of the data on Flare is free because of that. And it means that we also don’t have to have a token, which means that we can keep our data free and the network can benefit by people building with that data, using it in their applications and generating transaction volume.
Secondly, by unifying the security of the network with the oracle through merging that validator and data provider role, we can maximize the decentralization and the security budget. Flare has 100 infrastructure providers who are providing validation, but each one of them is contributing to every single price. On Flare, we can have up to 1,000 prices updated every single block and each one of our 100 infrastructure providers is contributing to every price. And we have about 67% of the circulating supply of our token, securing those infrastructure providers in some way either staked directly or delegated to their oracles.
In terms of the decentralization, having a large number of providers providing a price and on Flare, that’s essentially a cohesive number of providers providing a price and having a very, very high security budget. No other project really comes close to providing that level of protection around data. Lastly, because we’ve built the oracle into the chain, we have had a lot of flexibility on the design, which means that we can optimize the chain for being able to handle data, being able to minimize cost of handling that data, whereas third party oracles are very constrained by the network they’re operating on, they’re constrained to the design decisions made by another network.
Ian:
Do you have a specific example of some of those design constraints that don’t apply in the Flare context?
Hugo:
Oh, for instance, we can give a rebate within the network for submitting prices.
Ian:
Okay.
Hugo:
During periods of very, very high traffic, we can essentially charge the standard gas fee but rebate that back later.
Ian:
Interesting. Quite a bit different than the architecture that people are probably familiar with on other networks. Just so I’m clear on the… My role as a validator in, say, Ethereum, I’m basically accepting requested transactions, producing blocks ultimately. I have to have some amount of Eth in the node if I’m running a full node on my own, like 32 Eth. If I start falling down on my responsibilities to accept transactions and produce blocks or I’m trying to manipulate them in some way, eventually that catches up my staked assets or rewards will be struck. And if I do things like don’t keep the node up or operate in the right way, all my assets are kind of ultimately at risk. Same basic concept here, but then I have an added responsibility of providing this oracle data as well. Is that right?
Hugo:
Mm-hmm.
Ian:
Okay.
Hugo:
On Flare, you’ll earn zero validated rewards unless you are also part of the oracle and submitting.
Ian:
And how does that work? Let’s say that the data is not inherently on the chain, so it’s some piece of information that I need to pull in. Like you mentioned, real world asset prices earlier, so I need to collect that from somewhere. Does that mean that every entity, your 100 infrastructure providers need to then figure out how to go and collect that commodity price data from somewhere?
Hugo:
Absolutely.
Ian:
Okay.
Hugo:
Yeah. We were shocked when we launched what we call our canary net, which is called Songbird. How quickly that happened and how quickly, actually, machine learning took over, how quickly people started integrating machine learning into their role as a data provider in order to essentially provide something that was getting into the rewarded set. Essentially, their machine learning was interpolating where the price was when they sampled it versus where they thought the price would be when the submission is revealed. That’s been very interesting to watch. In fact, there’s been an arms race within our oracle in order to provide a better signal.
Ian:
Interesting. And what happens when someone wants a new piece of data that doesn’t exist? How does that then get added to the oracle set?
Hugo:
This is quite nice. Essentially, we have 100 data providers and we have an ability to upgrade or update what the prices are, what’s being put onto the chain essentially. And that’s just a very simple governance system, whereby people make a request, the providers look at the request, and they vote across themselves whether they feel that they can add it.
Ian:
Fascinating. Democratic governments around data access and control. I recently had the head of product from Chainlink Labs on the podcast and one of the things that they seem to be very focused on was the next generation of their architecture, which enables… They call it the Cross-Chain Interoperability Protocol or CCIP. And so they seem to be moving up stack in some ways from just being the classic oracle data provider feed to a general purpose message broker across multiple chains, which in theory also allows not just information but actual value to flow between chains.
Their argument was better than bridges, more secure because of the nature of the validation security architecture. I am curious, as you think about people using Flare, there’s always this challenge of like, “Well, how do I get onto Flare? Do I need a new wallet? Do I need a new set of assets that I don’t currently produce? How do I pay for things like gas? So I need the native token.” How does one get into the ecosystem and do you see eventually maybe building to what Chainlink has developed with CCIP or do you have other ideas on potentially a more secure path there?
Hugo:
I mean, we’ve just done a partnership with LayerZero, Stargate, which already serves… It already essentially is handling that kind of messaging that CCIP is trying to get to. I think the first version of LayerZero I would’ve bulk tap in terms of its safety, but they’re V2 architecture, which allows for decentralized validated networks of which we could potentially build our own DVN. Flare is kind of already a DVN. We just need to figure out how to integrate that specifically with LayerZero.
That’s kind of their out-of-the-box with Flare, but more specifically, I think the DVN model is much more interesting than CCIP because it’s modular. It has modular security. Meaning, for a very low value transaction, I can choose a DVN that maybe has 10 people. It’s not really important. It’s maybe $1, $5. For a very high value transfer, I can customize my security by choosing some set of DVNs. That’s really much more interesting than trying to create one cohesive network from my perspective for that kind of thing.
I think interoperability solutions are broadly fairly well-gated for, but I do think there’s complexities in some of them, but I think the DVN model and essentially the modular security that things like LayerZero offer is probably about as good as you can get.
Ian:
Yeah, that’s great. I mean, I think LayerZero is a really interesting alternative to CCIP, so that’s exciting to know that it’s already connected to the network. Maybe contextualize a little bit who’s using Flare today and where have you maybe seen some of the sweet spots in terms of things that people are able to do, given your unique architecture relative to, say, Ethereum?
Hugo:
I mean, we have quite a sizable number of people that have decided to build on the chain. We have, really, a lot of DeFi protocols at this point and Gnosis being one of the first [inaudible 00:26:21] and a lending protocol. The Stargate I just mentioned and LayerZero, Kenetic lending protocol, same group that built BENQI. They’ve also built something called Sceptre, which is a liquid version of our state token. We have SparkDEX which is both a V2, a V3 Uniswap and a perks DEX.
There’s quite a large group of entities that have built… Those are the ones that have come on very recently. Obviously, we have quite a few partnerships with a lot of entities around the space that do professional validation. One of the data providers on Flare that’re providing data and doing validation is Google Cloud. So I think we’ve… When we talk to developers, they absolutely love what Flare is doing and why. And that’s because basically if they’re on the Ethereum architecture, the principle way to consume data is Chainlink and that really sort of goes to the differences of Flare and Chainlink.
For starters, Flare is a EVM layer one with enshrined oracles. Chainlink’s a third party data provider. We have four real key differences: decentralization, security, cost, and ease of use. We’ve really been through decentralization. Chainlink’s most demanded feed has, I think, 31 providers, none [inaudible 00:28:05] staked. I believe they have some kind of staking system in beta, but, I think, in their beta, they have about 7% of their token that is staked. So 31 data providers in their most used price and they have 11 in their least used priced. Whereas as I said, on Flare, all 100 are providing that information.
In terms of stake, Chainlink’s using 7%. We’re at about 67%. These elements really mean that you’re just trusting Chainlink, and so developers really, really like the aspect about Flare that they feel more comfortable and our feeds are much, much cheaper. In fact, all of them are currently free and there will be the opportunity to pay later when you’re demanding more complex data, more expensive data to retrieve. That is built into the system already, but I think the biggest thing that really matters to engineers, at least from the construction of the app side, is the ease of use.
When you are a developer looking at using existing oracle systems, you have to analyze the security of each feed. As I said, the worst Pyth feed has five data providers. That’s not a safe feed and this means that developers not only are having to build a product, but they’re also having to be a risk analyst, which they don’t really want to be. And so I don’t think forcing developers to analyze the risk of your pricing is a sensible thing.
This really makes for developers a much greater experience and encourages innovation both on Flare but also on innovation of data, because when we add a feed, it has the same safety as the most demanded feed. It means if a developer wants new data, then we can add that feed and that data can be consumed and that really encourages innovation. Broadly, if you’re developing on Ethereum, it’s a fantastic platform as is, to be honest with you, Solana, but I think they’ve done some very interesting things. I don’t necessarily appreciate all of them, but they’re great platforms. But ultimately if you want data, you have a limited choices.
Ian:
Yeah. One of the things that occurred to me while you were explaining that is when I think about pricing failures that have been spectacular, it’s typically been in the context of a flash loan attack, where I’m able to buy a fairly thinly traded or low supply token, manipulate the price in some way, take a loan against that inflated value, then convert that loan to asset into some other asset, stable coins or whatever, and kind of run off with the money and never pay the loan back. At least as I understand those failures, and maybe you’ll tell me I’m wrong, it’s less about the data feed setting the prices and the lending protocol being corrupted themselves and it’s more about relying on a single price or this easily manipulated price. So it’s not strictly an oracle failure, at least as I’ve understood it, but maybe I’ve gotten this all wrong.
Hugo:
Well, I mean, there’s a bunch of different ways you can have oracle failure.
Ian:
Yeah.
Hugo:
For instance, with Pyth, there was very clear manipulation by the data providers in the early days. I don’t know if it still exists, but certainly in the early days there was very clear manipulation by the data providers, principally because one of those data providers was FTX or Alameda. I can’t remember. That was an absolute oracle design failure if your data providers can manipulate your feed.
I’d also argue that a lot of the reasons you haven’t seen these kind of things is because there’s really a pretense of decentralization within these things. Essentially, the data providers know the founder of the project.
But there’s a number of other ways that oracles can go wrong. You have engineering mistakes, which I think was the most recent oracle issue with ROE. Essentially, someone took over the contract because probably, I think, a private key lead or something like that. But you shouldn’t be able… If you engineer a protocol properly, you shouldn’t be able to take over the contract from a single private key. That’s not sensible.
On Flare, we try to rectify that with very, very extensive auditing and testing, then testing on a testnet, then testing on a canary net, and then we roll it out to Flare, our canary net, Songbird. If you have bad protocol design, I’d say that’s what happens when you have limited number of data providers providing a particular price. The protocol is designed to allow for a limited number of data protocols to provide a price rather than… On flare, all data providers must provide the price, otherwise they don’t get rewards. And so that’s your protocol design, kept missed updates and that has happened on Chainlink. This is from a lack of data providers. Flare doesn’t suffer from that.
Lack of decentralization is obviously the big one. And then the biggest one that matters to me and the thing is the mismatching, your safety budget relative to the value of the protocols that your oracle is serving. Obviously, if the stake you have at risk is less than the value from an attack, then the probability of the oracle stealing the money is higher.
Ian:
Yeah. I’m curious, going down the path of decentralization, one of the things that… It seems like a number of teams building on Solana are attempting to do is create fully on-chain order book. It seems like the gap to doing that on other chains has been primarily one of performance. At least that’s how it’s been articulated by the folks who have chosen to build on Solana, where you’ve got this higher transaction throughput. But you chose to build on the EVM chain. Any thoughts on that? It’s like trying to deliver an on-chain order book in the long-term roadmap or is that something…
Hugo:
Well, we actually have a project on Flare that I should have mentioned earlier called Rainlang that has built an on-chain order book, essentially an on-chain order book through solvers. So you submit the things you wish to trade around, your prices and all that kind of stuff, on chain, and then the solvers essentially create those trades once the prices hit. I think that’s an interesting way to do it for the EVM world. Our interest is in developer adoption. Obviously, Solana has had a lot of adoption now, although I would question how much of it’s real versus how much of it’s just meme coins.
There’s a lot of meme coins. The ratio is probably 95:5. I’m not certain. EVM has generally been, and I think continues to be, the broad mechanism for adoption of a layer one or a layer two. I think the biggest aspect of this is can you take compute off chain if you really want high performance? Because you can’t… Even Solana proves that you can’t have extensive decentralization if you want very high performance. Using on-chain compute, what compute can you take off-chain that allows you to get that performance without sacrificing too much decentralization?
Ian:
Interesting. So it sounds like you’re suggesting that oracle architecture native to Flare allows you to potentially take more compute off-chain yet still have…
Hugo:
I mean, the oracle architecture is an off-chain compute system to start with, so we’re broadly just doing proofs of everything.
Ian:
Yeah. Fascinating. Totally different direction for my next question. The big tug of war, I think, in the industry right now relates to responsibility at the chain and protocol level and token issuer level for what’s happening in the ecosystem, where we have this multilayered know-your-customer, anti-money laundering regime, and traditional finance. Can that be replayed across crypto ecosystem? I’m curious to hear where you fall on the view of that push from regulators generally, and then specifically anything that maybe is happening in the Flare ecosystem potentially related to permissioning or KYC that’s maybe native in the network.
Hugo:
I think, app-based, the native token and the network itself has to be permissionless and decentralized, otherwise there’s no point being here. I think there are aspects, especially when you’re touching real world assets, which absolutely and very clearly meets the definitions under all regulations pretty much. I think when you are doing things that are regulated, you absolutely have to fit in to the regulated unit framework. I don’t think that…
If you think about it, this space started out as a reaction to the global fiat system and there’s two ways that it can become the system. And that is either through an abject failure of the existing system or through regulation, accepting that it becomes a bigger part of the system. Either you’ll have all your chips on an abject failure, at which point crypto fills the void, or you accept that crypto isn’t going to immediately tomorrow take over the entire space and the entire financial industry, and you accept that regulation where you build something that fits into the regulatory purview must exist and must happen.
With our data angle, we think that compliance and KYC and AML and being able to prove those kinds of things is something that Flare is going to capitalize on. In terms of permissioning, I probably haven’t gotten on to some of the protocols we’re building, but we’re building a over collateralized bridge for Bitcoin and XRP, so to bring that to Flare over collateralize with stables in Flare. Some entities within that bridge will want the ability to do KYC on the counterparties that they’re interacting with. Not all of them, but some of them, so we are building in KYC to that system as an optional aspect.
Ian:
That’s really interesting. Say more about that. The built-in KYC, is that an on-chain validation system or you’re doing kind of an off-chain?
Hugo:
Essentially, it’s at the discretion of the party that is operating. It’s a little complex to describe how the bridge operates. Essentially, it has an entity. It’s more like a series of small bridges but it’s one protocol, where each… Let’s say I am an entity, I put up collateral. This allows me to receive Bitcoin and, against my receipt of Bitcoin, I am issued or whoever sent me the Bitcoin is issued Flare Bitcoin, and that is secured through my collateral that I’ve put up on Flare.
Now, in some cases, I may want to be able to KYC who is minting with me and redeeming with me and so building in KYC, basically. Building a KYC function into the protocol helps with that, and then the agent who’s provided the collateral and is doing this work, they can go to any off-chain KYC provider that they like, that they’re happy with. Ultimately, we’d like to bring the whole thing on-chain if possible.
Ian:
Yeah. It seems like the missing ingredient to bring something on-chain is like a verifiable proof of identity. There’s lots of projects who are working on this, but it doesn’t seem like we’ve actually settled on a particular one that people trust and will use reliably. It’s sort of absent and we’re stuck doing everything in the paper context.
Hugo:
Well, I think, for a start, what I would like is for… It would be nice for our agents in the system to be able to demonstrate. I called the Chainalysis API. This address that I’m interacting with was not on any list, was not on any blacklist. There was no evidence that this was a bad person. That’s a really good stop.
Ian:
Yeah, I totally agree. I appreciate the shout-out there. That’s an architecture I think we could get behind. Hugo, this has been a fantastic discussion. My customary closing question is always a look towards the future. What’s coming on the roadmap for Flare that people should be watching out for?
Hugo:
I completely missed two things in this call, which was the Flare Data Connector, which is our ability to prove Web2 and Web3 events. That’s coming on Flare towards September or October. That’s very exciting.
Ian:
Talk a little bit more about that one. So the ability to prove Web2 events sounds fantastical to me. What does that mean in practice? Give us an example.
Hugo:
So it means basically using our data providers, the same entities that are providing prices, for providing… Essentially, you request an attestation from a Web2 API and our data providers go to that Web2 API and essentially we have a proofing system that uses Merkle trees and each event is a Merkle tree leaf. We end up proving the root, so that means we can end up proving… In a single cycle, we can prove almost an unbounded number of events. That event proof can then be used on-chain by any [inaudible 00:45:18].
Ian:
Wow, that sounds amazing. So that’s launching in September.
Hugo:
Yes. It should be around September, October time. And then, I think I’ll split this question into a couple of things. Also, we have a whole compute strategy, which I probably don’t want an off-chain compute strategy using trusted execution environments, which I probably don’t need to get into right now. But we’re doing a very fun hackathon around that.
Ian:
Okay.
Hugo:
In the industry, I’m looking forward to seeing more forms of account abstraction, specifically one of the use cases we think for trusted execution environments is things like account abstraction being able to make it lower the barrier to entry for people to use blockchains. I mean, it would be really cool to make it just so much easier than a traditional bullet. I’m pretty interested to see how the political calculus shakes out-
Ian:
We all are.
Hugo:
.. [inaudible 00:46:27]. And depending on who wins, whether any of the promises that are made to the crypto community end up in anything concrete. And then on Flare, we have the second version of our oracle, what we call FTSOv2, so our price oracle going onto main net in September. Also in September, we’ve got the launch of that bridge I was just discussing called the FAssets, so being able to bridge Bitcoin and XRP onto Flare. Can’t tell you exactly when that launch will be, but it’ll certainly be fairly soon. Those are some of the things [inaudible 00:47:10].
Ian:
It sounds like a really busy fall for you all. Is that hackathon you mentioned open to the public? Anyone can participate?
Hugo:
Absolutely. It’ll be [inaudible 00:47:19].
Ian:
Awesome. We will link to the details in the show notes so that people listening can go and find it if they’re interested.
Hugo:
Oh, we haven’t published anything about it yet.
Ian:
Hopefully, by the time we publish this podcast, we’ll line up the timing there for some promotion. But Hugo, this has been a fantastic conversation. I feel like I learned a ton. Thank you so much.
Hugo:
Oh, great. My pleasure. Thank you.