Aave Labs 🛠️ Building Applications with GHO
ETHGlobal·Wed, Oct 9, 2024, 12:00 AM
Join Andrew Schmidt from Aave Labs for a workshop titled, “Building Applications with GHO.” This workshop will help you learn about features and opportunities to build projects with GHO for each of the LFGHO prize tracks. With a week of open learning, hacking, and workshops on all things stablecoin, as well as $75,000+ USD in prizes, LFGHO is a great way to connect with the community from around the world, and help shape the future of Ethereum and DeFi! ----------------- Follow us: https://x.com/ETHGlobal?s=20 Check us out: https://ethglobal.com/ Email us at: hello@ethglobal.com
Transcript
[Music] hello everyone and welcome to the LFO a Labs Workshop building applications with go joining us today is Andrew Schmidt who will be taking us through this session and with that I'll pass over to Andrew to get the session started hey thanks for the introduction yeah my name is Andrew schmidtz um online to go by defi Spartan um so yeah this Workshop is going to be about building applications with go we're just going to go through some highle details about go the different mechanics about how it works and then really dive into the tracks for the hackathon for LF goo um talk about what the different tracks are some different ideas and resources so what is go at a high level go is a decentralized stable coin native to the a protocol so what this means is that the go stable coin is governed by the same Dow which governs the a protocol uh and the other way that the the that go is native to the a protocol is that when the go token was launched the first facilitator for go which we'll get into exactly what that terminology means in a bit uh but the a protocol is actually the first way that the go token is able to be minted and burned and this occurs seamlessly through the very same methods which the a protocol currently operates so what is the a protocol um I'm sure a lot of people are probably familiar but at a high level there's kind of three main groups uh within the OB protocol ecosystem so you have suppliers um these are users who are providing liquidity and then receiving a tokenized representation called a tokens uh these tokens are used to earn yield and used as collateral and where that yield comes from is from users uh who are borrowing so borrowing is drawing liquidity based on Dow control parameters and collateralization um so what this means is that the Dow sets parameters for specific reserves um which basically says the conditions in which a uh position is deemed to be over collateralized so each asset might have different risk parameters um and these can be determined based on the liquidity of the reserve um different factors such as price volatility um there's a lot of different U methodology that goes into selecting risk parameters um there are even specific teams dedicated to essentially fine-tuning these parameters uh but the co-existence between suppliers and borrowers uh is really the core of the a protocol and then you have this this third group called Liquidators um who essentially maintain the overcollateralization of the system uh by responding to these risk parameters so if a borrower has a position which is under the minimum collateralization uh which is specified by these parameters um then a an a liquidator can come in and repay a portion of that borrow position and then redeem a corresponding amount of collateral plus a premium and this premium exists in order to actually incentivize that this liquidation always occurs as soon as it's able to be executed so how exactly does go interact with the a protocol um so this is just a small solidity snippet on the left you can see this is the typical uh a code for essentially borrowing an asset so the pool contract is the main entry point for the a protocol and this is for regular assets and for go so you call the borrow function and you're passing in essentially just the address of the token the amount the interest rate mode which for the go token um is always is going to be what's called a variable rate so we'll get exactly into how exactly that rate is determined for go but at a high level essentially what this slide is trying to show is that um interacting with like minting go through the a protocol uh is essentially a seamless operation you don't have to call a different function interact with a different contract uh it happens the exact same way that a typical interaction would with the a protocol so how are the rates determined um so if I want to borrow a token from the a protocol uh I'm going to be paying a certain interest rate and that interest rate could either be a variable rate which is changing dynamically uh or a stable rate which is essentially uh selecting a single rate uh at a at a point in time and then essentially keeping that rate uh constant until certain rebalance conditions might be met so the vast majority of liquidity within the Obby protocol is borrowed what's called a variable rate and that is what's represented inside of this graph here so essentially oh I I'm missing my axes here but essentially this bottom axis here is uh the utilization so this is essentially the ratio of the amount that has been supplied to the amount that is borrowed um so say there is 100 tokens in a pool and 50 of those are borrowed that would represent a utilization rate of 50% and then on this left axis here this is actually the borrow rate which is being incurred by by The Reserve so if you take this graph as an example say at a a utilization rate of 52% uh this borrow this Reserve might be um 53.6% this Reserve might have a 5% interest rate and then it uh ticks up as the utilization increases and this entire curve here is actually defined by parameters so these parameters are what a governance is deciding basically what is the minimum interest rate what is the optimal ratio um this optimal ratio is designed so that you want to basically select an optimal rate so that um users are incentivized to borrow so that there is yield coming to suppliers but you don't want this optimal utilization ratio to be so high that people are not able to withdraw and access their liquidity from supplying so go Works a little bit differently than this curve uh for one simple reason and that's that go is minted not supplied so with a typical Reserve asset say like wrapped ethereum um if I am a user and I Supply that token and another user comes in and wants to borrow that token they're actually borrowing that underlying token from the user that supplied uh go Works a bit differently and that go liquidity is not actually supplied to the protocol it's actually minted and in a little bit we're actually going to see the exact lines of code which actually execute this minting um and the B rate is instead of being defined by a curve it's determined directly through a governance and there's also this additional parameter called the discount mechanism and so all of the parameters for go kind of coales inside of this table here um and all of these like like I mentioned above are determined through Obby Community governance so there's essentially parameters which determine how much of a discount you were able to receive what will that discount be and also the kind of tiering of the rate so what what will the rate start at and what will the rate be with a maximum amount of the discount and a really good way to understand this is to check out um app. a.com and click on the actual go Reserve page and there's this really nice calculator uh which lets you see essenti based on the amount of go that is borrowed and also the amount of staked a so actually to backtrack a bit the discount mechanism for go is based on the staked a token so staked a represents the a token uh staked inside of the a protocol safety module um there's a lot of documentation inside AI docs about what exactly the safety module is um you know what is the difference between Stak a and a but essentially for for go uh you can just think of the Stak a token is basically a wrapped form of the a token and if you hold this token inside of your wallet you are eligible to borrow go at a discounted rate so you can see that essentially in this graphic that the base borrow rate for go is 6.42% and for every one Stak a that your wallet holds you're able to borrow 100 go at this discounted rate of 4.
49% and so essentially as you change the amount of go that's borrowed and the amount of Obby that is Stak you can you can see um you know what percentage of that borrow rate will be discounted versus the percentage that won't and so now we'll get into stability mechanisms so go is a stable coin and really I kind of break this down into two different forms of stability um the first is collateralization so the collateralization of go is handled through facilitators and uh facilitators are essentially the addresses which are able to Mint and burn go and at the launch of go there are two of these facilitators the a facilitator and the Flashman so the a facilitator is the a protocol which we went through earlier in the presentation where you're supplying where users supplying tokens and then able to borrow go against this and essentially how the collateralization works in the a protocol is that the go Oracle actually has a fixed price of one USD and what this means is that at any point no matter what collateral asset you've supplied what the price of that collateral asset is if you'll be able to Mint go against this asset at a value of one USD so if I Supply 100 USD worth of some collateral and that collateral asset has a um a maximum borrow ratio of say 80% it means that no matter what the open market price of go is I'm always able to borrow 80 go against that in in that particular scenario and similarly for liquidations um the Threshold at which a go borrow position is able to be liquidated is determined uh by this fixed price of 1 USD um but this is very different than saying that the price of the go token is fixed to 1 USD and this is where we get into kind of the minting and Red Redemption value so the collateralization aspect of go uh having the price fixed to one USD what this means is that within the context of the a protocol that go should always be over collateralized by one USD so for every one go that is borrowed there should always be one USD worth of collateral that is backing go no matter if go is trading above or below that Peg and so the minting and Redemption value this is essentially the price which you are actually able to um take these go tokens and use them in some other context and really the ways that kind of go maintains its stability uh with respect to this minting and Redemption uh is kind of a triage of things so you have interest rate management you know the if the interest rate is lower people are incentivized mint go if the interest rate is higher people are more incentivized to essentially close these borrow positions and obtain go to do that uh and then you also have other factors such as exchange liquidity um so obviously even if the go token um theoretically could be worth any amount you actually have to be able to realize the amount you have to be able to essentially convert some token into another token and having a liquidity on exchanges particularly on decentralized exchanges um which are actually doing these actions on change uh is very important to actually have a stable minting and Redemption value and the a protocol actually or the a dow actually has essentially a committee which has been been approved to kind of formulate strategies um because the the world of exchange liquidity is actually very complex and there's a lot of different mechanisms that can be put in place to essentially incentivize or disincentivize certain actions to kind of maintain this fixed value and then lastly is a peg stability facilitator um so this essentially would be a new facilitator for the protocol which would allow kind of fixed transfers so the ability to essentially take one of another token say a different stable coin and redeem it one to one directly to another go token uh and this is something which is not currently live but has been proposed to the a governance Forum uh and actually just recently has gone to a snapshot vote so to dive into the LFO hackathon there's four prize tracks uh the three main ones are payments vaults and facilitators and then there's this General prize track for Integrations um which is a much more open track it could apply to projects within any of these three tracks or things which are not included in them uh and obviously you can see the prize amounts here so diving into payments uh I kind of break this into three different tiers so the first tier that I'll go through is kind of just simple go transfer so this is basically just utilizing the functionality of the go token U so go is an erc20 token this is the standard ethereum token type uh and essentially allows you to transfer tokens from one address to another uh and basically the mechanism by which you're transferring these tokens is by calling functions on the actual go contract um there's one other tidbit here which is that the go token supports EIP 2612 permit uh which allows for signature-based approval so instead of a user having to submit a transaction on chain to approve the tokens they can sign a message and then somebody else or any other uh address on that Network can take this signature and then call a function called permit and this performs the same action as the approval it's just that it does not have to be executed by the end user um and this can provide some really really good user experience uh because the US the end user may not actually have to submit a transaction they may just have to sign a message and then the actual transaction is performed behind the scenes the next type of um action which we're getting into more practical use cases so these are um payments which are actually utilizing other tokens and potentially other networks so there are a lot of different applications uh for payments inside of web 3 a lot of things which you might want to use tokens for and a lot of them uh mainly due to kind of the fact that the go token is new and also that you know different types of applications might require different types of tokens for payments so go might not directly be usable for a payment but if you're able to switch the go token into any other token on any other network essentially you can utilize go for payments in that context and so that's like here starting with go and the end result would be interacting with any token on any chain that's kind of the idealized version of of a payment application and then lastly you have facilitator integration um so this is one way in which go is very unique uh and also um is a very very powerful tool for payments which is that the a facilitator enables users to supply collateral and borrow go against it and you can basically utilize this functionality in order to allow users to use their collateral as a form of payments without actually having to sell or um liquidate that collateral so you might say Supply ethereum and uh you you might want to use that ethereum for payments but what you could do is supply ethereum borrow go and then do this option to which is basically switching that borrowed go token into ethereum so now you're maintaining 100% of your exposure to ethereum while still utilizing the go token to actually do the payments that you want to do with that ethereum uh and lastly credit delegation um so this is a really really powerful feature of the a protocol um it allows you to take the borrowing power for your collateral and delegate it to another address so I might take um say I have one ethereum supplied and I I have the ability to borrow say 1,000 go against this but maybe I want to delegate that to someone else so that this entity now has the ability to borrow that go that entity could be a person it could be a group or it could be a system of smart contracts which in my opinion is the most um uh most powerful because essentially you could build any type of um scaffolded interaction so you can have really fine-tune controls over the risk uh and also have verifiability to see that oh this smart contract used this amount of credit this smart contract has this amount of credit available uh and when you kind of combine all three of these you end up with a very very potential powerful system for payments and lastly you have this question of how exactly does a user interact and so for the hackathon there's kind of two ways that uh you might consider approaching this one would be an application either a web application or a mobile application um which essentially provides kind of that experience and the second would be an SDK or a widget so basically something that could be embedded into other applications um and an SDK is actually quite a powerful tool and I I would definitely suggest if you're looking into the payments track to consider uh potentially exposing whatever you build as an SDK or widget uh because if you have a dedicated application essentially you might only be able to do payments through that application and it might be a very limited scope whereas if you expose something as sort of a library or something that can be embedded um you might be able to enable a whole lot more payments by allowing it to be integrated into a lot of different experiences um this is not to kind of restrict your ideas it's mainly just to kind of highlight that um you know you have these options available uh and then the next well actually to stick on this uh slide for a second I highly encourage you guys to check out a docs.google.com sorry I have a zoom uh have a zoom window open on me sorry I'm not able to switch that right now but if you go to docs.google.com or these other prize tracks into your applications um so the next one is go or vaults so this is any smart contract interation with go that defines the allocation amongst users groups or protocols so this is kind of a wordy explanation but essentially what this is trying to get is that a vault is essentially a smart contract which defines the rules for who what where and how these go tokens are actually able to be utilized and just a couple examples of potential vaults that could be built um starting with ER C 4626 um so this essentially is a smart contract vault which is tokenized so it's a way to basically represent a position within a vault by holding a token uh and having you know very clear rules within the smart contract Vault about what that ownership is uh there's also a credit delegation Vault so credit delegation the feature that I mentioned on the previous slide you can also utilize within smart contract infrastructure to Define very very uh unique agreements so say I have a go inside of my wallet I might be able to delegate that go to a Smart contract and then that smart contract then decides how to allocate that uh it might have a system of pre-built strategies um it might have uh or sort of a community governance aspect where a community decides how those tokens are allocated uh really the possibilities are endless because you can delegate credit to any ethereum smart contract so any logic you can write in a contract um you can execute through AED delegation Vault um sort of on this topic you could also collateralize different types of reserves so things like nfts or different types of tokens which you might not be able to use as collateral in the a protocol um you could build basically a custom Vault to kind of facilitate that borrowing um and then lastly kind of Treasury management so this is mainly not with respect to the a treasury but kind of Treasury management for a specific team or group um who might want to utilize the flexibility of the a protocol to kind of have their tokens supplied as collateral and then sort of utilize go as sort of this streaming mechanism to sort of perform the day-to-day operations that they might want to do and lastly we have facilitators for the core prize tracks so the go token contract is laid out in a very simple way that essentially you have addresses which are deemed facilitators that have a capacity and a level so the capacity is the amount of go they're able to borrow the level is the amount of go that they have borrowed or sorry not borrowed but minted uh within the a facilitator this is borrowing but there's also this flash mint facilitator so flash Min is similar to the a protocol functionality of flash loan where essentially you're able to borrow a specified amount of go tokens with the condition that those tokens are returned within a single transaction um and this is really powerful for things like um entering positions which might require multiple transactions so say instead of having to do Supply borrow Supply borrow you could essentially take that entire borrow amount in one transaction do something with it and then repay those tokens at the end of the transaction and then kind of the the this is the cut off where essentially go is today that the a facilitator and the Flash Min facilitator comprise the the mechanisms to Mint the go token today but these these can be extended through a governance to essentially allow um new types of facilitators to be brought to the market so the ghost module that I mentioned earlier is the facilitator that is kind of closest I would say that it's it's gone through sort of the early stages of the governance process um and essentially these could be extended to be any type of facilitator so for the price track the facilitator track is to design a new facilitator that can be proposed to the a DA and kind of the features I want to highlight here are um number one that facilitators are approved through a governance um which means that there's kind of a a high bar to essentially get a facilitator to Market and that's something that should be mindful of within hackathon projects is that uh definitely the feasibility of a facilitator is going to be something that's very important um something that maintains sort of levels of decentralization that maintains collateralization and probably most importantly provides some sort of utility to the AOW so when the a is kind of weighing these decisions they kind of have to weigh this risk reward of do we want to basically allow this facilitator to Mint go and use this sort of new mechanism for allowing go to be minted versus the benefit to basically enabling new users to use this facilitator um and so there are a lot of different types of facilitators that you could potentially create um uh the go docs.
google.com uh just because the a Dao governance and a protocol operate entirely through smart contracts and so if you're able to define basically a really robust system of having collateral inmart contracts or interacting with existing smart contracts like existing defi protocols um such as decentralized exchanges um sort of other protocols similar to a you could basically utilize these existing very secure pieces of code uh and leverage sort of their security and their collateralization to kind of make your facilitator more robust and decentralized and lastly the Integrations prize check is sort of a general purpose track to integrate go token in any type of application this does not even necessarily need to be a web application or a mobile application um these could be just unique projects which provide some utility to the go ecosystem um things like developer tooling or data analysis um or wallet insights with something like metamask snaps um these would all be things that would qualif uh because this track is mainly meant to be just sort of a general framework for um you know incentivizing applications to be built which might be creative things uh but may not fall within the other prize tracks or they could be things within the priz track the other prize tracks um but maybe they have sort of a a more Niche use case that maybe it's a type of payment application uh but it's really mainly meant to be um something focused on data analysis or U getting further insights to user um so these would be the types of things that would kind of fall under this Integrations track um lastly we have resources um so I would highly recommend checking out this link tree site um here we list all of the different documentations sdks uh contract Registries anything you need to kind of get started building with go um and that is actually the end of the presentation so I'll leave it here and looks like we have do we have some questions in the chat uh let me check I don't don't think there were any questions but yeah if anybody has any questions you know we've got some time feel free to take yourself off mute and ask or just type uh your questions in the chat I guess as we wait for those to come in do this and highlight just this one one other cool thing that I wanted to show earlier uh which is that you might be familiar with kind of ethers scan. is kind of a tool to to investigate smart contracts uh but there's this other really cool thing that you can do which is that if you take any block explorer link it could be ether scan or a different block Explorer and just replace doio with this d.net I'll put it in the chat too um this actually lets you view the verified source code through a block Explorer um so this is a really really neat tool to kind of dive into you know actually looking at the source code of how uh different smart contracts work um so this is actually the go token smart contract as you can see it's a total of 130 lines um so it's very compact but very powerful and it has to do with this sort of facilitator infrastructure where I'll highlight basically this mint function this function right here is where um every go token is originated from so a facilitator address calls this mint function and then essentially this contract delegates that call to that facilitator and says okay facilitator you're able to Mint this go token and now you're able to perform you know the operation which your facilitator does um so I think this is a really cool contract to read through to kind of understand at a high level how the go token was designed especially if you're looking at the facilitator track oh looks like we have some question now could you elaborate ERC 4626 tokenized Vault versus treasury Vault difference a little bit more um so actually there's a lot of overlap between those two things oh the second thing and could a project both be present as a facilitator and a vault in terms of a prize um so to answer one at a time uh there's actually a lot of crossover between the 4626 Vault and a treasury Vault essentially you could utilize ERC 4626 to build a treasury Vault so I'd say 4626 is kind of the Primitive it's like the type of Vault that you're building whereas treasury is the actual kind of implementation like what you're using that Vault for um so yeah definitely kind of not not mutually exclusive things they they can kind of exist together um and a project that could be a facilitator and a vault uh this is also definitely something that could kind of be combined together where so a facilitator is a smart contract which basically is calling this mint function on the go token and so if you have a vault which essentially defines some sort of ownership maybe it says um you know maybe it's a multi- signature contract and it says you know I need five of seven signers to execute something um this could definitely serve as a type of facilitator um and if you think about um kind of different types of facilitators especially if your facilitator is doing something with offchain collateral where you're sort of utilizing some sort of Oracle um you can kind of think of this as a vault or sort of a smart contract which is defining essentially you know what article or under what conditions the go facilitator would actually be able to Mint the token so definitely I'd say that yes the project could be of both a facilitator and a vault says do a deposited token support permit if not any other that come to mind so yes actually every single a token within the a protocol V3 um has support for permit so this means that if you hold a tokens in your wallet the example you gave a wrapped ethereum um you're able to sign a message the same way that you are with the go token and actually transfer that underlying collateral um so yes yes that is definitely um something that you can utilize within your projects is permit for a tokens then have another question what if like maker Dow we create Peg based on stable coins like usdc usdt or even die to M go um Peg stable HS so I think this is actually very similar um to the go stability module so if you're familiar with maker Dow they have this concept of the peg stability module and the g stability module is essentially just a an implementation of the same Peg stability idea so I think if I understand the question right uh the ghost stability module kind of serves this purpose where essentially you're able to Mint go one to one against other tokens that would be approved so say the ghost ghost stability facilitator is live and the a governance um you know allows a certain credit line for certain tokens like usdc usdt die um in that case then you would be able to Mint go directly against those tokens so it works very similar to that um maker out Peg stability facilitator it's awesome with that looks like I don't see any more questions than we seem to be at time yeah yeah so definitely a great presentation Andrew really appreciate it and everybody else thank you all for attending um and I think we have just one more uh Workshop later today and then also the second team formation session that Andrew will also be joining with us so if you're you know so stuck on what to what to do in terms of ideas or looking for a team definitely you know come come attend that and Andrew would be a as such just a plethora of resources and information to to help you all out um yeah thanks again Andrew for the great [Music] presentation
Automatic transcript — names and jargon may be misspelled.