GRTiQ Podcast: 22 Sebastian Siemssen

The following podcast is for informational purposes only the contents of this podcast do not constitute tax legal or investment advice, take responsibility for your own decisions, consult with the proper professionals and do your own research.

00:23
Any application this year and also last year is using The Graph. I don’t know a single one who doesn’t use The Graph and is successful. And that’s simply because The Graph really makes accessing data on the blockchain easier. And I’m not talking about it just makes it more convenient. It makes it possible in the first place.

01:15
Welcome to the GRTiQ Podcast. Today I’m speaking with Sebastian Siemssen, co-founder and lead application developer at Avantgarde Finance, the main developers behind Enzyme. As you may already know, Enzyme is a decentralized Asset Management infrastructure built on the Ethereum blockchain. And as you may have already suspected, I am speaking with Sebastian because Enzyme is not only a user of The Graph, Sebastian, known as Fubhy on Discord has been mentioned a few different times in past episodes of this Podcast. Our conversation covers a wide range of topics including Sebastian’s professional and educational background, what Enzyme is and how it uses The Graph. His unique introduction to The Graph, and a great discussion about how important The Graph is to web3 and DeFi. We started the conversation talking about Sebastian’s educational background in of all things, medicine.

02:14
Sure, so for educational background, you might be a little bit disappointed because I don’t have a formal education in software development. I actually studied human medicine in Vienna. But then while I was studying, I already started working professionally as a software developer – as a freelancer – then got hired by an agency here in Vienna, eventually quit studying, went to Zurich, worked at another agency and then eventually ended up in crypto.

02:38
So what did you study in medicine?

02:40
So you do not specialize in the first six year while you’re studying, you just study human medicine, right? Anatomy, pharmacology, endocrinology, that stuff. And then once you are done, and you become a resident doctor, somewhere at a hospital, that’s when you start specializing as you are already working as a resident.

03:00
So how does somebody who studied medicine with the intention of becoming a physician, and then began doing some freelance developer work and up in crypto?

03:10
Right, so it’s actually not as uncommon to start out in a different field and then become a software engineer, I have a lot of colleagues who are coming from a finance background or coming from a physics / math background, even a teacher. So yeah, it’s not so uncommon, because software development is really accessible, especially since the rise of GitHub and open source software development. So that’s also how I got started as a software developer: just contributing to open source projects. And I already started doing that as a hobby as a kid when I was 14. And then, just through social pressure, I guess, I started studying medicine, simply because my parents both were doctors, and software engineering wasn’t really considered a professional career option for me at that time. But then, as I was studying, and as I was seeing these opportunities emerge for me, through my open source work and the offers that I was getting, I became more and more interested to also pursue this as a career. I think it was around the fourth year. So while I was at the university, that’s when I started working full time – while I was studying – for an agency here in Vienna. And then I moved to Zurich, started a software development meetup in Vienna, and also in Zurich. And at those meetups you meet a lot of interesting people, right? I think if you’re looking for a job offer, or just broadening your exposure to other software projects, meetups are the number one spot, not even conferences, like, just straight up meetups with your local development community. And at such a meet up that’s where I met one of my former colleagues at Melonport. At the time they were the developers of the Melon protocol, which is now the Enzyme protocol, which is where I work. And when I was considering quitting my job and going traveling and backpacking in Southeast Asia, he approached me and offered me to do freelance work while I was traveling, which was really exciting, and a good opportunity for me to combine both the traveling and the freelance work. And yeah, so then originally, I just started as a consultant, a little bit of freelance work for auditing and reviewing the application code base, and helping them out on the application side a bit. And eventually, well, as I got drawn into the crypto and Ethereum community more and more and got more and more interested in that space, I also increased the number of hours I was working with Melonport on a week by week basis. Eventually, I became a full time Freelancer for them. And now I’m one of the co-founders of Avantgarde Finance, and the Lead Application Developer for Avantgarde Finance. And we are now appointed by the Enzyme council to work as the lead developers on the Enzyme protocol. And here we are.

06:11
So Sebastian, how would you explain the interest you have in pursuing a vocation in crypto?

06:17
There’s certainly an ideological and socio economic aspect here, that makes Ethereum and smart contracts and the blockchain and the crypto space so interesting. But for me, as a software developer, as a nerd, as a builder, I just really find the technology so fascinating. And the idea of decentralization at a technical level, and the challenges that that brings purely from a technical standpoint, that’s really what I’m here for.

06:45
So as a software developer, as a builder, what is different about being a builder in the crypto space, versus being a software developer or builder outside of it? What’s the nuance or the difference there that maybe listeners don’t appreciate?

06:58
The difference at the core is really the decentralization of information of data, of truth on the blockchain versus a centralized database and proprietary service. By moving that data out of the control of a single company, of a single organization, it becomes a lot more complicated to work with that data. But also, that data really becomes property of the users, of society really. Moving serverless is what the real difference here is: the company doesn’t own your data. The company does not get to dictate what the truth is. Only basically whatever provably happened, which is then stored on the blockchain, and verifiable by anybody, and accessible by anybody. It’s not a walled garden. That’s really what the difference is for me.

08:01
So Sebastian, one of the reasons we’re talking today is you work on Enzyme, and Enzyme is one of the users of The Graph. And so more and more listeners want to understand the perspective of folks like yourself, who are using The Graph. But before we explain some of that, what can you tell us about Enzyme and what it does?

08:18
Enzyme is an Asset Management Protocol. It’s a platform that allows you to spin up a vault, accept deposits, and then manage a portfolio for you and your depositors. It’s backed by the Ethereum blockchain with an onchain track record for you, the fund manager, and based on smart contracts, enforcing policies, fees, and a plethora of adapters that integrate with various other protocols like ParaSwap, Yearn, Aave, Uniswap, Kyber, and many others.

08:51
Can you maybe for people that don’t understand what an asset manager is and why they might need a tool like Enzyme? Can you give us kind of an explanation or a use case of how people are using it?

09:01
Yeah, so people spin up these vaults on our platform. And a vault is basically an ERC-20 token itself. And, well, it’s a smart contract that follows the ERC-20 tokens spec, and it’s both a store of value that hosts the balances of whatever assets are managed by that vault. But it also, through its own token balance, manages the participation in the share distribution of that vault, the vault shareholders. And so an asset manager could spin up such a vault and accept deposits by investors. And then you’re basically pooling the gas to manage a portfolio and that one vault, and you as a shareholder, just own part of it.

09:48
In theory, I could do this right, I could spin up a vault and I could market myself as a crypto or a DeFi asset manager. And I could let people send funds there and I can manage this vault on their behalf like a conventional asset manager, am I thinking about it correctly?

10:05
Yes, you as an asset manager spin up this vault, invest yourself, right you buy shares of this vault, which is then like you’re buying ERC-20 tokens of this vault which represents your shares in that vault. And then others could come in: you define by which rule others can come in, how much they have to deposit as a minimum, how much they can deposit as a maximum. You can also define a list of wallets that are permitted to invest and no others can invest. You also define a shared action time lock. So how long a depositor has to stay in the fund before they can withdraw their shares out of the fund for their share of the underlying tokens. You can define policies and fees. So management fee, performance fee, entrance fees, exit fees, all sorts of things.

10:54
How would you describe or define what a smart contract is?

10:58
A smart contract is an immutable state machine that, being fed with a signed transaction, encodes the information generated through the logic of that state machine into a persisted, immutable state and, therefore, truth.

11:17
Sebastian, how would you explain how Enzyme might be different from other asset management type solutions?

11:25
Enzyme is a really great fit for active vault managers, we have a very broad asset universe, I think we are at about 250 – maybe even more at this point – assets in our asset universe. It’s backed by a very flexible, extendable plugin-based core, which allows us to continuously expand the offering of the protocol. We are continuously releasing new adapters and integrations with other protocols. At the core, the extendibility expands also to policies and fees. So we can roll out new types of fees. So we can also support very custom requirements by people who want to build on top of Enzyme. Same goes for policies: we can release and deploy new policies and make them available to our vaults, new rule sets, that they want to control their vault with. Yeah, and just in general, that flexibility is really powerful, because it allows us to whenever there is a new development in the crypto space really quickly react to it and to integrate that new thing as a feature onto our platform. And another great benefit of the Enzyme protocol is its upgradability. So if we need to release a new version, because fundamentally, we have to deploy a new change to our core architecture that would not be possible within the extendable plugin system that we have, but is rather be a change to the core architecture. If that is a necessity, and we need to deploy in such a new version, vaults can migrate to that new version on a voluntary basis. Every vote is immutable. And at the time of the deployment of that vault, that vault is guaranteed to function even in the future, as new versions are rolled out. But if you are willing to and if you are keen to use that new functionality of the next release, you can upgrade your vault. And because your vault is a persistent contract, backed by a proxy, that is upgradable will also migrate over your existing investors, we will migrate over your track record. And as a fund manager, you just know how important the track record is.

13:36
How would you describe what your current role is at Enzyme in what you do?

13:39
I’m the Lead Application Developer at Avantgarde Finance, the lead developer of the Enzyme protocol at this time. And in that role, I am responsible for anything that revolves around the application development. So backend services, front end development, infrastructure, DevOps, but I’m also supporting the protocol development team with infrastructural and DevOps work in their areas. So for instance, setting up the testing framework, setting up the continuous integration and tools around the protocol development, that’s what I do.

14:09
So for listeners who want to learn more about Enzyme or how they might be able to get involved, where should they start?

14:15
So we have our website, which is at enzyme.finance. And then we have our application. If you want to check out the app, just head over straight to app.enzyme.finance. We also have an active Telegram and Discord community which you can reach through Telegram.enzyme.finance or discord.enzyme.finance. And then there’s the GitHub repository at github.com/enzymefinance and also our documentation at userdoc.enzyme.finance

14:44
Are there any exciting initiatives or news coming for members of the Enzyme community that you could share with us at this time?

14:50
At the time of the recording, we actually wrapping up development for the next release of our protocol, the Sulu codename release and we’re going to hand it over to auditors In the next few days and weeks, and we’ll probably release it in late Q3, maybe early Q4.

15:07
So with this upcoming release, then are there any new features or anything that users of Enzyme should keep an eye open for?

15:13
Going forward with the Sulu release, you’ll be able to source the gas cost for any asset management related transaction out of the fund. So you’re not be paying from your own fund manager wallet. We will also add debt positions. We will also add the ability to transfer shares of the vault. So share transferability is a big big feature request that we have had repeatedly in the past. And that’s I think, one of the biggest new additions alongside the gas cost refund out of the vault.

15:43
Exciting. Well, I encourage listeners that want to learn more about Enzyme to visit all the resources and that you’ve provided their links for which are in the show notes.

So Sebastian, I’d like to turn a little bit of our attention now to a discussion of The Graph and how Enzyme uses The Graph. So if you don’t mind, can you tell us when you first became aware of The Graph?

16:03
We first heard about The Graph a couple of months before DEFCON Prague. I think that was 2018, early 2018, if I’m not mistaken, and we ran some experiments, checked out the GitHub repositories. And then at DEFCON in Prague, we actually hosted a dinner for the to-be Melon Council, and also invited Yaniv Tal to that dinner. And Yaniv and I, and also some of my colleagues ended up speaking about The Graph for the entirety of the evening philosophizing about graphql philosophizing about indexing data on the blockchain. And, well, that’s how we really got started. When we came back from DEFCON, we quickly spun up our first subgraph at a hackathon that we hosted. And ever since then, we have been happy and active contributors and participants of The Graph community.

17:03
When you heard Yaniv describe The Graph and you all had discussions about indexing blockchain and this type of a solution. What was your initial impressions? Were you thinking this is something that’s necessary? And this seems like a good solution? Or was it even a new idea or a new way of approaching a problem you’re already trying to solve?

19:03
Yeah, fun fact, I was actually brought on to the Melon protocol as a consultant to solve the data fetching problems around retrieving data from the Ethereum blockchain, because that’s fundamentally what The Graph really solves. And the React application at the time was using a really complicated mixture of Redux and Redux Saga to fulfill all of these really complex data requirements in a predictable manner. And it just turned out to be a really, really, really, really complicated, huge mess that was extremely hard to work with and extremely hard to debug when things went wrong. And so we were looking for alternatives already back then. And me coming from a traditional software development background with web2, React – a lot of React -, a lot of GraphQL development already at the time, so we were already really experienced with React and GraphQL. what we ended up doing was building a GraphQL API in the browser, which might sound weird to more technical users now, that actually abstracted all of the data fetching logic in this GraphQL browser back end, in such a way that the front end would just ask for data through The GraphQL schema, instead of trying to compose these data fetching requests in React directly. So it was a really good fit, because we were already switching over to a GraphQL based solution. And then The Graph was also built around GraphQL interfaces. So it was a really good fit, and I was super excited that this was becoming a thing because even with our solution, data fetching was not easy because of certain data points simply not being available directly on the blockchain, right? Because the blockchain is not as accessible as a database. And then also because some of the data requests that we had to do, you had other data dependencies that had to be loaded upfront, to even figure out what you had to load in the next step. And all of that stuff, all of these problems, just faded with The Graph emerging.

21:16
Well, I think it’s very interesting. And I think listeners will find it interesting too, that you know, you are trying to solve or address the problem that The Graph does. So can you explain in greater detail, what pain points using The Graph instead of trying to do it yourself solves?

21:34
With The Graph, we are indexing the data at the time the data is created. And we can then run logic at write time, rather than running all of this complex computational logic to reshape and reformat the data and also combine data from different data sources together. We can do all of these things already at the time the data is created on the blockchain. So instead of running all of this complex logic every time a user requests data through our application, we are already solving this problem upfront, and then just fetching the data in a pre-optimized shape.

22:13
For listeners that go to some of the websites and resources you listed earlier. Regarding Enzyme, how might they see the way the Enzyme is using The Graph?

22:24
The entire application is built around our subgraph. So everything that you’ll see, literally everything that you will see on the application is served from The Graph, or from a little micro service that that sits on top of The Graph to do a slight amount of further data processing on top. The only place where our application directly reads data from the blockchain is when we present the user with forms for interacting and sending transactions to the blockchain, because that’s the place where we’ll want to have the most, like, the freshest data possible to run validation of the data that they are submitting with the form. So everything on our application, all of the data you see comes from The Graph. And the only thing that doesn’t is the real, live data that we pull directly from the blockchain for form validation.

23:22
You bring up in your answer this concept of a subgraph, and you obviously know how to build subgraphs. And they’re critical to what The Graph does. But not all listeners fully understand what a subgraph is. How would you explain a subgraph to somebody who is non-technical?

23:40
A subgraph is a graphical schema purpose-built for the data requirements of the application that you’re building. And it is backed by a subgraph manifest and logic: code that runs whenever changes occur on the blockchain. So for instance, triggered by calls or events or just fresh blocks on the Ethereum blockchain. And then this logic can take this data, take the event payload, fetch additional information, at this block from the blockchain and index all of this data together and store it in a database that is then made accessible through The GraphQL schema,

24:21
Subgraphs at The Graph are open source, which means you’ve spent the time and effort in writing a subgraph that other people can come along and use, is that correct?

That is absolutely correct.

So I’d be curious to ask someone like yourself, and I’ve never had the chance to ask somebody, but how do you feel about that? I mean, in some ways, in traditional or conventional business, there might be a sense of pride of authorship or proprietary nature of what you’ve created. So why are you so open or willing to let other people use the same subgraph that you wrote?

24:56
So first of all, in my opinion, one of the biggest benefits of GraphQL is that you’re really abstracting and taking away the complexities of data fetching that purpose, building that GraphQL schema, that interface through which you’re pulling information into the application, you’re really purpose building that for the requirements of your particular use case of your front end, right? So our subgraph is built for our requirements. And so it’s a really great fit for us, and the data that we are exposing on that subgraph is also usable by you sure. But it is really, like, shaped in the way that we need it first and foremost, right? So unless you’re building the exact same thing, you might need to actually create your own, maybe derived subgraph, with slightly different schema, maybe even slightly different logic, because you just consume different shapes of data in your application. That is one thing, right? But also, I think it is a way of thinking around application and product development that is born out of fear that making parts of your application open source will allow competitors to also benefit from this and steal your product and release something better. I really strongly believe that our team is just so good at what it does and it’s just not easy to copy us just because of the knowledge and the people that we have that’s really hard to replicate. So we don’t have any fear really, for competition, there’s just much, much more to it when you’re building a product than just code and just the stuff that you put on GitHub.

26:41
Sebastian, one of the reasons I wanted to interview you is you’ve come up several times in prior episodes of the Podcast, Chris Wessels mentioned you. And then my migration special panel also mentioned you. And it all centers around the relationship and interaction they had with you during the first migration when there was a failure in the Enzyme subgraph. And so I’m very fortunate to speak with you directly. What was your experience or perspective of that event?

27:09
First of all, I’d like to say I’m really glad that I got mentioned on your Podcast as part of a disaster recovery process. Then secondly, yeah, I consider the failure of the Enzyme subgraph during this migration phase a net positive event. We learned a lot from it, both the Indexer and the subgraph developers, but also Edge & Node working out a solution for this. Because this is not something that is just going to happen during this mainnet migration. It’s something that we’ll be facing as a community also going forward. Subgraphs can fail, due to several reasons, right? So there might be a problem with the code, right? There might be a problem with the contracts code, there might be a call that is done within the mappings that simply reverts, which was previously not expected, so not accounted for in the code base. So lots of different scenarios in which a subgraph can fail. And there needs to be a process right? And, well, having had such a case during the migration phase was very educational, and, hopefully, also beneficial for the entirety of the community going forward.

28:18
In researching and getting ready for this interview. I’ve done other interviews and spoken with a lot of other guests. And when they talk about the different types of subgraphs. You know, sometimes they talk about the size of a particular subgraph. And other times to talk about the complexity of one in the Enzyme subgraph in terms of complexity gets brought up a little bit. How would you explain what makes the Enzyme subgraph complex?

28:46
The Enzyme subgraph is complex because it has a lot of different data sources. We are observing around 100 different contracts on the Ethereum mainnet, currently with hundreds of events that are tracked on those contracts. And we have a very big GraphQL schema with an extremely large subgraph manifest describing all of these data sources. And with all of these different data structures, and all of these different events, all working with each other and changing over time, the complexity of this grows, right? So the length of the code grows, the complexity just grows with it. That is one thing right? But also, simply because our protocol is backed by a plug in system. At its core, we have plugins for policies, for fees and for adapters. Every time we expand our feature offering. We also expand the number of contracts that we observe and the lines of code that run on our subgraph. So we also have to constantly redeploy the subgraph and deal with data upgrades and data migration.

30:29
How important do you think a solution like The Graph is to the future of DeFi?

30:33
I wouldn’t even answer this just on behalf of DeFi. But application development, web3 application development in general, The Graph has just changed the game. Fundamentally any application this year, and also last year is using The Graph. I don’t know a single one that doesn’t use The Graph and is successful. And that’s simply because The Graph really makes accessing data on the blockchain easier. And I’m not talking about it just makes it more convenient, it makes it possible in the first place. We have witnessed this, right? I’m always hearing the argument that The Graph actually makes it simpler and more performant and more reliable to read data from the blockchain. In some cases, it actually makes it possible in the first place. I remember in the first version of the Melon protocol, we actually built certain contracts in such a way that it was possible for us to query data out of those contracts. And now we have completely changed the way we’re building our smart contracts, such that we do not design our contracts for querying purposes outside of what their requirements are to work with themselves, like, to establish the functionality through, like, their transactions. We are now actually designing them with The Graph in mind. So we are building events into the smart contracts, whenever there’s a state change. Anything that we want to track has an event associated with it directly in the contract. And we do that to make it possible to index this data really efficiently through The Graph. So yes, you could say that we have changed the way we are building our smart contracts because of The Graph. And it has made us 10 times more productive. And it has made certain data structures accessible to us that we previously wouldn’t have, like, we wouldn’t have been able to get that data out of the blockchain at all right? People who are more technically advanced and know how interactions with smart contracts work to query for data know that there are just certain limitations, right? So you cannot really query lists very efficiently, you have to really build the smart contract with these things in mind. And that comes at a cost. And we completely removed that code, we completely removed that dead weight of our smart contracts. Simply because The Graph is now a thing.

33:04
From your perspective as a user of The Graph. What would you share with listeners about the experience of working with members of The Graphs community Indexers? The team at Edge & Node? How would you describe how that experience has been?

33:18
Me and my team, we are active on Discord in The Graphs Discord community. And ever since we joined that place, everyone has been super welcoming. Everyone is extremely knowledgeable and helpful in the support chat. We are also answering support questions on a regular basis. Fun fact, for instance, when I was stuck with a random graph-unrelated Rust question (Rust is a programming language that also The Graph uses), I just randomly reached out to Jannis. And yeah, he just coded it for me, because he writes Rust on a daily basis. It was not related to The Graph at all. Right? So I just want to say that The Graph community is just great. And super active. It is exploding in size. Yeah, and Slimchance has recorded a video together with me and my colleague, Ivan, where we were talking about our experience building our subgraph and all of the quirks and edge cases that we’ve run across. And that’s been split up into two episodes. I think it’s available on YouTube. Yeah, there are some gems in there around performance tuning and around the quirks of AssemblyScript. Some techniques that we use when writing our mappings and yeah, just general tips around building subgraphs. And yeah, so the community is great. The indexes are extremely knowledgeable and also super well organized. That was particularly noticeable during that time we had that incident with the Enzyme subgraph failing. So shout out to everyone on the Indexer Discord channel and also on the weekly meetings. That was just a really great experience. And that’s how open source and decentralized protocol development should work. So yeah, big shout out to everyone. The community is great.

35:10
Sebastian, Thank you so much for your time. I appreciate you explaining not only how the Enzyme uses The Graph, but introducing us more to what Enzyme does. And the great benefit is to the DeFi Community. If people want to learn more about you follow Enzyme and more about the work you’re doing. What’s the best way to do it?

35:28
You can find me on Twitter at twitter.com/thefubhy , and I’m also on Discord under the same name and The Graph community. There’s also the Enzyme community, as I mentioned, at discord.enzyme.finance, you can find me there. And yeah, those are the best places.