PowerPool X Spaces AMA with Gearbox — August 29, 2023

PowerPool and Gearbox Protocol have completed their joint Community Call AMA where they discussed the potential application of PowerPagent v2 in Gearbox’s automated products.

If you missed the call, we’ve prepared this Recap article!

Spaces recording: https://twitter.com/i/spaces/1nAKErgeYbnGL

Speakers:

PowerPool:

Gordon Gekko: @gordongekko_CVP

Vasily Sumanov: @vasilysumanov

Gearbox:

Atlas: @ivangbi

Elias: @mugglesect

Recap:

Gordon-Powerpool: Welcome, everybody, to this AMA hosted by PowerPool, operators and developers of the PowerAgent Automation Network. Today’s guest will be Gearbox, an asset management protocol and a major user of automation services. The format is AMA, so you’ll be able to learn a lot more about what automation networks are, what they do, and what the users of automation services are looking for from their automation networks. Many of you probably don’t even know that you have already been using automation. You just use your protocol and you’re not 100% aware of what goes on in the background. To give you some background, distributed ledgers and scaling layers, L1’s & L2’s, only keep track of transactions, but they don’t actually execute transactions on their own. So most protocols must rely on automation services, either their own ‘home-rolled’ keeper bots or ideally decentralized autonomous networks like PowerAgent to provide automation and offline computation. It is increasingly clear that the complexities of managing DeFi are such that automation is increasingly required. Most DeFi protocols are moving in the direction of architectures and designs that are very, very difficult to manage manually on your own. As a result, there’s a lot of innovation right now amongst primary protocols supplying primitives, developers of services on primitives, and the automation networks Like PowerAgent increasingly required to support them. This session is intended to help you understand these trends, what’s happening in DeFi, and especially what’s happening in DeFi automation.

First, I’d like to introduce Vasily, who’s Head of Research for PowerPool. He can give more background on exactly where the PowerAgent Automation Network is on our Roadmap. We are very, very close to launching perhaps initially on Gnosis Chain because we can do a lot of intensive testing at a lower transaction cost. But the Ethereum mainnet launch is coming, very soon™. So we are in heavy discussions with a lot of DeFi protocols about integrating all the new capabilities, explaining the new V. 2 architecture and resulting advantages of PowerAgent v. 2. So with that, I’ll just let Vasily bring you all up to date on PowerAgent.

About PowerPool/PowerAgent v2

Vasily-PowerPool: Thank you, Gordon, for the introduction. We are not far away from the launch of PowerAgent on Gnosis Chain. So let me introduce the PowerAgent Automation Network shortly for our listeners. PowerAgent is a decentralized autonomous automation network. Its main features include that it is both decentralized and permissionless, so anyone can run a Keeper node, stake $CVP tokens, earn fees by participating in transaction signing, and also earn some of the proceeds from verifying the successful executions by other Keepers. The PowerAgent network allows Job Owners to automatically select Keepers randomly, and Keepers can slash each other in case of their misbehavior, for example, the non-execution of transactions. Regarding random Keeper selection, we use the Ethereum consensus as a source of randomness. Gnosis Chain has the same implementation of the Ethereum consensus, so it’s quite a good chain for us to launch a very close clone of the mainnet version. Gnosis Chain transaction costs are quite cheap compared with Ethereum mainnet, so we will be doing very intensive live testing of complex jobs, especially those subject to gas cost abuse first on Gnosis Chain, in preference to doing all this final testing on the much more costly Ethereum mainnet.

The PowerAgent Network supports several types of tasks. We have basic interval tasks where Job Owners can set up a Job to call some contract every time interval, for example, every 12 hours, 4 hours, or any other time period. These Jobs can be with some predefined calldata, or a simple contract call. We also have more advanced types of Jobs — Resolver type of Jobs. Job Owners can define on-chain conditions for each Job, such as when it should be executed, what are the conditions to automatically execute the code, etc. The contract’s calldata can also be generated through the estimation of this execution. Resolver Jobs is a much more complicated type of Job that requires a lot of testing because there can be really complex algorithms inside. It is possible for Job Owners to mis-specify Resolver Jobs that cannot be completed, and result in slashing of Keepers. We are talking about a permissionless space, so preventing abuse is a big area for analysis and testing. This is why I think the Gnosis Chain test launch is quite a good way to do all of this complex Job execution hardening without spending too much on gas.

We consider that there are basically two types of job owner client projects. The first type of projects are projects that have a demand for automation for their own design. You could have a project designed from the outset with automation under the hood fulfilling requirements for the product operation. The second type of prospective job owner projects, much more widespread, are projects building on top of other projects, requiring some automated actions. This would include generalized leveraged farming and asset management protocols like Gearbox. It could be some projects like vaults, liquidation protection for CDP, etc. Any project that builds on top of other projects and needs some automated services is definitely a good match for PowerAgent. So with that, I will invite Gearbox on stage to share some insights about their protocol, their automation requirements, and what types of tasks they have.

About Gearbox

Elias-Gearbox: Hello, yes, nice to meet you. Thank you for inviting us. My name is Elias. I’m the Gearbox member responsible for product side business. So I’d love to discuss my opinions on how automation and optimization tools can be used inside Gearbox. And what kinds of issues it can help solve for our protocol. So, yeah. We’re happy to be here.

Atlas-Gearbox: Hi, I’m Atlas. I’m on the marketing side at Gearbox. Uh, mainly do memes. Gearbox is a composable leverage protocol. The idea is we eventually want to be the leverage layer for all of Defi. We’re not there yet, but, you know, every day closer, hopefully. Especially if Defi TVL shrinks to nothing, then we can be the leverage layer for a few remaining protocols and become the leverage layer for all of Defi because Defi TVL has gone to zero! Uh, I’ll leave the technical stuff for Elias, but uh, thanks for having us. And I’m excited to talk about automation and everything else.

Vasily-PowerPool: How should we proceed? Could you share some insights about Gearbox and your automation task requirements?

Atlas-Gearbox: Yeah, let’s start from the beginning, with a high-level overview of Gearbox’s technical design. Gearbox is a two-sided marketplace. One side is for passive returns seekers who just provide passive capital and want to get some passive yields in return. The interesting part is the other side which we call the Credit Account. It’s a special primitive that actually helps to get leverage which can later be applied to any DeFi protocol. So depending on integration, it could be leverage trading, leveraged funding, leveraged staking, actually different kinds of stuff.

A lot of interesting use cases arise in terms of automation. First of all, whenever you have leverage, it’s a risky position. So you as a user want to have some tools to avoid liquidation. This is one of the dimensions where automation could be very helpful (because nobody wants to be wrecked), given that our markets are pretty volatile. But it’s hard to be online 24/7. So when you sleep, some bad news comes and everyone is wrecked and you end up liquidated to zero at the end. To avoid this, it’s very beneficial to have some automation that actually could act on your behalf. Here in Gearbox, we are implementing what we call these bots. It is a special infrastructure where you can delegate different roles, and different rights to various separate wallets or separate smart contracts. So as a result, you can delegate some rights to manage your credit account and close positions or move some assets to less risky positions to avoid liquidation.

Yes, liquidation management is one interesting topic. Another one of the interesting use cases, which we already discussed, is copy-trading. A lot of people just want to have some follow-up strategies, maybe following some other big names. All transactions are visible and copy-trading is easy to implement because everything on-chain is visible and transparent. But it can become very difficult to implement if you don’t want to give your private keys to somebody else. But it becomes much easier if you can delegate some rights to do some specific operations on your behalf and you can actually specify what exactly the terms should be of these operations. It’s similar to how Binance and some other CEXs actually manage their API keys. You can create API keys that have no rights to deposit or withdraw funds, but actually, they may have rights to swap on different assets that are listed on Binance. So this is like the same logic that could be very, very interesting stuff for users to implement different copy-trading strategies on Gearbox with some other specific strategies to rebalance.

Vasily-PowerPool: What do you think about copy-trading strategies? I think maybe they have to have some algorithms off-chain, right? Not open source, or do you think it is okay if it will be open source, the entire strategy?

Atlas-Gearbox: It depends on the exact design. In Gearbox, we don’t think a lot about what kind of strategy should be implemented. We are actually thinking more about some magic black box with leverage so you can put your money, get leverage, and then use any kind of different strategies or tooling that other smart guys implement. So of course, it could be some off-chain logic. On-chain everything is like, what’s checked is some invariant here. So for example you could give exact rights to swap only Ethereum. So users can trade in any kind of different assets. But inside these two assets, actually, this bot which is connected to a credit account can implement different strategies and, of course, opens some possible attack vectors. Because if it trades at some bad prices, you can actually lose money. So another option here, is where you can put some limitations for trades that should be implemented on-chain. So it could be some checks with, I don’t know, comparison checking prices or something like that. So this kind of logic could be on-chain, and some other parts could be moved off-chain. So it’s an option for users. It depends on what kind of strategies are interesting for users, and what kind of risks are acceptable for them. So for us, we are addressing all of these questions to the user and he can decide what’s good for him. So for example, for us, one of the possible strategies is, for example, you can delegate rights to trade on a specific address.

This address could be some hot wallet. So for example, you can open a credit account using your Ledger wallet. So it’s very safe. But using just a Ledger, you have to have it all the time with you. So it’s like you open it, but then you can forget about your Ledger. You can delegate your rights to trade to some specific hot wallet, the private keys that you keep on your iPhone, and voila, you can trade using your iPhone. But actually, all the risks that you have are if your private key is leaked from your iPhone. It’s not possible to just withdraw money from your credit account. So it’s still safe for you to have such a kind of infrastructure to give money to trading and so on. So yeah, that would be one of the options. Yeah. But this option, I guess, is not very interesting to discuss because it doesn’t use automation. But in terms of automation, as I said, the user should decide what kind of risk is acceptable for him. Of course, the more you put on-chain, as it’s safer here, but the outcome here is that it shouldn’t be full on-chain as it’s more difficult to trade, and not so agile. Yeah, and for example, if some meme coin arises on the horizon, you can just change this smart contract that keeps all invariants for your credit account. So for such a case, I guess you’ll lose this opportunity to make money, as having less invariant on-chain allows you more flexibility but also goes with more possible attack vectors for your funds.

Vasily-PowerPool: So basically, you have two general tasks for automation. The first one is protection from liquidation, to make for a safer experience while using Gearbox. And the second is a variety of copy-trading strategies, which are also quite interesting. So, at this moment, do you have an implementation for it ready? Do you already have tasks for the bots that you use? Is this already operating or just an idea?

Atlas-Gearbox: No, it’s not just an idea. It’s going to launch with Gearbox V3 which is planned for October. It’s written in code but not deployed yet. An audit is ongoing.

Vasily-PowerPool: Gearbox operates on your Ethereum, right? Will you launch on the Ethereum mainnet so we can make some sample tasks to check out? For example, not an open product for everyone, but just for testing, we can make some task implementations to see how it works, right? Check it out for one particular credit account, just to see how it will protect from liquidation or how it will do copy-trading. Do you have any particular requirements or some strategy for liquidation protection, for example, some algorithms? Or if the Ethereum price goes down to a spot where you need to burn some debt. What are the conditions for execution? For example, once you get a signal that you need to start burning part of the debt, what time do you have in your models to make the execution? In a safe mode, is it 10 blocks, 100 blocks, maybe it’s in minutes, or in seconds? Do you have some information about that?

Atlas-Gearbox: Uh, yeah. A good question, actually. So in terms of how it should work in Gearbox, to calculate the health of your debt position, we use a metric called a health factor. Health factor represents the over-collateralization of your credit account. So if your health factor is more than one, you’re safe. If it falls below one, then your account becomes available for liquidation by anyone. So to build liquidation protection, I guess, all you need to do is to check this health factor. I don’t know what exactly should be designed from a product perspective. Maybe there should be some optionality for users where they can decide what kind of health factor level is acceptable for them. For some, I guess, 1.01 is fine, for some other users it can be 1.05. So I guess each user can decide, depending on his risk appetite. So all you need is to check this health factor and compare it with the target value. And if the health factor drops below the target value, you should swap positions to some underlying token which is debt-nominated. And actually, that’s it. So I guess from the automation side, it’s all you need. Yeah. So if you swap the underlying asset you can’t be liquidated. Maybe from the product side, it’s good to have some notification here, but it’s not an on-chain operation. So I guess it could be interesting to have some integration with a telegram bot or some push notification services like EPNS to notify users that okay, there is a risk event, your credit account was moved to an unliquidated option. Here, you can come back to the application, check it, and choose what you should do next. I guess that’s it. At least how I see it, to start with. Yeah, I guess there could be more sophisticated stuff. But for an initial product, I guess it’s a good MVP to start with.

Vasily-PowerPool: Yeah, I think as well that MEV protection is quite important. So what about the trading strategy? I think that it also requires some MEV protection solution integration because you know, in the current account only you can interact with the credit account, right? So nobody can front-run you or, you know, make some bad things on-chain. But for trading, it’s not the same. So some MEV protection also should be used from the Keeper side of PowerAgent. I think it’s also important. Yeah, Gordon, maybe you have something to add? For me, it’s pretty clear, that we have two general use cases for automation from Gearbox and both of them are potentially quite valuable for users. So I think that also this trading strategy can be made by zkResolvers. Making it off-chain without sharing the algorithm on-chain, is also quite a valuable thing in the future. It’s not developed yet. This is a zkResolver thing, it’s planned for the future of PowerAgent. But yeah, talking about testing the automation capabilities of PowerAgent with Gearbox, I think that starting with liquidation protection is a much easier task. I understand where to start with the trading. So Gordon, could you add something, maybe some ideas on how to proceed with the discussion?

Possible legal issues in the automation market

Gordon-PowerPool: Thanks. If we look at what is happening right now in the development of Defi and crypto, we see the issues of regulation coming up. And particularly in the US right now, there are all sorts of crazy draft rules, court cases, and a pretty chaotic regulatory environment. Nobody really knows what’s going to happen. So my question is how do automation networks become part of the architecture of a protocol? Not from a technical perspective, but from a regulatory perspective. In other words, if a protocol is running its own ‘home-rolled’ keeper bot, what does that mean for the regulatory domicile of that protocol? Conversely, if a protocol says no, we need maximum decentralization. So we need to outsource execution to a fully decentralized autonomous automation network. But we don’t want any Keepers that are in the United States. So how does that work? This isn’t only about technology. This is also about understanding that there are a lot of people out there who don’t like the idea of transactional freedom. They don’t like a lack of transactional surveillance. Full decentralization is the only viable global strategy in many cases. And yet even that may not work because if you have your own keeper bot, you’re not decentralized, you have a single point of failure, AND you have regulatory risk stemming from your control of the keeper bot. This is going to become a much hotter topic when people start to say ‘Where is a protocol domiciled? Well, I don’t know, let’s look at their keeper bot because that’s the thing that’s executing’. So maybe it’s the keeper bot that gives them control and domicile? At which point I can tell you that protocols really don’t want to have their own keeper bots. At the same time, PowerAgent not only needs to be a provably fully decentralized automation network, but we also have to be able to assure protocols that nothing Keepers do can fall foul not just of US regulation, but in the future, every country will have some weird and wonderful patchwork of regulation that no one can predict. One of the roles of an automation network is to give protocol architects options to say, ‘We don’t want this particular kind of transaction executed by Keepers who could get us arrested in our own country’. Obviously, Keeper domicile becomes relevant. No Keepers should be allowed from totally sanctioned jurisdictions like North Korea, for example.

The real problem is that eventual regulations on crypto DeFI will not make sense. There is no one in charge, literally no one is sitting there looking at the whole world going, oh, we need consistent regulation. No, never going to happen. Not going to happen. So the architects of every single protocol have to have a global regulation strategy and we PowerAgent as an automation network also have to have a global regulation strategy.

Vasily-PowerPool: So you want to say that if a project has its own centralized automation bots, the regulatory responsibility comes from some actions that these bots take?

Gordon-PowerPool: Of course, it’s an attack surface for regulation.

Vasily-PowerPool: Yeah. It’s a good question who is responsible for what. Right. In any protocol. So if a user did something from his own wallet he’s responsible because he was interacting with the protocol. I’m not talking about any anonymity protocols. I mean, just basic ones like Gearbox, with no anonymity feature at all. So if a user does something, it’s his responsibility. But if the automation network or centralized bot did something, for example, if there was a centralized bot launched by the protocol itself, like by the Gearbox team, like a theoretical example, it means that if there will be some problem with the bot, the Gearbox team is responsible for it, right? You want to make this analogy, right?

Gordon-PowerPool: Exactly. These are issues and I’ll give you some examples from Tradfi. If you’re in a country where you’re not allowed to, for example, invest in US dollars or maybe religiously, you’re not allowed to earn interest, or for whatever reason, you have some restrictions. In TradFi, people often outsource asset management to managers in other jurisdictions. Usually to save tax, but also to give more freedom to the strategies. So for example, in the Anglo-Saxon world, you have offshore islands like Jersey, Guernsey, and Isle of Man, and all of the financial services that are centered there are there because clients around the world are outsourcing the responsibility to agents resident in jurisdictions where the strategies are legal. Something similar will eventually happen in crypto, which is to say that one of the roles of automation networks and also the role of asset management protocols like Gearbox is going to be to allow people to outsource asset management to avoid legal problems. And I think it’s going to be a bigger role than most people think. Certainly, it is in Tradfi. Asset management operations are all headquartered in a few certain jurisdictions, and people who don’t live in those jurisdictions need to outsource to people who do live in those jurisdictions. So I wouldn’t be surprised at all if one of the major use cases of Gearbox will be asset management for people who are in places where what they’re doing would be illegal. For example, in Saudi Arabia, women are not allowed to operate bank or brokerage accounts. But they will be able to use Gearbox.

Vasily-PowerPool: But it should be done in a way to avoid any legal risks for Gearbox as a protocol, as a DAO, and as a team that developed some core code and functions. Because I think nobody wants to have issues like Tornado Cash, right? Or developers who wrote the code got some particular lawsuits and all this kind of stuff. So what do you think? We all understand that it’s not legal talk, we’re not lawyers, none of us, not the guys with proper legal knowledge. But I think it’s just the exchange of opinions regarding the role of protocols and automation networks, possible roles. So we don’t provide any legal advice here, of course, because we cannot provide it to anyone. But at least we just theoretically discuss something, right?

Atlas-Gearbox: Yeah. I think on the regulation stuff, you’re talking about that the keepers are going to be legally responsible and it depends on their jurisdiction. The way that I understand it, for example, right now there are already some kinds of bots that are frequently doing transactions on the Ethereum network, or on any other network, like liquidation bots, for example. The way that that works is basically, you set up an incentive market and then you hope that people will run bots in order to win those incentives. And you might have an in-house bot also just to shore up the thing. But the idea is this thing will keep running even if you take your own bot down because you’ve created your protocols such that the actions that you want to be taken on-chain, and people can make money from completing those transactions. So for example, liquidation bots take a percentage of however much they liquidated, in most protocols. So imagine, when we’re talking about even deeper automation like Gearbox bots or what you guys are doing at PowerPool, I would imagine that it would be a similar kind of thing, right? You set up an incentive market and you hope that the people with the right technical skills will build the bots and then they will compete with each other to win whatever incentives you set up in the system. But in that sense, it’s still kind of decentralized, at least in such a way that like, okay, if you’re in a jurisdiction where doing that thing is illegal, then you can just not do it. Or you can try and do it in a sneaky way or whatever. But hopefully, in some jurisdictions, it will be legal. And then the people who build the code to make the transactions that need to happen on-chain are there and there’s enough of an incentive for them to compete for those transactions, basically.

Elias-Gearbox: Yeah, in terms of the predictions, you are definitely right. So there is an incentive market and first come, first serve, in terms of liquidation stuff. But if we talk about Gearbox spot transactions, it’s a bit different. So there is no kind of asset management or anything like that in Gearbox protocol, we don’t provide such kind of services. What we build is primitives for leveraging. And later users actually can decide how to manage their funds, and they can delegate these rights to some other parties. So Gearbox just provides some software to manage specific operations and that’s it. And Gearbox doesn’t act as a counterparty for asset management. So yeah, at least that’s how I see it from the legal side, I’d say. But of course, if we take a deep dive into the bot side, there arises a lot of questions. If you use any kind of automation stuff. First of all, of course, like if it’s some centralized party, it’s some service close to asset management, close to some specific operations, there could be some legal outcomes for such kinds of relationships.

So it’s a relationship between, if we talk about Gearbox, between credit account users and people who actually wrote the bot or used it in some specific manner. If it’s a fully on-chain bot, I guess it could be seen from some other option, and it’s hard to say how much of the asset management legal stuff is here. If all logic is fully on-chain, it’s visible, and it’s needed to run some specific transactions in specific timestamps, yeah. For me, I’m not a lawyer, so it’s difficult to say how it can be seen from a legal perspective. But yeah, this part definitely can be delegated and it’s better to delegate it to some decentralized network automation, like PowerAgent, a good example here of how it can be managed to mitigate such kinds of risks. But yeah, I guess it depends on what kind of strategies you want to implement and what kind of rights you want to give to both.

Economic incentives for Keepers in a permissionless network

Vasily-PowerPool: I want to add that not all automation tasks in the world can be handled in a way just to provide incentives and hope that someone will try to get these incentives. Because when you create an incentive but don’t have any particular requirements, you don’t have anyone who is responsible. For example, if gas is quite high or there are some circumstances in the network, bots can not execute it. There even were some issues with liquidations that have quite a large penalty, and quite big incentives. Like during the big squeezes down on the market, there were some issues when some positions were not liquidated because for liquidation bots it was too expensive to spend gas to get this liquidation premium. For a lot of tasks, I think you wouldn’t submit 0.5% of the amount of the trade to make automated trading, or 1% of the capital as a fee to the bot, right? It’s not logical, it’s not economically rational. And also, if you’re talking about liquidation protection, if you provide a small sensitive timeframe for execution, nobody’s responsible for it. So, this is the main problem when a community, someone who is not specified, is responsible, you can say that nobody is responsible. This is a big problem because I know a lot of projects, particularly some of them, that have some NECESSITY for automation under the hood. It’s not about trading or liquidations, but they put some incentives that are not small, on the BNB chain, on Polygon, into their design.

And sometimes they find out that, for example, for 24 hours, 48 hours, or even for 84 hours nobody executed some kind of important update or harvest. Anyway, even they have a button on the website for anyone from the community, without any specific software just using Metamask, to execute and get the reward. And sometimes even this does not happen. And so this is why the space needs an automation network because not all transactions can have intrinsic incentives that work really well. Liquidations are one of such jobs that have this incentive that really works and is proven by the years in the market. But for a lot of other tasks, it is much more efficient and cheap to make the task by the automation network way. You pay a gas compensation, pay some premium on top of that, and have the whole network responsible for the correct execution of the transaction. And if not executed well, then the keeper can be slashed, there can be some particular penalty, etc. So the particular responsibility is set in a percentage of the stake. So I’m just explaining that from one point of view, you’re correct that you can just make an incentive, and anyone, permissionlessly, without registration in any network, just can execute this transaction and get the reward. This can work, but it does not work for 100% of possible tasks, with 100% of possible cases.

There are a lot of other cases where this wouldn’t work or it will be just too expensive and not economically rational to automate something with such big artificial incentives. So yeah, I think I’m also aligned with Elias’s vision regarding that I’m not building Gearbox, but I checked it out, made some credit accounts, and participated in the community for some time. I think that the concept of leveraging primitives that can be used for building is quite good from the technical point of view and from the legal point of view as well. So anyone can launch something on top of it, use automation networks, bots, or anything the user wants to get the product working in the way he wants. So yeah, I think it’s a very good explanation. Thank you a lot for it. So what do you think, guys? Do we have any other important stuff to discuss or I can wrap up, make a summary of this AMA, and briefly collect all the important points? What I learned, what was the important information shared here that we need to put on the record one more time. So what do you think? Or do we have something to add additionally to what was discussed already? So, do we have anything else in this? Would you please share?

Atlas-Gearbox: Yeah. I actually don’t think that I have anything to add.

Wrapping up the call

Vasily-PowerPool: Okay. So in this regard, I think we can wrap up with the most important points of the call. So, the first point was that Gearbox has two potential use cases for automation, particularly for products that can be built on top of Gearbox’s leveraging primitive. So one of the products is protection from liquidation, which I personally think is quite important and can make the usability of such kind of product less risky for users and require less attention from the end user, which is quite important because nobody can be online 24/7 and check out everything right? The second product that can be built on top is an automated trading strategy using the leverage acquired through Gearbox’s services. And I think there is a big, big variety of possible strategies, possible products, and particular integrations with different protocols. DEXes and other protocols. It’s very interesting. So I think there is more than one product possible, there are a lot of products that can be built on top. It depends mainly on the algorithm of the trading strategy. And in the future, the trading strategy could possibly be also enriched by zkResolvers making these algorithms private and more proprietary, but at the same time showing the community that this strategy works, works as intended, and the results are taken not from other strategies, but from this strategy in particular.

I think this is also the future of automation, some private strategies that have value when they are private and not public. Because they cannot be front-ran easily as if everyone knew what you planned to do. The third point that was discussed and was very important for me as I personally learned a lot from it was the legal landscape that possibly can influence keeper networks, decentralized bot usage, and their responsibility. Who is responsible for what, in which direction, etc. So it’s very interesting to explore. I’m not a professional in legal stuff at all, but I’m just curious to get some knowledge in the future about this to understand how it can be applied to modern Defi. So this is the point that I got from this AMA that I think is important for the community. So could you maybe add something on top of it?

Elias-Gearbox: Yeah, I just wanted to add that actually we discussed these two use cases, but actually potential use cases could be much broader and they’re not limited to these use cases. Automation could be implemented in different farming strategies, rebalancing between farms for example, and a lot of different stuff. I guess here we have a lot of people who could be interested in building different stuff and we are open to discussing all these ideas. I guess, it’s important and I know some protocols work with some rebalancing ideas, so this could be easily implemented using optimization tools instead of building separate protocols. So that’s actually curious to see how this vision comes to real life, or will it just end up in our thoughts and discussions. But I guess automation, especially in terms of leverage, it’s something very important and interesting to dive into. A lot of interesting stuff can be implemented here. So yeah, I would love to hear any ideas in Discord. If somebody has some other stuff to discuss, we are open to following it.

Vasily-PowerPool: Yeah. Gordon, maybe you could add something to the final note of this call.

Gordon-PowerPool: No, I just want to thank everybody for listening. And I hope the takeaway is that there is a lot to be discussed between protocols like Gearbox and a full-blown, decentralized autonomous automation network like PowerAgent. And we’re still at the early stage where protocols are starting to get a feeling for what an automation network like PowerAgent adds to their options and their users as well. So I just hope that for the people listening, you sort of understand that this is sort of new. All this stuff hasn’t been fully thought through or thought out. And by the time PowerAgent hits the mainnet, everybody’s going to have to think hard about these things.

Vasily-PowerPool: We are so thankful for your insights on the legal ideas behind automation. Because it also has some relation to the legal environment. It wasn’t clear to me, for example, from day one that we need to think about the legal environment and the conditions in which Keepers are operating, the protocols are operating, etc. So there’s a lot of unexplored stuff. I think, maybe we’ll make some AMA with some professional lawyer to get more insights to understand this.

Gordon-PowerPool: But I think my point is a different one: even the lawyers don’t know the answers today. Even starting after, say, the end of WWII, Tradfi regulation across different countries doesn’t match up and is not always that consistent. And crypto is at the very beginning of trying to figure this out. And most of the laws that are currently being proposed don’t actually make any sense. Crypto is all about attack surfaces. Everything should be attacked. If it’s not attacked, it won’t evolve. But the idea that you can dial up some legal expert who will tell you exactly how to do it is just not true and it won’t be true for decades. What IS true is that if you have a fully flexible, autonomous decentralized network made up of a fully international complement of Keepers, all of whom you can select from signer sets you can configure, your odds of minimizing your global regulatory attack surface are going to be a lot better. There is no legal insurance in this case. There is no authority. No one is in charge. Okay? Every country will get away with what it wants to get away with. The formal term for this whole thing is regulatory arbitrage, meaning you do in each jurisdiction what makes sense to do and you don’t do what doesn’t make sense to do or what is too risky. And the reason for focusing on this is that a lot of protocols will think, ‘Oh well the lawyer said, our home-rolled centralized keeper bot is okay’. Well, I can tell you right now the lawyer has no idea what he’s talking about. Even if they were right in one country, they will be wrong in many others. So that’s the issue.

Vasily-PowerPool: Yeah, I think this is a good final note to think about because I personally didn’t think a lot about this before, but it’s a very, very good point to start thinking about. So, I don’t have anything to add to this legal talk, because I’m not very deep in the legal stuff yet. As I understand, we don’t have any real insights and won’t have them for a long time. So now we just need to do what is legal in particular jurisdictions and not to do what is not legal. So it’s a basic rule and I think it’s understandable.

Elias-Gearbox: Yeah. Legal is a real dark forest.

Vasily-PowerPool: So, thank you, guys, for this discussion, thank you for joining. Thanks to the people from Gearbox. Thank you also for your insights and contributions, and thanks Gordon for organizing the whole thing, moderating it, and providing us with a lot of insights. Thank you, guys. Bye!

Atlas-Gearbox: Yeah, Thanks for inviting us.

Elias-Gearbox: Thanks!