DAO Snippets: Engineering Web3 — an interview with Burak Benligiray
Although Web3 is still in its infancy, it has experienced massive growth over the last few years with no sign of stopping. In 2021, the number of developers in Web3 reached an all-time high, with the most significant increase in employment in history. As such, this industry is growing at a rapid pace, with new blockchain projects being developed daily. This has opened up new career opportunities for people worldwide who can participate remotely to contribute value, even with unrelated experience.
This blog series tells the stories of individuals who took the initiative to get involved in Web3 by contributing to the API3 DAO, a blockchain-governed organization open for everyone to join and participate. In today’s article, we meet Burak Benligiray, co-founder and core developer of API3. With a background as an electrical engineer and a Ph.D. in deep learning, he has successfully transitioned into Web3 with a unique story to tell.
Burak Benligiray, co-founder of the API3 DAO
Marcus:
Hello, Burak. Thank you for having this interview with me. Can you tell us a little about your background and why you decided to become an electrical engineer?
Burak:
Sure. Here in Turkey, university admissions are based on a standardized exam. While preparing for that, I planned to become a computer engineer because I like working with computers. However, I did quite well on the exam and picked electrical engineering mostly because its admissions were more competitive. I later found out that it wasn’t for me, though.
M:
That was quite a spontaneous shift in direction. What kept you motivated to continue your studies?
B:
The nice thing about electrical engineering is that it’s one of the main engineering fields along with mechanical, civil, and chemical engineering, allowing you to transition to interdisciplinary engineering fields later on easily. In the second half of my undergraduate education, I was able to focus on computer architecture and embedded electronics, which I enjoyed a lot more. As I finally reached post-graduate education, I could further specialize in certain areas that matched my interests, so I was doing computer science research while primarily teaching about embedded systems. I enjoy working on various things, and diversity is not a bad thing anyway.
M:
I agree, and there is the potential that different subjects complement one another, creating an even broader spectrum of knowledge. Eventually, you pursued your P.hD. in deep learning. Why did you choose that particular field?
B:
My Master’s degree was in geometric computer vision for a human–machine interaction project I was working on as a researcher. I wanted to work on that because it complements virtual reality technologies, which I’ve always found interesting and was starting to make a comeback at the time. After I was done with that and was looking for a Ph.D. subject, it became apparent that deep learning would become massive. Ultimately, I tend to choose to work in fields that I identify to be the hottest and most competitive. Doing my Ph.D. in deep learning with limited advisory support and funding was challenging, yet I enjoyed academic life in general because of the freedom it provides.
M:
Seeing that you constantly challenge yourself and keep yourself busy by diving into different fields is inspiring. How did your journey into Web3 eventually begin?
B:
I have been following the field closely since 2013, but I dived deeper into it in 2018 with the intention of actually building things. Perhaps due to my engineering background, my motivation was to build something with real utility rather than some kind of financial tooling. After researching how to implement some smart contract ideas, I realized that none of them were feasible because they required API integrations that didn’t exist back then. To be able to build the projects I had in mind, there needed to be a solution to this problem. This was when I identified a problem in the blockchain field that I found worthwhile.
M:
How did you proceed when you realized that API integrations for smart contracts don’t exist, hindering you from building your projects?
B:
Before attempting to solve the problem, I looked for people already working on it. In the same year, 2018, I started to follow an up-and-coming project discussing similar problems: Chainlink. While doing so, I met many like-minded people, such as Heikki and Andre. We built Honeycomb, an API marketplace built partly utilizing Chainlink technology, and many of the same people went on to build API3 together later on.
M:
What was the motivation for building Honeycomb, and was it your first project in Web3?
B:
Yes, Honeycomb was my first project in this space. We designed Honeycomb assuming Chainlink was going to provide the API integration framework and we would be able to do the operational part of business development and technical integrations with API providers. The result would have been an API marketplace from which smart contract developers would come and pick all kinds of oracle services. However, it soon became apparent that Chainlink did a significant pivot and focused their efforts on data feeds. This ended up being an existential crisis for Honeycomb because the underlying technology was no longer satisfactory, and we were only using it with the assumption that it would be continually improved in the first place.
M:
I assume this was the final moment you decided to build your own oracle project.
B:
Yes. Essentially, there was no other option than to take building it into our own hands. It was clear that the original architecture of Honeycomb was doomed, so we would have to build API3 first for a kind of Honeycomb to ever be feasible.
M:
The timing seemed right. What was your experience like when you began building API3?
B:
We attributed the crisis we faced with Honeycomb to the dark side of centralized governance, so we were convinced that API3 should be a DAO from the start. In 2019, there were barely any functional DAOs, yet there were a few examples with relative success that we could consider as a proof of concept. In addition, there were very few reference DAO implementations and barely any tooling. Our requirements were also very restrictive with the exact staking and governance functionality that would also need to be future-compatible with the upcoming Service Coverage feature. I was a little frustrated throughout the process because I wanted to build oracles, but I found myself building a DAO for quite some time.
M:
You had to overcome many challenges. Is there anything you would do differently if you could build everything from scratch again?
B:
After releasing a version of a protocol, we tend to encounter shortcomings while using it and then address these in the next iteration. This cycle repeats itself every six to twelve months. You cannot expect to have that hindsight when you start, however. Otherwise, we could develop everything in a short amount of time. While designing a protocol, we uncover knowledge and then use this knowledge to improve our design. It’s a necessary research process. In light of that, I would not change much if I had to start all over again. Maybe I would change some of the priorities of our products. For example, we could have completed QRNG much earlier because there wasn’t anything blocking it, and data feeds could have been prioritized a bit more. I’m happy with how everything worked out in the end, though.
M:
That’s a fair assessment. What are some things you’re working on or thinking about at API3?
B:
In general, I want the whitepaper to be delivered with minimal delay. This is a heavy responsibility that is rarely achieved in this space. The good thing is that many unknowns were figured out in the last six months, and it’s now just a matter of time for all the moving parts to come together. The open question is how to improve it further. While considering this, I mainly think about Service Coverage. The version discussed in the whitepaper is mostly a minimum viable product, yet there are questions to be answered for it to be utilized at scale. It’s mostly a matter of ensuring product–market fit, which is difficult in a space where recklessness is rewarded, at least for a while. Still, I think the idea of Service Coverage was ahead of its time and is the only feasible way to implement oracle security in a way that covers everything that can go wrong. The oracle space is slowly accepting that, but there’s still the question of how to execute it successfully.
M:
Considering the various challenges along your path, has your initial motivation changed throughout building API3?
B:
It has. We need to change our position when new information is introduced. Before we launched API3, it wasn’t clear how much recognition it would receive and the early plan needed to accommodate that. After launching API3, many people noticed and supported it, and we had to adjust our plans to realize the potential this new situation allowed. Generally, projects with a lesser potential need to deliver fast, or they will fail. If a project has more potential due to good response and runway, more time can and should be spent developing an even better concept that will have more impact. For example, I initially wanted to release aggregated data feeds by early 2021. It would have been entirely possible, yet at that point, what was expected of us was not releasing a few data feeds and getting some adoption but something greater. Consequently, we are using our resources to fulfill that rather than the more modest goals we set at the beginning.
M:
That is exciting to hear, and I share the same sentiment. Would you say that your engineering background influences your work at API3?
B:
Yes, being an engineer manifests itself in various ways. The holy grail of engineering is building something that does the job adequately at minimal costs. Here, the job is what the user needs the product to do and nothing else. Designing an innovative product is difficult because the user doesn’t know what they need the product to do. So we need to build products that solve our users’ problems effectively that they didn’t know they had, at minimal costs. Another thing that being an engineer brings to the table is the habit of expecting no bulletproof solutions and assuming that everything will fail at a particular point. Expecting failure and designing a solution that works regardless creates a safer and more reliable product. This is represented in Airnode, which is designed to work in a way that essentially reboots periodically. If it crashes for whatever reason, it will automatically recover soon after. This is a rather controversial approach. The more traditional solution is avoiding everything that could cause a crash. The problem with the traditional solution is that it assumes one can foresee the causes of all potential failures.
M:
It’s fascinating how your mindset as an engineer affects your work as a developer. Do you have any recommendations for developers who want to get started in Web3?
B:
I suggest solving the problems you encounter in Web3. At least, that’s what I did. I tried to build something and identified obstacles that prevented me from doing so. Upon that realization, I worked on removing these obstacles.
“If you encounter a problem, other people are likely facing the same problem. Consequently, a solution built for it will be adopted by others affected by that same problem.”
M:
That’s solid advice. Let’s move on to our last question. What is your long-term vision for API3?
B:
I believe that a smart contract is only useful as it facilitates a real economy. It can generally be achieved by enabling agents to employ agents to perform economic activities. Obviously, the usual way of things is people employing people to do things, and we’re now seeing people having AI work for them. However, I envision the most potent of this configuration to be AI agents hiring humans for micro-gigs. Let me illustrate my idea with a simple example. If an AI wants to move an object in the real world, how would it achieve it most efficiently? Most people would suggest that the AI would command a robot to execute the task, yet having enough robots readily present to perform all potential tasks would be highly inefficient. Instead, the most efficient solution for the AI agent to move an object in the real world is to pay a human to do that job in most cases. A powerful AI capable of manipulating the real world can easily gather wealth, which creates a feedback loop. In such a setting, smart contracts could act as the trustless medium for AI agents and humans to do business. Whether tasks are completed would be checked through APIs, and humans would get paid accordingly. The more APIs we can integrate, the more kinds of gigs would become possible, eventually establishing something like a decentralized Uber for everything that caters to humans and non-humans alike. AI replacing employers would create jobs very efficiently, opening up new opportunities for most people.
M:
This is a very intriguing vision of the future. I am excited about what is to come and what API3 will accomplish over the following years. We are at the end of our interview. Thank you for sharing your story with us, Burak.
B:
Thank you for having me.
Web3 offers new opportunities for people worldwide to contribute, build and participate. Regardless of their background, anyone dedicated and willing to learn can find their way into this rapidly growing space to write their own story of success. In the next article of this series, we will meet Erich Dylus of API3, who transitioned into Web3 with a background as an attorney.
Join the API3 Community and begin your own journey in Web3.
DAO Snippets: Engineering Web3 — an interview with Burak Benligiray was originally published in API3 on Medium, where people are continuing the conversation by highlighting and responding to this story.