Using Solidity for Infrastructure

Transcript

Excellent. Hey everybody, my name is Gerach or Brennan as some people know me as. I am the head of ecosystem over at Drosera and I'm here today to talk a little bit about what we can do, how Solidity can work in a new way, in a form and fashion that it hasn't previously for us before and the different things that Drosera can do to optimize your smart contracts, your protocol, and everything to do with your ecosystem in web 3. What is Drosera? Drosera at its core is a security and automation protocol that's built and designed to work well for notification alerting and onchain response. One of the things that it

really shines at and one of the things that we've really enjoyed the most about is that for developers to come and build and expand their toolkit onto Drosa and work with us doesn't require you to go learn 50,000 new fancy tools. It doesn't require you to go learn a brand new type of code, any kind of new thing that you haven't touched before. Droera at its core is just solidity at the end of the day. You can write the same kinds of contracts with incredibly upgraded capabilities that you never would have been able to onchain previously. Because of that, we've created something where now we have smart contracts that we call traps that run continuously. They can respond, react, alert, and push an

onchain action for anything that you can possibly write code for. With that being said, there are a huge, huge, huge breath of use cases. Even if you just take into account the different things that we can do on traditional mainet, not even counting the fact that we can work on base polygon and in all these other places where you can truly build some unique and interesting things that haven't been done so far. An interesting thought experiment that we talk about frequently whenever we're introducing the idea of Drosa is imagine a world where you can run these smart contracts that operate 24/7 all the time. They can ingest and respond to much more than just state data. They can also work with

event data and they can take on a plethora of new information because each of our nodes has a copy of the equivalent of the graph on it. With that being said, it makes it so that you can go and you can build new logic and build new things that have never been done before on chain and set it up so that your ecosystem is more well protected and reactively ready to deal with a compromise, an issue or anything that you can think of that you can write in solidity. The number one thing that we thought about whenever we were designing Josera, we were putting it together and we were thinking about what devs might be able to use these tools for and what form and fashion is. When you look around the industry and you see what

security offerings there are in the world right now today, there's a lot of proactive solutions. You have audits, you have folks like Hypern, you have a plethora of different options for people who want to help you prevent the day one problem. There is almost nothing that exists that is for the reactivity for what happens after the compromise or the attack has happened. That's one of the things that we first looked at whenever we were building Drosa. By creating post- deployment security in a way that people understand already that is already in solidity that they're familiar with. Regular devs who are already working and building amazing new protocols can work in the same thing they're already familiar with to further

secure it, prevent more malicious actions from happening, and get robust information about what's happening in their protocol and their ecosystem through notification and alerting that just doesn't exist today on chain. The risk automation aspect of what we do makes it so that not only are we infrastructure but at the same time we're a security solution for people. Creating these unique smart contracts which once again we called traps makes it so that folks are able to enable their ecosystem to do things that they were never going to be able to do before.

I've kind of already touched on it, but a trap is a one of these upgraded smart contracts that we've created. So, Drosera as a whole and the way that the ecosystem and architecture looks internally for us is we have our own network. We have our own nodes, our own operators, we feel very similar to like a layer 1.5, but instead of us acting like a layer 2, we've built our own ZKVM. And the whole purpose of what we do is to push these onchain actions onto the main net or an L2 if you're working on one of those. The idea is that if you are using us, you are still using a ZK verifiable solution that feels and looks just like the ETH mainet, but with an

incredible addition of functionality that doesn't exist anywhere. Whenever you work with a trap and you're working with these different tools, it feels much much much similar to passive contracts that have now been turned into active contracts. The passivity of the onchain smart contract today typically means that unless somebody is interacting with it, it's not doing anything. The problem that creates is that you can't set it up to say, "Hey, I'm looking to see if there's been an outflow of funds for my treasury that's more than 10, 10 or 15% and I always want to be looking at the next confirmed block to see if something like that happens. And if it does, shut it down and require five, six, 20 multi-IG

signers to say, "Yes, this is okay. We're good to proceed and move forward with this." Problems like that when they occur are almost always as the result of a compromise, but by the time it's happening, it's too late for you to do anything about it. This is a very, very good way to do something about it that's constantly sitting in the background that you don't have to think about and that only follows predetermined logic that you have specifically written. There's not a bunch of gotchas. There's not a bunch of, oh, well, you didn't do this piece of this puzzle, so this didn't work. It is quite literally just a result of whatever you've you've built yourself and what you want to see it do.

It gives you the flexibility and the transparency to be able to design solutions that you don't need to think twice about whenever it comes to whether or not you can trust it because you built it. It's not somebody else's software that you can't trust or that's a black box or that you don't know anything about. Our our plan and where we're headed is to be fully open source and to make it so that people can work with us in a way that they already know, feel familiar with, and that they can rely on. Crypto is an ecosystem of digital organisms. We say this over and over and over again as we have conversations internally and we talk about the kinds of things that we want to see on chain in the future. The fact of the matter is is digital organisms all have different

functions. They fight for different resources and they all work with different things. I'm sure every single one of us remembers whenever gas was so expensive that getting a transaction through was near impossible unless you were spending a good chunk of your own money to make it happen. Especially if you were trying to beat other people to the punch. When things like that are happening and when things like that are going on, those are the moments that we really see the benefit of being able to use a trap to work on some of that functionality. We're near gasless at the end of the day. The amount that it takes to run one of our smart contracts continuously is so much less than what it takes to run even a single mainet contract by itself one time. It's hard to even believe sometimes.

Trees communicate through an underground network of fungi known as micorisol networks. The reason why this is relevant is because this is part of what we modeled the original design of what we wanted Drosa to be after. You have signals that come from these neighboring trees. There's always one or two that hold everything together. But at the end of the day, if you can't react, respond, interpret, or work with those signals you're receiving, those trees are dying and the forest isn't working. We see that very commonly right now here in the space. There's very very little composability between different protocols or different people working to do different things on the main net.

Some of that's by design. Some of that's just the way that it's built and set up. What we want to create is a world where you can work with something like Troera as your base layer for signaling and for the different things that you want to see executed and run on without having to deal with the unreactivity of smart contracts on the main net. Protocols are equivalent equivalently connected. This is another thing that we talk about all the time and it goes back to the original ethos of what can we do to make it so that protocols are more composable. It's more able to work together not only across the mainet, but to make it set up so that you can have automation that works for you without having to compromise a your security, b

import something that you don't understand or use a tool that doesn't make any sense. And C, it's written in the native language of what everything else around us that's working there is already built in. very understandable, easy to work with, and more importantly, it can flow in between different places easier than, for instance, if we were building on a protocol where oh well, you know, they've got Rust included here and all these different things. By focusing on solidity, we make it so that devs can work with things that other devs already know and it's easy for them to have a conversation about it any minute of the day.

The reason why we call ourselves Droera and the reason why we call smart contract the smart contracts that we've invented traps is because we named ourselves after the Venus fly trap. The Venus fly trap's original scientific name when Charles Darwin discovered it was called the Drosera. That's what we call ourselves as well because our whole goal is to catch the things that you're looking to get your hands on. Malicious transactions, people trying to do interactions that they don't want to happen. the different kinds of things that you see in slashing detection for those things. We can automate and work with all of that. So, we're a fantastic comparison to a Venus fly trap that lies in wait continuously to spring their trap and activate what it's meant to do,

which is catch the bug. You know, in this instance, this is a very good example of what it looks like whenever you're working with our traps and what exactly it does. So, with this, you know, it's got an emergency response as the the final end result down at the bottom, but it doesn't just have to be for an emergency. We've seen people build traps that have done things ranging from looking for stable coin deping events so that they can swap into them for a profitable trade to looking for stable coin deping events so they can swap out of them to prevent something malicious from happening to the majority of their money. The other thing that we've seen frequently is folks are a very big fan

of the notification alerting data that they can get with something like Troer. We have a tool that we've built internally that can ingest that kind of stuff. web hooks. We can send it into your Slack. You can use a plethora of different options to be able to get that kind of info without ever even needing to push an onchain notification. And the reason why we're able to do that is because these traps are running continuously. I cannot stress enough how big of a deal it is to be able to constantly look at the next confirmed block and do something about what's actually happened there instead of relying on a hope and a dream that you're going to catch it whenever something bad begins to happen. For instance, especially on the notification side of things, it's very very easy to say, "Okay, I want to know how many of

this type of event is happening or how many of this type of state interaction is happening on any given day at any given time." You can log it, have it sent to a Slack channel if you'd prefer. We could plug it into your Telegram if you'd like. And the best part about all of this is you don't have to call me, the ecosystem guy, to build this for you. Anybody can build a trap. It's just like working in any of the regular protocols you would have originally when you were designing that kind of work. Feels very very very familiar. And if you're somebody who's looking for an onchain result in your smart contracts that are currently on the main net, it's two lines of code to import the logic from our from our traps into your main contracts. It's a very very very easy

process. I'll show an example in a little bit about what a typical trap looks like. We're typically looking at anywhere from 40 to 60 lines of code. So, it is an incredibly simple product to be able to work with, implement, and also get the advantages out of depending on what you're looking for. We often refer to ourselves and what we're doing to enable the ecosystem as the infinite forest. So just as we were discussing how there's chemical signals between different plants, forest, everything that goes on there, we feel very much so the same way with the composability of the traps within our ecosystem. It's actually not hard to do something amazing like say, "Hey, we're

looking for addresses that are on the OFAC sanctions list or we're looking for addresses that have previously interacted with these malicious protocols or any other and say, "Hey, we're going to make sure that that can't those people cannot interact with anything on our protocol on the mainet." And if one person is using that, it's simple for another protocol to say, "Well, we'd like that, too, and use that trap for the same thing and opt into the same one." And it makes it this giant organism where everybody is able to work together to secure and work on the same things without necessarily ever showing their ass so to speak where you're saying, "Hey, you know, I don't want to reveal what my internal code looks like or I don't want to reveal what I'm

looking for in particular." You don't have to. Everything is ZK verifiable. You can choose whether to share that trap and let people see it publicly. You can choose to keep the bite code private. It is it is totally up to you what you decide with that. Once again, we're talking about the survival instincts from these digital organisms. Now, no longer are you sitting there potentially sitting as a dummy waiting for something to happen to you. You can build your own reactivity to respond to any kind of event that you can envision. If your biggest concern is as a staking protocol, one day your pools are suddenly dipped down to 1% APY whenever they've been at 17% APY and you

need to be notified of when something like that goes on, it is incredibly easy to set something like that up for us. The other advantage of it too is if you really get into the weeds of building it, your trap can go and look for a much more profitable option and put that fund into there. There is so much that you can do with these with these traps that when we go through the use cases, you'll begin to see a little bit more of what I'm talking about where it's just this incredible plethora of options for us. There's a wide breadth and a deep depth of the different things that you can do with Troera to protect yourself, to notify, to automate, and to take different actions on chain that you couldn't have previously.

The way that our nodes and our operator network works was intentionally designed to be incredibly lightweight. The number one thing that we have seen as an issue as scalability has continued on the mainet and in other places is a total lockout of regular people like us being able to run and execute this stuff because we're never going to be able to compete with folks who are operating in data centers. With Drosera nodes, you can have a two core CPU with four gigs of RAM and you are still able to run a node that can do an absolute wonderful, wonderful job at what it does. The fact of the matter is is most of these continuously run smart contracts at all times are simply looking. And because

they're looking, they're not actually performing any actions. They're just looking at all times, which is great for you and great for us. It's protecting everybody. But the good thing is is it doesn't require a giant beefy machine to do that. Every single one of these nodes has a copy of the graph on it. And it's easy for them to be able to say, "Okay, here's what events were emitted from these different protocols. Here's what this trap is looking for. We don't see any of that. Take no action." It's very quick. It's very easy. If something does happen and it is time for it to react to it, this is still more than enough to be able to push the response necessary that you're looking for that you've written in your logic already.

Now, brother, I'm going to keep looking at you while I'm talking cuz I I'm I'm doing my best here to chat. But, uh, in case it's not super clear, lots of times what we're talking about is the fear of the dependency risk issue. So, as we saw with Balancer the other day, a compromise can happen and it can come out of nowhere from something that you never thought about, never planned, and never prepped for because you got audits, you had all of the things done correctly to ensure that you were safe, you were smart, and you were good, but you didn't have any reactive defense to take care of what's gone on. The proactivity is incredibly important, but you have to be prepared for whenever all else fails. And that is a big problem that we're seeing in web 3 constantly.

An attitude has been adopted that you can get an audit done and you can pass it through some really fantastic devs and if it clears all the boxes and checks everything and it looks green, you're good to go and there's a low likelihood of something happening to you. The thing that people constantly forget about is that's only the case that day at that moment in time. Dependencies change, protocols change, PRs are done. There are a million minute things that might happen or affect your protocol that might encourage you to say, "Hey, I don't really have anything to be worried about here. This isn't really a concern that I need to think about."

Everybody in web 2 has already adopted the stance of it's going to happen. A compromise is going to happen to us. There's a fear. There's a concern. There's a worry. We need to be prepared for the inevitable. In web 3, we see people not take on that attitude almost anywhere. They don't prep for the inevitable. They don't ready themselves to be able to take care of what seems to be happening left and right every single day in the industry. That's why we built Drosa. At the end of the day, we're a very reactive solution. That's great for a post compromise solution for you if you need that kind of help.

One of the great things that we've been up to and we've been trying to work with people on frequently is running trapmies. So getting these tools into developers hands, showing them how it works, what they can do with it, and the different ways that it can be applied with the goal of raising the security of the entire ecosystem as a whole. At the end of the day, anybody can jump in and build the trap on Drosa and opt into some operators who are interested in executing the logic for their trap. And you don't need there's there's no oversight as far as needing to get permission from somebody or doing anything like that. So anybody can build this protection for themselves without having to pay a ridiculous amount of money or more importantly having to pay a ridiculous amount of operating cost.

What's the point of of securing yourself and saving yourself if you're getting a $10,000 bill every single month from your from your cloud service that you're using for whatever it is you might be doing? With us, that's nowhere near as much of a problem. We're intentionally designed to make it so that you can secure yourself in your protocol without spending an arm and a leg. I always like to show a little bit of some of the things that inspire us, some of the vibe that we put together as far as like Drosera, our art, the Venus fly traps as a whole. This is the kind of stuff that whenever we're looking at it and we're thinking about it, the community is excited about it. We're excited about it, but it reinforces in us that we really do like the comparison

of being able to be the trap for the bad guy. That is that is the thing that we really enjoy focusing on and being able to also provide that notification, alerting, automation, those typical things that you just don't see anywhere else right now in an easy to understand primitive and standard. That's absolutely where we shine the best. To everybody who hasn't been able to join us for the quick presentation here, I just want to say I wish you were trapping with us in Argentina. I know we have quite a few people who are going to be checking us out and having conversations later, but now I want to spend a little bit of time diving into the different ways that you can use use cases with us.

running through it because I don't want to make you listen to every single one of them. But to start at the top, one of the first things that we were approached about that was really interesting to a lending and automation protocol we were discussing was an automated liquidation response. when you can move collateral like when you can be watching for a collateralization drop via trap and initiate an automated response to trigger either a partial or a full liquidation. You get the added benefit of being able to both run in a ZK verifiable manner. You don't have to pay to deal with the onchain automation that typically comes around with that. And on top of that as well, we're running continuously. So we're always looking.

we're always ready to do it. It makes for some very, very robust response whenever it comes to anybody who's got a lending platform or doing anything that has to do with constantly looking to see and check if a number needs to be changed somewhere. with Dexes in particular, monitoring different tokens, looking at their volatility, seeing the different things that they can do as far as being able to say, "Hey, you know, we're in a situation now where there's not enough liquidity here, there's not enough volume here. Push me an alert so that I know that this coin is no longer getting what it needs to get so that it may be delisted or some combination of those things." This is a really, really great

tool to be able to make things like that happen. And it's very, very, very simple to create, too. Yield farming is probably the second most popular conversation that we have. Yield farming and staking. When we're chatting with folks who are interested in that, they're typically doing quite a bit of shuffling around as far as moving their coins to different pools, looking for the best possible combination of solutions to max out as much APY as they can possibly get. With Drosa, you can build traps that are looking for those things and are also taking the response to make that movement happen for you automatically. If the logic is written robustly and correctly, you can set it up so that we're taking Drosa is taking

care of all of that piece of the puzzle for you in a manner that can be audited, can be easily looked at, and you can take it and more importantly at any point in time. Make it so that if you so please, you can add any additional layer you can think of without having to go redeploy on chain, recreate some kind of staking pool or something similar or do anything like that. Now, we're talking about oracles at this moment, but I I'll talk about infrastructure providers as a whole. Infrastructure providers tend to have a lot of different moving pieces in a million different places. They're spinning nodes up and down frequently in different spots. That's commonly on web

2 infrastructure that they own already. Perhaps it's a data center that they've got their stuff collocated in. Perhaps it's AWS. Perhaps it's another cloud provider. There's a million options. But without a good look at what's going on on chain at all times, it becomes hard for them to know where profitability is, who is using what, and to what extent that usage is happening. With Trosera, it's easy for you to build infrastructure monitoring traps that let you look into the million different kinds of things that you're looking for. Trigger alarms, look for unusual data fluctuations, and most importantly of all, one of the best things that you can use us for is to identify and prevent oracle manipulation attacks. If you use

Troera, there are native oracles that are already built into the infrastructure of the eco. You get the added benefit of being able to import any kind that you would like as well. And now you have a secondary smart contract on top of the one that you've got on the mainet that can look for the same checks that your mainet contract might be missing and give you an additional layer of security that you wouldn't get privacy solutions. The very first app that was built as a thought experiment on Drosa was Drosera Tornado Cache. It was the very first thing that we were excited about looking at as a solution and something that we could use. And it was just something that we wanted to see if it would work, if it was something

that we could replicate and make work in a fashion that made sense. It's one of these things where you because you can do what you are you already know what you can do on chain with smart contracts. We've just upgraded what you can do and how much of it you can do in a way that we haven't really seen anywhere else before on chain. Bug bounty platforms are another popular conversation that we've been having recently. Drains happen, exploits happen, and all kinds of a million different kinds of compromises are seen across the ecosystem every single year. It is always something that people try to prepare for and look for. And bug bounties are a good example of protocols

being proactive and trying to say, "Hey, we're looking to see when these kinds of things happen and we will take care of you for it." If you were someone who was interested in looking to make it so that you could automate the payout of bounties or something similar, that's another fantastic use case for us that you could use for traps. If you were looking for a specific way to double check for something or to see if it was real, you could write a trap that was looking to see if they could replicate that action and even make it happen instantly. And if the outputed result was what was expected or what they claimed that it would be, it would be easy for you to automate such such a thing.

So I I touched on this a little bit earlier, but this is this is easily the one of the most frequent conversations that we have. So stable coins in a general sense, of course, we're all very well aware they're a dollar, but they're pegged and stable coins dep and day out is is how can traps protect my stable coins in my treasury? The answer oftent times is is we can look for a deping event to happen and you can set up predetermined logic to say, okay, it's at 60 cents now. USDC's DPEG to 60.

I've got two options here. I can hold, I can hope, I can wait, or I can start swapping into a currently more stable coin or even regular ETH, Bitcoin, whatever you might have in mind, and I can try and mitigate as much of the damage of this deping event from my treasury as humanly possible. The alternative flip side of that being, hey, I'm looking for deping events because I want to swap my coins into them because I trust that it's going to rep. So you have both sides of the same coin in terms of stable coins. Both of being able to protect yourself and being able to take advantage of something like that happening. Stuff like that is much better done through a continuous solution like we are that's always looking, always watching with regulatory compliance. I know I

brought it up a little bit earlier as well but it is so easy to take one of the publicly available traps that are a list, a constantly updated list of everybody who's on the OFAC list or the folks who are on the anti-moneyaundering list, right? You can always be looking for their addresses. You can always be looking to see if they're interacting with your protocol. And you can even set it up so that if one of those addresses does interact with your protocol and deposits funds or does anything similar that a trap automatically executes because it knows their address and freezes those funds on your protocol and prevents anything else from happening with it. That address won't be able to interact with it again. They won't be able to withdraw or use those malicious

funds and it will prevent them from trying to execute anything on your protocol that you can imagine. Stuff like this is obviously something that they try to circumvent constantly with new addresses and the million different ways they do it, but they're still so sloppy that they'll use their OFAC list, their sanctioned addresses all the time because they don't care. It makes no difference to them. With something like this and building these different kinds of tools, it just makes the ecosystem safer and it makes it so there's more tools available than ever before to try to prevent malicious actors from interacting with your protocol.

I chatted a bit about the possib possible functionality for treasuries already so I won't hit it again but another fantastic thing that that we're looking at all the time and always talking about is working with multisig so one of the first things that we were kind of having conversations with was noisafe you know we were chatting with their team seeing what their architecture was like getting into the weeds with them about how we might be able to work together and the answer ultimately is is that to build something for a multi6 signer is awesome, but we're seeing people build traps to act as one of the multisigs now. So, folks are getting smarter. They're starting to think, hey, if my people's multisigs are compromised and they get three of the

five signers because my devs were using password one as the password for their for their computer or whatever happened and people were able to get in. If you've got traps as part of your multi-IG solution, you've got to go into Drosa's ecosystem and interact with that particular contract, which only you'll be able to because it's private and it's yours. And that's the only way that you can get that multisig signer to sign off as a yes, everything is okay. So, this can prevent not only the issue of, hey, your team's been compromised, it can stop your whole protocol from being compromised, especially if you require a complete consensus of all of your signers. If Drosa is the last one that you need done and you set it up so that all seven of your other team members

need to sign the Drosa trap as well to make that happen, there's a really good chance that an attacker doesn't even know your Drosa trap exists. It just knows there's this eighth multi-IG that they can't seem to get their hands on and therefore your funds are safe. We talk about liquid restaking a lot. It's been a huge huge huge topic of conversation in DeFi in a general sense in the past 3 to 6 months even a little bit longer than that 12 months I would say. Those liquid restaking tokens are also subject to the same mechanism of deping and price fluctuations that those different kinds of staking pools are

working with just as everybody else is. The same way that you can use a trap to be constantly looking for something to happen with stable coins, you could set that up for any coin that you could possibly imagine. liquid restaking or otherwise. Ultimately, if you wanted to make it so that you had a trap that was essentially acting as your stop loss, you could do something like that, too. So, I'll uh what I'll show next, I could go through every single one of these for another 45 minutes, but I won't do that to all of us. What I will show next though is a snippet of what it typically looks what a typical trap looks like to give you an idea about the logic. So this is a really great example of a block number trap, right? So this is

less than 40 lines of code total, but provides an incredibly incredibly important function for the folks who are opting into it and using it. The fact of the matter is is this these traps can be built in Solidity in such a way that even with incredibly incredibly simple tools, you can trigger complex actions that protect you, keep you safe, and prevent people from doing the kinds of things that we see every day across the space. Another great example is is the operator commands list. Right? If you are working in the Drosa CLI, this is pretty much all you need to know to to make that happen for you. It is not complicated. There is not a ton of complex integrations, commands, and a

million different things that you need to know about. This was all intentionally designed and created with a normal dev in mind. We built this so that people can go and talk with their developers and we can immediately nerd snipe them with the possibilities because at the end of the day, those are the folks who we're talking to who are the most excited about what they can do with us. And so, we built it for them. They were the people who we really were excited about getting their hands on this. And we've had over 25,000 traps deployed since we've been in testn net. We've had 40 plus thousand individual users across both testnet and mainet.

And we just recently launched into mainet about 2 weeks ago. So now we're at the stage where we're actively securing protocols. We're having our first conversations with people who are really excited about using us. and our investors are beginning to find more and more and more opportunities not only amongst their port co but in the wild in a general sense who are excited about seeing Drosa applied to what they do. The last one I'll show you is just what we tend to use whenever you're like simulating a trap creation or you're updating a trap. This is this is everything that you need to know. These common actions, these super super easy things that you can work with. This is not complex. That was our whole point.

That's what we wanted whenever we were designing it. Now, I I know I've got about an hour, but once again, Drosa was designed so that it could be explained much quicker than that. So, please, if anybody's got any questions, anything they want to talk about, anything they want to know, don't sit at your tables. You're welcome to come have a conversation with me, and I'm happy to talk about it. And I appreciate you guys for chatting with me a little bit about this today. Thank you.