New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Flare Workshop - Bring Any Web2 Data On Chain I Nik Erzetic

ETHGlobalThu, Oct 9, 2025, 12:00 AM

Nik Erzetic’s Flare Workshop demonstrates how to bring any Web2 API data on-chain using the Flare Data Connector (FDC). The session covers the FDC workflow: creating attestation requests, using verifier servers, submitting requests to the FDC hub contract, validator data retrieval, JQ filtering, Solidity struct encoding, and Merkle proof verification. Nik walks through the Flare Hardhat Starter repository, showing how to adapt example contracts and scripts for custom projects. He explains modifying URLs, JQ filters, and AI signatures for different data sources, and highlights a weather insurance DApp example. The Q&A addresses proof structure (not zk-proof, but Merkle-based), handling sensitive API keys (not private after attestation), and further resources on the Flare Developer Hub. The workshop emphasizes decentralized data attestation, smart contract integration, and practical steps for developers to connect Web2 data to the Flare blockchain. 00:00 Introduction 01:14 Flare Developer Hub Overview 01:43 FDC User Workflow Explained 05:05 Flare Hardhat Starter Repository 06:36 Example Contract and Script Walkthrough 10:06 JQ Filter and Data Processing 13:02 Solidity Struct (AI Signature) Explanation 15:33 Modifying the Starter Project 18:04 Q&A: Proof Structure 20:07 Q&A: API Keys and Data Privacy 21:11 Q&A: Weather Insurance Example 24:59 Additional Resources and Closing _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 🇫🇷 *ETHGlobal Cannes* This workshop is specifically for ETHGlobal Cannes, a 3-day hackathon held July 4-6, bringing together the most skilled web3 developers, designers and product builders from all around the globe for a weekend-long adventure to advance the Ethereum ecosystem! Watch the full ETHGlobal Cannes 2025 playlist here: https://youtube.com/playlist?list=PLXzKMXK2aHh5N2DCwhcEshNW9C8knZ1T-&si=Lc-WOyfkAVP2--R4 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ ✅ *Follow Flare* X: https://x.com/FlareNetworks ✅ *Follow ETHGlobal* X: https://x.com/ETHGlobal​ Warpcast: https://warpcast.com/ethglobal Website: https://ethglobal.com YouTube: https://www.youtube.com/c/ETHGlobal _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _Are you interested in Ethereum development and entrepreneurship?_ 👉 Sign up for the next ETHGlobal event: https://ethglobal.com/events 🎁 Get exclusive access and perks with ETHGlobal Plus! https://ethglobal.com/plus 📣 Want us to throw an event in your city? Tell us where! https://ethglobal.com/city _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Transcript

[Music] Cool. So hello everyone. Uh thank you to for coming to this workshop. Uh this workshop will be on the flare data connector. Uh and specifically how you can get any web to uh API data onto the flare chain.

Uh the way this presentation is going to work is we'll have 20 minutes of presentation followed by eight minutes for Q&A. So if you have any questions uh do save them for then. Um so I'll first explain how FDC works really re really briefly. Um I'll go through how the user workflow is supposed to look like and in the end I'll also just briefly mention how you can modify the existing code on the uh flare hardhead starter repository uh so it can serve your own projects or rather how so it can serve as a baseline for your own projects. Um, but before we get started, I would first like to mention that there's the Flare Developer Hub.

Um, and Flare Developer Hub is the go-to place if you need additional written guides um, and overviews of our technology. Um, more specifically for the Flare data connector, you can go under FDC, FDC guides, and hard hat. and and there is also a more expanded uh guide which basically covers all that I going to talk about today. So first of all uh let's look at this diagram here uh that explains the user workflow for um uh using the FDC. So, first of all, um let's say you're building a D app that um needs some external data to function.

Um for example, you could be building an insurance agency that needs weather data to resolve insurance policies that rely on that weather data, which by the way is a guide that I have written, so you can look at that in your own time. But anyways, um the diagram here uh demonstrates what the user workflow looks like. Um first you have some external data that you need. Um the first thing you need to do is create an attestation request to the FDC protocol. Um and the the atestation request is submitted as specifically encoded byte string.

And you could of course do this manually, but we have a verifier server that can do that for you if you just provide it with the um with string data uh that uh basically matches the attistation request. Once you have that, you submit the attestation request to the FDC protocol through the FDC hub contract um which leaves on the flare chains and then you need to wait for the voting round to finalize. Um so the voting round finalizes in at most 180 seconds. It's usually much much faster. What will happen in that time is uh the validators of the flare network which we call data providers will go to the URL that you have provided uh get the data apply the jq filter that you also will need to provide and then encode that as a solidity strct.

um the they will also like they will also hash the data and then with consensus write the hash onto the flare chain. So at that point the round will have finalized and you will be able to go to one of the data providers, one of the validators and request the data from them. Um, and then when you get the data back, you will basically be able to do the same thing they did to get the Merkel proof and compare that to the one stored on chain to see if they tried to deceive you or they in fact gave you the correct data. And at that point, your data is basically free uh or good to be used on the Flare chain. Um so that's the overview of the um user workflow.

Um the user workflow is encapsulated within the flare hardhead starter repository. Uh this is a repository that's available on GitHub. So let me open that up really quickly. Uh so uh the flare hardhead starter is a good baseline uh for your projects uh because it's basically fun functioning code. I have already cloned that and um uh basically copied the example environment file to the environment file.

Um and now let's look at the we don't have the so okay first of all let's look at the contract that we will need uh and this one is under contracts and fdc example web to JSON um the other contracts within this or the other files within this folder are all different examples for different atestation types um so what this contract does it simply goes to um it simply takes an input of a Star Wars character and saves it to a list. So a very very basic thing. Um what is more interesting is the script that actually um goes through the whole of the user workflow and the script is saved in scripts fdc example and web tojson. So I will run the script. So it uh goes off in the background uh while I quickly explain how it works.

So if you go if I scroll down to the main function, you can see that each of the functions here corresponds to one of the steps uh in the workflow that I have described. So we first of all prepare the attestation request. In this step, we um get the data that we have predefined and uh and and basically make a get request to the um verifier server which gives us back the AI encoded data. With that API encoded data, we can submit the attestation request to the FDC hub contract. Um and then we have to wait for the run to finalize which basically happens within the retrieve data improve function.

Uh and with that we can get the data improve back. We can also then deploy our contract the Star Wars character list that I briefly showed. Um you could just as easily uh access a static pre-eployed contract at this point. uh and then we interact with it by giving it the proof. Um so if I open up the terminal we can see that first of all the request was prepared.

This was the data we inputed the URL um the JQ filter and the AI signature and the AI signature is the encoding of our solidity track and I will show you how you can get that u the simplest way possible. We see that the um that the data we provided was valid. This is the uh ABI reco uh encoded request uh and we submitted that to the FDC hub contract. Um this all happened in the uh voting round with the ID with this ID basically. Um and then we also got back the proof which so the proof is uh constructed from first of all the hex encoded response.

This is where our data is and then the actual proofs that we need to uh check. Um, and lastly, we deployed and verified the contract, inputed the proof, and the um the Star Wars character we were looking at was uh R2-D2 with the body mass index of 34 uh if anyone was interested. Um so um let's now briefly talk through all the components of the request or at least the most interesting ones. Um you can see that they are defined right at the top of the example uh script. Um there is a thing commented out because the UR uh the API stopped working.

So we are temporarily using the Star Wars API.info instead dot ofdev. And I mean this is simply an API that gives you Star Wars character information. No need to spend too much time on that. What's more interesting is the post-process JQ.

This is basically the JQ filter. Um, and the most like the easiest way that you can um workshop that is to go to a website like uh JQ Playground. Um, and this is a website that basically allows you to live uh perform the G JQ filter on input data. Um, and let's see if I can get some real data real quick. Um, and I think that the easiest solution is to just go to the Star Wars API and this will require some um bending on my part.

Okay, perfect. So, let's take the um Luke Skywalker data um and just um copy all of that into the JQ playground. Um so, what what we can now do is um stuff like that. So we could like get the name of the character and this would be um we would first of all have to take the first element because I copied the thing weirdly. Um and then call the name to get the name field.

Uh but we would also be able to do um some simple transformations um which in this case uh let's see uh yeah let's take height uh and that would be again zero field height um and we can also apply uh transformations like to number um and I possibly need to enclose this. Let's see. Anyways, look at the documentation for that basically. Um so anyways, this is the second part the jq filter. Um and the last thing you need is the solidity strct.

So the AI signature. Um and this is how the data that you get back and filter should be encoded. And the easiest way that we found of doing this is to um basically uh defining a like a mock or a um placeholder function within a contract. So uh if I open web two to JSON file uh up you can see that there is a data transport object strct at the top of the file um and I'm basically I'm defining a function called AI signature hack which which takes the data transport object as one of the parameters and does nothing. But what this allows us to do is to then compile the code, go to the artifacts contracts, uh, FDC example web to JSON, and then it takes a bit of looking to find the, uh, to find the AI signature hack function uh, within the AI signature of the contract.

And we can see that uh among its components is the AI signature of the um of the uh of the data transport objects strct and this is the thing that would be inputed into the um into the script. So with uh five more minutes, let me just quickly uh point out the uh the places where you can modify uh the existing script or exist existing project to serve as the baseline for your own projects. Um first of all, you of course need to define your own contracts. Um, and the only thing that that contract needs to do to be able to work with FDC is to get um as a parameter a I web tojson.proof prove uh parameter as input and all you need to do with this input is um to first of all um uh validate it and you do that uh as it's shown here through a FDC verification contract um and then you of course uh decode the data into the data transport object and afterwards uh it's up to you what you want to do with that data.

So that's the first modification that's needed. Um the second modification is of course providing a new URL which is the URL that you will would be using. Then the third modification is the uh jq filter that you're applying. The fourth is the AI signature which should match the data transport object that you define. Um and then there are only a few more modifications left.

Um namely you um need to deploy your contract either in this script or in a separate script. Um and then you need to access the contract here of course and interact with it. And the interact with contract script uh sorry function uh is the one you would be modifying to accept the input that matches your contract and of course calling the function on that contract. And so these are all the necessary modifications to get the project working um with a simple uh one uh contract example. Um but there are of course much more complicated things that you can do and I recommend that you look at the other guides for inspiration on that.

Um but with that I think I'll conclude this. Um, if you have any additional questions after the Q&A, visit visit at at the booth. Uh, but yeah, now we have 10 minutes for questions. So, um, yeah, a question right there. I think he will bring you the microphone.

Uh, thanks a lot for your talk. Um, I see you, uh, I saw you use proof. Is that a like cross 16 proof or is that anything signature or something like that?

Yes. So um the proof that we use is basically uh just a custom strct that we have defined. Um I mean it's a wait the question was is it a zk proof? Uh it is not. It's a like it's a simple strct uh called a proof because it uh uh has um it contains a an array of Merkel proofs uh that can be uh crossch checked against the data so that the data is valid but it is not a Merkel proof.

Uh I can open up the proof I mean the proof strct itself. Um it's basically it has an array of Merkel proofs uh and a uh response strct which again contains the attestation type source ID um request body and response body and data is stored within the response body. Um cool another question there. Hey, uh for the data connectors, can you embed API keys or like sensitive information when you make some uh API calls to external data?

So the question is can you uh embed sensitive information within the data? The answer is no because I mean the answer is yes but probably not. So you could do that but once once you perform this whole attestation request thing once you get the data through FDC it becomes exposed to public. So at that point it's not private data anymore. Um so you could do that but you would basically destroy the data that way.

Yeah.

Any more questions? Cool.

Yeah.

Uh you mentioned you have a like uh uh dup or example of the how to get the weather data. Would you like to show that?

Uh sorry I didn't catch the question.

Uh you mentioned uh you have the like write up or example of how to query or get the uh weather data. Can you show that?

Yeah. Yeah, I can show that. So, um the question was about the the weather data I have mentioned, right? Who um so if you go to the um first under contracts there's the weather insurance which has two subfolders. Uh I'm looking at the wrong thing.

I'm right. Cool. So under if you go under weather insurance there's u uh mint temp agency um basically this defines a simple insurance agency which allows you to create a contract with specific coordinates and the minimum temperature threshold. And so if you provide a proof that the uh threshold was exceeded uh it is considered that the loss has occurred. Um the more interesting thing is probably the script that does that I mean that uh interacts with that.

So if we go under mint agency there are first of all scripts to deploy the agency itself. scripts that um uh allow you to create an uh an agency to um claim a sorry create a policy, claim a policy and then resolve the policy. Um and so let's quickly look at the um create policy. Uh so create policy contains the latitude and longitude of a real place in Slovenia. Um what I first do is go to the make an API call because that thing contains the uh uh the coordinates of the nearest weather station and I want to create a policy that uses those co coordinates instead of these ones.

uh so that I can uh cross check it with the response. Um and then I simply create the policy and for the policy resolution it is again a um um API call to open weather um with uh uh the jq filter and the AI signature. And what's interesting here is that uh be the API requires a key which is free to get. Um but um you still need to provide it somehow. Um and let's see if I can find it real fast.

Basically the uh web 2JSON at the station type allows you to also input uh query parameters. Um and so uh I'll just query. So prepare query parameters. Basically um I I'm passing in latitude and longitude as well as the API key as query parameters. uh and I just basically doing a JSON string if I that and the query parameters will be um passed in as uh basically a field in the request body and then the u back end will be able to um like construct the correct URL the correct API call using that.

Um so that's just a quick preview of it. Uh but there is also a guide on the uh on the flare developer hub um if you go under uh FDC guides hardhead and weather insurance and this goes much more into detail about uh it all. Um I think we have enough time for just one more question if anyone has it. If not um or if another question appears I I invite you to visit us at booth. It's um like we have a nice view of the main venue.

So you can find us there and we'll be happy to answer any and all of your questions. But otherwise, thank you for coming to this workshop. [Music]

Automatic transcript — names and jargon may be misspelled.