DAPPCON 2019: Automated Refinancing with Conditional Transactions - L. Schliesske & H. Orth (Gelato)
DappCon 2019 · August 2019 · 15:23
L. Schliesske and H. Orth of Gelato present automated refinancing through conditional transactions at DappCon 2019. They cover how Gelato's infrastructure lets smart contracts execute automatically when predefined conditions are met, a building block for automating DeFi strategies like collateral refinancing on Ethereum.
Speakers
Topics
From DappCon 2019, hosted by Dappcon Berlin.
Transcript
and today we want to talk to you about how to bring true automation to aetherium and in particular in particular how to level up from the current manual user experience of today's d fabrications a quick intro to the two of us I'm humorousness Lewis we work at gelato and we received funds from the ignosi ecosystem grant program so shout out to kenosis for supporting us and to kind of introduce the problem that we are addressing I would likely I would like to introduce a quick example of a current DFA user experience so you all probably know maker let's say we have a
user he wants to deposit some eath in maker to withdraw some dye and then he goes to sleep knowing okay I hope my position is safe but then as it usually happens the eath price crashes as always and his or her CDP gets liquidated and you will incur quite the hair loss on his position wakes up and thinks a large percentage of my ether is gone and this is this is not so great right and like the applications we have they're amazing like what maker offers you but the user experience is still very manual and we actually lured users in by saying hey we have these autonomous Marc
contracts that you can interact with but they are not really autonomous they are quite lazy actually they're always required as outside impulse to do anything and what the current solution of these defy applications are is that you basically have to manual track the market conditions yourself and look ok every day what is the price what are the interest rates and then you have to assign and submit a transaction by yourself to actually react to these market conditions and wouldn't it be much nicer if someone else could react to these market conditions for you so you don't have to watch your CDP at the time all the time so we have two same example here you deposit some eath you withdraw some dye but this time the user gets into an agreement with another
party let's call this party the executors and says hey if the price of the the price of ether drops below let's say $200 could you please save my position by withdrawing some collateral before I get a Nicola to rise going to uni swap getting some dye instead and wiping on my depth and saving my positions the executor says hey sure but of course you need to pay me otherwise I have no incentive to do so and yeah that would be a much better experience because he won't the user wouldn't incur this 30% haircut so at the end of the day this automation is just paying someone else to do something on your behalf or paying someone else to run a machine and this is what we're all
used to in the web 2.0 you write you have brokerages you've got investment banks and they run some services they react to certain market conditions on your behalf what kind of a theorem enabled us to do if you like a developer or a 10x engineer you can write these scripts yourself you can write what's that track the prices you get some Oracle's and then you can you can conduct some actions for you by yourself but this is not what regular users can do right and but what about we what we could do potentially is do like the eath way or we say hey why don't we crypto economy incentivize and other people to transact on your behalf in the future that wouldn't be nice right it sounds easy but it's actually not that easy because there are some
fundamental problems in a theorem that makes this problem quite difficult first of all the executives if you want to if you want to if you want that someone else execute this transaction on your behalf in the future you need to pay this person right and they always need to make a profit on a transaction otherwise why wouldn't they transact for you the problem here is that gas prices only theorem are quite volatile so what if the transaction cost you a let's say $1 today it won't cost you $1 in 10 days because the gas price might go up and you can't really anticipate it so what this results is that users have to over Cola to rise their prepayments and prepay like three times or four times as
much as they would pay now in order to have some guarantee that someone else is incentivized to execute a transaction on their behalf in the future which leads to another bad incentive from executives because their incentive is always to get mines quite quickly and choose a high gas price and this is basically maximizing the costs of the user which is bad and then there are a couple of other problems for example that the user of course always requires this party to be online so there needs to be an incentive for the executor to remain online if he promised to submit a transactional US behalf and and there's a data availability problem as well where the users best interest is actually to distribute the data or the scientist transaction to as many
executors as possible however this leads to a situation where you have many executors wanting to transact a transaction from a user but only one getting through I'm beginning mine first getting the rewards and the others just through racing conditions colliding with each other incurring some gas costs and not getting anything so this is a really good solution at the moment they're already a couple of approaches that try to address these problems of transacting on the user's behalf one is the centralized approach and one is the decentralized approach sense the right approach is basically and quite a nice user experience users are normally charged society a fixed fee and they get a guarantee from the service saying hey we always execute no
matter what even if we incur a loss because long term we'll make a profit for this from this execution service and and there are no collisions because there's only one executor not running and this is the only one who can execute this transaction so there's no collisions there no problem but of course single point of failure no censorship resistance boo and then you have the decentralized approach which is good because there's no Singapore the ferry there's no censorship resistance because there are many parties involved however it's very manual for the user because the user has to predict the future execution cost so the user as a like you probably don't know about gas but they have to know how much they have to pay in ten days when the gas price might change and then of course if you
have multiple nodes multiple executives potentially executing a transaction you face racing conditions they might collide with each other and then some of them face costs don't get a profit and then they are not really incentivized to do it any longer yeah so and there are some solutions to that like complex con census layers on top of like on the side you know something but these create costs again as well so what we thought would be cool is if we could if you we would be able to combine the best of the two words the good user experience of centralized systems and the benefits of decentralization of the decentralized systems and actually provide kind of like a hybrid approach so what we thought is a cool design goal is for the
user to completely be abstracted from the predictions of gas prices a huge execution cost they just pay a flat fee and that's it they get execution guarantee and they don't need to overpay that much they just need to overpay a little bit and they don't have to worry about spreading their science transaction to a lot of nodes they just have to give it to one person and this prom person will then transaction they behalf and from the executor point of view they should always make a profit they should be always incentivized to take a fair gas price at execution to minimize the cost of the user and there should be this incentivized to neglect execution of transactions that they that they claimed and they should not run into racing conditions they should not
collide with each other so that they don't incur losses and Lewis will walk you through how this would look into detail so in our model we talked about automated trusted DEP interactions and you can think about it as kind of DEP into actions as a service so you have a user that only interacts with a DEP interface and the user basically pays the DEP interface a fixed upfront automation fee and the depth interface uses the fees to pool eath and the user can then activate some triggers to respond to death events basically and the DEP interface will interact with the depth on behalf of the user according to the users automation context the executors are the ones that actually trigger the user step
interactions and however they do so through the gelato core and the core acts as an escrow between interfaces and executives so both of them stake eath on their executives take Ethan order to be incentive aligned in slash able and the interface Dex in order to pay executives and yeah when they trigger the exit the call is forwarded to the interface and the interface then interacts with the depth on the user's behalf as the user pre-specified and then the coop pays out some if to the executives so what we try to do in our approach is to combine good UX with all the benefits of decentralization we think that decentralization is non-negotiable otherwise we wouldn't be
here at Def Con I guess so the user only talks to the depp interface and doesn't need to worry about gas prices gets charged a fixed rate and has a service guarantee from the interface the depp interface stakes on genetic code 2 pays to pay executives and pulls the funds in kind of like an insurance scheme and therefore must charge a profitable fee in the long run and it assigns or users to single executives the core is an escrow between interfaces and executives and requires interfaces to have a balance in order to pay executives and it slashes executives for inactivity or forgets over pricing and executives take on the core to be accountable and
incentivized they get paid by the core if they act honestly and they get slashed if they act act dishonestly and users get assigned to them by the interface so there's no more collisions and raising conditions for them so let's look at an example how this would look like under the hood with the example of refinancing alone so executives would stake on the core and so what interfaces to register themselves and the user would then go to a front-end interface and approve funds to be moved and activates some triggers under which conditions the funds shall be moveable and then the interface means some execution claims on the core and selects an executor for the user when the user event actually happens on the depth so for example and in this case the
interest rate of dydx shoots over the 1 on compound the executor then sends the trigger transaction and forwards the the core forwards the call to the interface the interface does all the solidity smart contract checks like checking on chain dates are verifying that the event actually happened and then if it did happen it triggers Depp interaction 1 withdrawing funds from compound for the user and atomically also depositing them dydx at this point in time the users loan has basically been refinanced for a higher interest rate all automatically the user didn't have to do anything manually and also of course the executor gets their payout from the DEP interface balance so there's a lot more things you
can do with that other than just refinancing loans you could think about limit or us on uni swap this would be the first time that you actually have limit orders on a fully decentralized exchange in a fully decentralized way you could also think about time-based sell orders like we're currently working on with noses for the Dutch X where users can have their cell volume automatically spread across a lot of auctions without having to be there every time in order to send a transaction let's dive a bit deeper into some technical or game theory details here and how do we actually want to incentivize executives who have uptime and to use fair gas prices it's a bit tricky we have users assigned to executives and we have the user trigger event where the executor must then
execute with an above a period so there's an uptime challenge where challenges this can be anyone really can send a transaction and if the executives transaction is not mined within the buffer period the challengers have succeeded improving that the executor was inactive and the executive stay get slashed and redistributed to the challengers however if they don't challenge or if the executives transaction does get mind within the buffer period the executor should get their payout there's also a second game of like a lower gas price where challenges can send a transaction with a lower gas price than the executor used and the idea is that they basically if they get included in a block within the buffer period they've basically proven that the executor could have used a
lower gas price therefore they get the executor gets slashed and the state gets to reduce tribute to the challengers however if they do not get included within the buffer period they haven't proven anything so exactly the executor basically use the correct gas price and gets a payout should be a reminder that all of this is just like to incentivize executives to act honestly and it should always be like shouldn't always be used so the system is still not perfect of obviously we haven't even deployed all the smart contracts yet the sort of research core ongoing and testing however the the benefits are really that gas price volatility gets completely abstracted from users interfaces are incentivized to calculate a fair fee because they kind of compete in an open
market executives always make a profit so they can always run their note for automation and there's no racing conditions collisions for them and the downside is that Shelley's challenges can kind of try to grieve assigned executives we kind of assume that - rationally and prefer higher gas prices and executives could also lose some of their stake because - ik maliciously kind of like censoring them and interface might also go bankrupt which would mean that a user doesn't get their triggers executed anymore and some users also overpay for the underpayment of other users Charlotte also - with human arm clock the meter transaction group and the gas station network they inspired us in many places and a big
shout-out to kenosis and the gecko fund i think everyone that wants to build something should look into this we've gotten a grant from them and this really has helped us a lot in development thank you very much for listening if you would want to build an interface on gelato here are some steps you can take to do so at the moment it's not live so but soon it will be basically you just choose a Deb you want to interact with you define some Deb into action triggers configurable to you users you use our standard you register on the core by staking some if you accept your user requests through a front-end and charge users according to a business model users don't need crypto they can use paypal you keep your balance on the core above 0.5 eighth and then the pay-as-you-go for the execution service
is Hana budget lots of core and now you basically have access for users to automatic triggers that will be executed by a decentralized set of nodes yeah that's it [Applause]