Locking Down Safe Smart Contract Deployments w/ Key Management Policies - DeFi Security Summit 2025

Transcript

All right, let's do this. All right. Hey, um, thank you all for, uh, for hanging out. Um, my name is Dion. I'm here to tell you a little bit of uh um what it's like to write secure policies uh that can help you for example deploy the smart contracts that you thought you wrote and the ones that auditors actually audited instead of potentially buggy ones or potentially ones that have been backed by I don't know let's say an insider which we've seen kind of happen uh more often than than than I would like. Um before I get started, I guess maybe I'll tell you a little bit about who I am. I'm one of the co-founders of

Cubist. Um I'm also a faculty at UCSD where I uh co-lead the security and the programming languages groups. Um and um I also sometimes wear a board of directors hat alliance which is kind of the organization that's been working on deploying uh and securing web assembly outside of the browser. A while back I uh I found a different company called Intrinsic that was working on Noode.js JS security uh maybe before all of web 3 kind of started doing a lot of stuff in in node that's that's really sensitive um broadly I work on secure systems um so like I've done a bunch of work that that has landed in in browsers uh a bunch of work on secure hardware so think like looking at hardware uh timing

channels and things like that uh but at cubis I've been working on uh our key management platform called uh cubigner now the reason I guess like we were started working on um on key management was largely because if you look at like what people are having a hard time with and where things go wrong um just purely by the amount of money that people have lost in the space has been largely a fraction of uh a huge fraction more than half of it has been due to key compromise or misusing keys. So, it's a little bit hard for me to point here, but like the right half of this pie chart and a little bit into it is basically because of key compromise of one sort or another. Um, and it's not always that people are losing funds.

Sometimes they do silly things like if you don't properly manage your keys, you might mint, you know, $300 million worth of of tokens that you don't actually have, which could actually have serious consequences if that's actually ever made it undetected. Um now the one thing that I want to kind of get at like what's common between all these things is that all these things could actually be prevented um if we slightly rethink how we do key management from we just show up with a ledger to actually thinking a little bit beyond that in particular if you actually lock down your keys and secure hardware and I'm thinking here server side um so that there's only one place where this key actually lives uh then this means that we can actually have complete mediation

so we can have a policy that's sitting in front of this key debts in secure hardware that only allows us to sign transactions that are allowed by particular policy. So we can actually enforce lease privilege um that would be hard to do otherwise. Um and of course like this only like is meaningful if we actually lock down the policy itself. If I can just go to your system modify the policy well I'm so glad that you spent your time writing this policy but like if I could just modify it to do whatever I want it's all bets are off right. So like we really need to make sure that this thing is actually completely mediated which means that our policy has to actually be locked down itself. So in this in a sense we need kind of governance policies on policies right so like who's

allowed to modify a policy. Um so um this is kind of like what we designed cubeigner around. I'm not going to this is not really a product advertisement but I think it's a useful example of a thing that exists that does this right. So like at a high level like the thing has just exposes an API for signing transactions for creating keys for managing user so on and so forth. Um then you have an authentication layer which you need to make sure that hey who's actually trying to perform these actions and a policy engine and right behind that right so this is the thing that's actually going to enforce am I allowed to sign this particular transaction or not um and finally we have the secure hardware that does a bunch of fancy stuff by combining nitro enclaves with HSM but the high level bit

is it's actually rooted in HSM not just a nitro enclave and this is what gives us essentially this property that this is the only place that the key exists and there is no weird protocol call for somehow recovering keys like we have like these things actually rooted in an HSM. Um, okay. So, what does this mean at the end of the day if you had an architecture that looks like this? Well, it basically means things like the bybit hack aren't a thing that we would have to necessarily be worried about. I'm not saying you shouldn't be worried about Lazarus. You should, but it it it does mean that a compromised UI doesn't mean in a drained wallet, right? In particular, if we have our keys sitting server side and secure hardware, um we can ensure that these policies are

forced. So for example, we can ensure that three out of three UB keys are from the right users approving this transaction. Uh we can ensure that only transactions to known warm wallet addresses are allowed, right? So like this is a simple policy that we can specify. Um we similarly can say like hey like maybe like these three people are actually rogue. Maybe we want to give the community uh more confidence in what they're what what the what what these folks are trying to do. So we can have transfer limits, right? So we can say like, oh, you're only allowed to transfer, I don't know, a million dollars over like a day instead of $1 billion at any point, right? So like actually having transfer limits is a thing that we can enforce and we can ensure that this is the only thing

that's actually allowed because well our keys server side in front of that is this policy engine and then we can have policies to ensure that those policies are actually enforced right so we can require for example um maybe not five out of three UB keys but let's say five out of seven UB keys uh to change your policy uh and in particular we can have a policy that says like hey we can change this policy but there should be a 7-day window before this takes effect. So, you're not allowed to change the policy to something potentially malicious um without somebody noticing for a week, right? So, we can set these kinds of policies. Um now, this is like something that you can do with with with other systems, right? Um and these are

things that we have built in because they're common enough that you really want to actually have them. Um but like if we really think about like what is the key manager actually giving us and what how should we be thinking about policies where you can just say like hey Dan we need this new policy can you guys please add it we'll add it to the road map and maybe we'll have a policy for this. Um right so like at the end of the day like this has to be like important enough to enough customers that we're willing to do this. Um and this kind of sucks because this is a policy that you might only care about and you might be the only person that cares about this because it's your particular system. Um, and what this basically means is like we should let you implement this policy

yourself. So if you want to have a policy that maybe is not super common, I guess this one maybe is common enough, but I want to for example ensure that my developers can only deploy contracts and contract upgrades that have been built by our CI pipeline and can be app that were approved by our auditors, whoever those auditors may be. Right? this is like a particular policy and like you could imagine adding something like this but you can imagine having like way more complicated policies that are not generic across the ecosystem. Um, and this is where like WASM comes in, right? So like in the previous picture, I showed you kind of like we have a policy engine with a bunch of those built-in things, but really the WASM policy engine is the thing that lets you do whatever you want, right? So if you can

write code, you can express a policy, right? So you can do things like secure deployments, right? So we can say like the only thing you're allowed to deploy and the only contracts you're allowed to upgrade are things that were audited and built with RCI. You can do secure bridging, right? So we actually have customers doing this uh in production today where basically they're watching one chain to see that hey you've as a user deposited funds here right so like we and what that might mean is like I burned X tokens and then I'm going to release here on this other chain the corresponding X tokens because I saw that there was a corresponding burn here right so we can match the burn with a mint you can even do this for Bitcoin so

like on Bitcoin I could see that you've deposited one BTC and I can mint one wrapped BTC of sorts on this other chain because I can actually point to a transaction on chain that this has happened, right? So like you can do things that you couldn't before and you can extend to some degree these chains with custom logic that's specific to your application. In this case that may be a branch um and kind of we get the same security guarantees that you would get from running an actual protocol like the safety properties from the fact that these policies are running in a nitro enclave, right? So we get the safety from the secure hardware. And then finally, you can do all kinds of other things if you're using a system like this. So you can do atomic crosschain

swaps. So for example, I can if the if both of us are using keys that are held here and we both have policies, we can ensure for example that I can only spend money as long as I've paid my debt and vice versa. you can encode, you know, biparty triparty agreements, things that are typically like legal contracts that you may actually want as code because you may want to have the invariant that your TVL is actually what you say it is. And you don't want to necessarily rely on a whale or a giant corporation that has a bunch of lawyers that may delay this variant from actually being true for let's say a week because like for that week your your protocol might just collapse, right? Right. So, we want to actually enforce these things with code.

And you can do all kinds of other like clever things. And we have a bunch of folks that are actually uh doing this live as well where you can have like essentially a private off-chain order book that you can match with like orders on chain and you can implement things like a dex with having like actual security guarantees instead of three, you know, uh trusted dudes. Um, okay. So, there's all kinds of stuff you can do. Uh what I'm going to talk to you about today is uh securely deploying contracts and upgrading these contracts.

So we're going to look at some code. Um and you can interrupt me at any point, but basically this is a live demo. It's not a a video or anything like that. So I'm just going to show you what this thing looks like and then we're going to hit some road bumps along the way and it's going to be fun. Um okay. So, on that note, I'm going to close off Keynote and let's see if I can share my screen. Let's see. All right, there we go. All right. Okay. So here I

have um a key that I created earlier. I named the key contract upgrade because that's what we're going to do. It's just a sec key. We're going to run this locally. Uh but one thing that I'm going to do uh or maybe before I even show you that is you know all those policy that I mentioned earlier. So you can have you know a multi-party policy that requires multiple like people to like approve the thing and you can have a threshold you can require UB keys. Um, you can restrict uh IP addresses, you can set value limits, so on and so forth, right?

Like I'm gonna I'm gonna not set any of those policies because those aren't the ones that I think are are interesting to talk about. The one that I will set um is the multi-party approval for editing the the policy itself. So this is the governance policy that basically says hey in order for like you to change this policy you need to be in this particular case D plus beta owner uh and we're going to require me to like use my UB key to approve changes to this particular policy. So like anytime I want to change this policy including the policy itself I now need to show up with a UB key to to to change this policy. Um and one policy that we're going to set is a wasn't policy. Uh, but before we do that, I guess I want to look at a a

simple smart contract. In this case, my smart contract is just a box that contains a value. There's nothing really interesting to it. Um, and as usual, I'm going to have, let's say, a deployment script. In this case, the deployment script will just be a a TypeScript script that uses a ser as as you would anywhere else, right? So, we're going to create a provider. We're going to create a ser. In this case, it's using uh a Cubis remote signer. Um, and then we're going to deploy a proxy because we want to actually upgrade this contract later, right? And then we're just going to print out like where where this thing was deployed and what the proxy admin address was, right? And then when we upgrade the thing, we know that we're

talking to the proxy admin and the new code that we want to deploy. Okay. So in order to uh deploy this thing um I'm going to MPX hard hat compile. Let me make sure that you can all kind of see this. Um and this is going to compile a few of those contracts. Well, I guess. Okay. Nothing's changed because I compiled them earlier. I promise I'm not lying. Um, I'm going to just show you and get the contract bite code hash because this is the thing that like if I was an auditor, what I would want for my auditors is basically for them to

actually go through the process of building these contracts um, and giving me or recording the hash of the built thing, not just the hash of the source code where they audited this piece of code, right? So, like what we should be expecting from auditors and sorry a bunch of you are auditors. uh but we should actually be expecting them to build the thing and actually say like this is the hash that you should be deploying on chain right so in this particular case the contract is ox 51 be f1 and so forth um and then later we'll go through what that looks like for um for for for the upgrade okay so in a separate tab I'm going to just start a local hard hat node um and this is doing nothing really

interesting other than we have a local network that we can play with so that we can deal with with with the network latency here. Um, and the other thing I'm going to do in this other tab is I'm going to airdrop. Um, and by by this I just mean we're going to basically send some funds from one of the keys uh local to hard hat to my key that's used for deploying this contract. In this case, this key is ox5. And if we go back here, it's the same address here, right? So it's oxa is my address, right? So this is the key that we're going to use to to do the deployment. Um I'm already logged into cubigner locally here. Here I have me as the developer and then here I have me as

the owner of the org. So these are two separate users. Um the idea is as the owner I'm going to set some config bits to let my developers do things uh but not necessarily trust my developers to not be rogue necessarily, right? Like we've seen people deploy malicious contracts in particular like layer zero contracts and then walk away with a lot of funds. Okay, so the airdrop function is not doing anything interesting. The next thing that we're going to do is um actually set a policy that enforces we want to make sure that we're only deploying approved contract. So I'm going to show you a very simple piece of code. So this is the deploy uh policy.

Uh and I'm just going to go all the way to the top. So this policy will run before we sign anything if we attach the policy correctly to the key. So what it's going to do, it's going to parse the request. In this case, we're going to have an EVM request because we're working with with EVM. Uh we're then going to inspect the two uh value. And if it's not actually set to anything, we're saying like, hey, this this policy is only int like this key is only intended for contract deployments, right? So we're not going to let you call any uh contract or send any funds with this thing. The only thing that we're allowed to do is deploy contracts, right? The two fields should be empty.

Okay. So what does validate contract deployment actually do? Well, this is a very simple one. So it's not doing any of the fancy things that I mentioned earlier, but it is doing some checks. So the first thing that we're going to do is we're going to check that hey the key corresponds to um this uh this request so that we're we know we're signing transactions that that we can sign with this key and we don't want to be confused into signing other transactions. Um and then what we're going to do is we're going to take the transaction data um and we're going to get the bite code. Right? So the data when you deploy new contract is your contract by code. Uh, and then what I'm going to do here just so that we can look at some logs is we're going to print the contract uh

address. And then what what Okay, great. Now we have the contract uh hash. What should we do with this? Well, if it's a proxy that we're deploying, we're going to say like this is okay. You could deploy the proxy. Um, and uh otherwise it's not the proxy that we're deploying. It's going to be the actual implementation. So we should make sure that this thing was actually approved by the auditors, right? And in particular here is auditor approved. we want it to be um the this hash that the auditor should should agree to. So we're we're going to like set a variable to make sure that that's actually the thing that uh that a developer is allowed to deploy, but nothing else. And just to show you what

this looks like. So for the is proxy uh primitive, this is just a function that checks like, hey, is this the standard proxy implementation? Um, you could pass this as an argument instead, but I decided to bake it in because like I don't want to deploy anything else. I've picked my version of um, uh, uh, hard hats, well, open Zeppelin's uh, proxy implementation, and that's the bite code that we're going to use. Uh, and the audit approved is a little different. So here um we are going to read from what we call uh a a config a secrets config that contains basically the hash that the auditor has approved or in this particular case it'll be a list of hashes. Um so in our w wasn't policy engine this is like one kind of API that

you have access to. So you as a as a user you have the ability to read secrets things like uh contract hashes or API keys for example if you're making like HTTP request which we'll do a little bit later right but the idea is like you have a key value store you have secrets manager and you have uh HTTP endpoints from where you can write custom code okay so here all we're doing is we're getting the string that uh I as the owner will set that will contain our contract hash um and then return true if the contract I'm trying to deploy corresponds to one of these things on the allowed list. Um on this side as the owner, I'm going to actually set um this environment variable or this uh

secrets variable to this hash here. So um I did this earlier um and this is roughly what it looks like. It's pretty straightforward where we just say set the policy secret this particular key to this list of contracts. So here I'm just going to set this address here sorry not address that this this hash here and this hash is the one that corresponds to the hash of our by code. So if it's not on this list we shouldn't be like able to actually deploy it right. So let's say as the uh otter what I said is actually here f instead of six because it's a different thing that we built. Um then

we should see our policy fail. Okay. So this is the environment variable. As you can see here I've set a few other ones earlier. I I'll explain these a little bit later. Um okay. So the next thing that we're going to do is actually set the policy on the key. Right? So the policy on the key if we look at it I've had an earlier policy here you can do any of the other ones that I mentioned earlier like transaction limits receivers and so on but we're going to use our wasn't policy engine. So here I'm going to do deployer actually deploy latest and then here is where I'm going to show you how we're going to build this policy. So this here we have this deploy RS

uh and then I'm going to build all my policies. Um I guess I built them earlier. Um and then um I've because I've already attached I I've I've named this policy uh earlier a thing already exists. But the thing that I'm doing here is I'm going to say like hey update the deploy policy. So that's the name of the policy with this new was bite code. So, I'm going to do this. Um, and it it might take a little bit because we're sending this over over uh Oh, there we go. That was faster than expected. Okay. So, what happened here is we deploy the WASM policy. Now, this policy exists in the WASM engine. You should be able to run it. We can say like I want to use this policy by doing

deploy. Um or we can do version 14 version 14 because we want to pin down the exact version of um the code that corresponds to the the the deploy implementation. Okay. So I'm going to do that right here. Um and I'm just going to clear my earlier DB. Okay, great. So now what we're going to do is we're going to actually run the deploy script. Um and this should now fail, right? because the environment variable that we've set as the auditor or as the owner doesn't actually allow the thing that we're trying to deploy. So in fact here we get um

a failed response that basically says hey like this thing is not approved and if we look at our policy code where is this thing not allowed? Well the auto approved contract did not actually pass. Um okay so um we can also look at the log for this thing because this is again just code that's running um I'm going to get the logs for our particular piece of code and see like what is this what did this thing actually print out. So it printed a bunch of things because I was playing with it earlier. Um but um you can see kind of like what we're trying to do.

We're checking this particular bite code against what we've uh provided as the caller as the thing trying to actually sign transactions. So okay uh actually um in this particular case I um I lied to you all. This is still running the old policy. That's why that we're not seeing this generic error. Uh so this is running the upgrade policy which is failing. Uh which is great because I never actually approved changing the policy. So there we go. Like I forgot to change the policy. It's running the whole policy. I'm trying to deploy and the thing is saying like, "Nope, sorry."

So, if we look at this generic error, not policy approved. It's actually from this other policy. So, I'm a rogue developer. This is what I would do. I would just try to like mess with you guys. Okay. So, I'm going to veto this change. Um, and then I'll show you what it's like to run the actual thing. Oh, all right. Let me tap this thing. Great. Okay. So this part was real. I did deploy the thing. The part that I never actually successfully did was update the policy.

So let me do that. Um and here I'm just going to say deploy slashv14 or you know what latest is fine for the demo. Okay. So this succeeded. But now as the admin I need to actually approve this thing. Um, and if we look at what we're changing the policy to, we're changing it from whatever it was before, which was our upgrade policy, that's what the name resolves to, to deploy latest. Okay. So, I'm going to approve this policy edit. And as the owner, I can say this is a cool thing for us to do. Okay.

done. All right. So now the policy is um actually set to the deploy policy. Let's actually deploy the thing. And now we should fail because again the auditor hash is different. Right? So unrecognized contract by code is what we're failing with and this is in deployed RS. So we basically end up failing over here because it was not a proxy and it was not the auditors. I changed that six to an F. And let me just confirm that that was indeed a six.

Yes, it was a six. Okay. So I'm going to change it now to the actual thing. Okay, great. Um, and I'm just gonna kill my node to make my life easier here. And now as the not rogue person, run the airdrop and then run the deploy. So now we should be deploying successfully because our policy says, hey, this was like we're deploying a few contracts, right? in particular, we're deploying the proxy and we're deploying uh the actual implementation, right? So in this particular case, it succeeded.

We now have a contract address. This is my contract address here. We have our proxy admin here. We're good to go. Yeah. Okay. Any questions so far? No. All right. So, what we're going to do next is we're going to update this piece of code. So the way we're going to do that is we're going to look at our upgrade script which why don't we take a slightly different one here is we're going to take box evil which is just a a different contract from the one I as the auditor would approve right so this is just uh another contract as the attacker I might want to

deploy this thing instead of the other thing maybe it would be a tweak to the box v2 two doesn't really matter, but the idea is we're going to use hard hat off the shelf. Nothing interesting here. And we're just going to say like, hey, please upgrade my my box contract to box evil. Okay. All right. Excellent. Um, and now uh to after I've kind of deployed the thing as as a the actual or owner, I would have changed the policy from the deploy policy to an upgrade policy. You can imagine doing all as one gigantic policy, but for a demo it's easier to do one instead of the other. Okay. So here I'm going to change this to upgrade latest.

Um and again I'm going to have to approve the change from the latest that was the deployment to upgrade the latest. All right. And there we go. Okay. So now our policy has changed to the up upgrade policy. Now what does that policy look like? Well, this one is a little bit more complicated, right? So in particular, this is the one that we're going to tie back to our CI pipeline. So um I'm going to go to the top and show you walk you through

exactly what this is doing. So here we have two cases that we match on which is the two if two is actually set to something and if it's not. So if it's not set to anything again this is just a contract deployment as part of our upgrade we are actually going to deploy a new contract right so we're going to want to make sure that the contract that we're deploying is something that was again approved by an auditor uh and we're also going to make sure that this was actually built by our CI instead of just me on my local machine. And then separately, we're going to call the proxy admin to actually make the the change, right? So we want to say like don't use the old contract, use the new contract. So we want to make sure that we're actually allowing the change to

the new contract, not just allowing you to deploy the thing. Uh but this is basically a two-piece uh thing that's going to happen underneath the hood. This is what hard hat ends up doing. So it ends up deploying the thing and then it's going to call upgrade and call. So validate contract deployment is going to look similar to what we looked at before but a little bit more involved. So we do the same thing where we check like hey um what is the bite code of this particular contract we're trying to deploy but here I'm also actually getting the nons from the request because we want to compute what the contract the new contract address will actually be. Uh right so that's the thing that we're going to then tell the second step.

Hey, you're allowed to change the contract to this new thing and this new thing is this contract address that we're storing locally in the database. Um, okay. So, we're going to we're going to compute the nons or we're going to get the nons from the transaction. We also get the sender from the transaction and we get the bite code from the transaction. Um, then we check as we did before, was this a approved? So, we're going to need to add this new contract to our list of approved uh contracts. Um, and then what I'm going to do here is actually check against GitHub that this particular hash. So this is the hash of the bite code was actually checked into the repo. Right? So we're going to use GitHub uh attestations to actually

verify that this went through our CI pipeline ideally was reviewed by a bunch of people potentially even auditors. They thumbs up and then the build system itself built that bite code and agrees with what I'm trying to do here as a developer. Um and then finally after we're done with that we're storing the address. So the get contract address here is just a function call to the um ether's implementation uh that computes the address from the sender and denance and this will be our new contract that we deployed and then later we're going to use it in our validate proxy upgrade to make sure that that's the only thing that we're allowed to like call the proxy admin with. So this is what this does. So this basically checks like that

the two transaction um to destination is a proxy admin. This is a thing we're going to use again the environments or secrets um u variables to set um and we're going to um get the new contract address from the transaction and make sure that thing actually is the thing that we stored in the database earlier. So this is what the fetch deploy does. It fetches that address. So if you look at like get uh new contract address this is taking our request right so this is the proxy call um it's computing the selector for the function that we're going to call here which is upgrade and call so we could have baked these in as like fixed things

but instead we could just use libraries and write natural code um then we're going to take the data from the transaction take the selector and make sure that the selector matches upgrade and call and And then later we're going to check that the input that we're calling it with is actually the address of the contract that we just deployed. Right? So like this is the thing that makes sure end to end that a we've deployed a contract whose bite code is in our CI pipeline and approved by an auditor and when we're calling this function upgrade um uh and call we're calling it with that address instead of some other potentially bogus address because like if we had hijacked this this would have

been just as bad. Okay, are we all on the same page? Okay, excellent. So now what we're going to do is we're going to just run the upgrade. Well, I guess before I do that, let me uh let me approve box v2. Um so this is the thing that I as the otterer will approve here.

Excuse me. Okay, great. Um, and then we're going to run the upgrade script. Okay, so this failed. Why did it fail? Well, we don't have a GitHub attestation. Um, and if we're trying to figure out, okay, what are we trying to find an attestation for? Well, we can look at our logs, and this will tell us, hey, we're fetching at the stations for this thing 5C blah blah blah. That's actually not

our V2. That's our EVO contract, or it should be. And indeed it is right. So we we we roguely tried to deploy this uh thing. this thing was ne never made it through CI even if it if it if it did like let's say the developers colluded to actually deploy this uh piece of code uh right and so like one way you can do that as a developer right is we can look at our workflow and instead of just publishing here the box v2 um byte code we could publish the evil box evil uh bite code hash instead right so like if if you're all malicious you

can compromise your CI pipeline this way. But at the very least um we should here have some separation with the auditors who have said that hey the thing that's on the allow list are just these two pieces of code right so this address here corresponds to our box v2 not our box evil so as long as one of those things says like um this is the actual contract that you're allowed to deploy then we should be good okay so I'm going to modify the upgrade script here to deploy v2 here Um, and now, um, it succeeded, right? So, what happened?

Well, it passed all the checks that we had here which are the uh for the first for the for the contract deployment is that this thing was actually audit approved and that there's a GitHub attestation corresponding to this particular contract. Um, okay. So, how do you know about the GitHub attestations? Well, here is actually something that I did a little bit earlier just to to be on time for this is I published that particular piece of code, right? So here is the workflow that we saw earlier um as part of this workflow.

We have an at the station. This is the at the station that was actually looked up and these are the artifacts corresponding to that thing. So I could just delete this. Let's see. Delete all logs. Maybe this will do. I'm not sure if that will delete our attestation. I don't think it would, but let's see. Okay. Um, so if we I'm going to rerun everything. Deploy.

And here I'm just going to deploy latest just so you don't see that um I'm making any of this up. Okay, so we're going to deploy again and then we're going to Ah, I did not air drop.

All right, there we go. And in the meantime, I'm going to start updating my other policy to upgrade latest. Okay, excellent. Okay. And lastly, let's run the upgrade script.

Great. One second. Oh, I forgot to clear my database earlier. So, it's only allowing me to deploy the thing that I've uh previously uh deployed. Okay. Okay, great. Um, so I guess the attestation stays alive forever. Um, I guess the only other bit that I could show you is modifying the thing and publishing an evil thing um won't work if we remove the again tweak this um one to an let's say an eight

um so that the auditor is the one that says like hey this is actually a different thing that we're approving. Um but you've already seen what that looks like. So there's no point in in in me going through it in in a lot of detail. The only thing that I want to kind of like uh maybe hone in on as the last bit is this is just normal code that you would write anywhere else, right? It's not like weird smart contract code. This is code that is doing things like making network requests to GitHub and fetching these attestations, right? So like this is just using if we look at the definition for fetch estations at at the top here we can see like what crates can we use? Well we can use pretty much anything that compiles to wom from the

rust ecosystem right as long as like obviously like we trust these the uh the these things but we can use cert for serialization deserialization. Um, and from our side, we have the GH tokens that we've again kind of encoded as secrets that you pass to to the WASM policy. So that when we make this request here, we're including things like the O header that includes my secret private at the station to uh private um uh access token uh so whatever GitHub's path stands for that I've earlier included as a secret here.

So here you can't actually read the secret because it's actually encrypted directly to the enclave. You can set it again to a newly generated thing. But the idea is you can encode secrets like this and make potentially secret requests to fetch data that is not public. Um and again you just write code as you usually would. Um, so I guess on that note, I think um I will stop here. Um, and just reiterate this is like to me a pretty like interesting use case because it's one that we've had customers come to us. We're like, hey, we've had um developers that have deployed contracts that are malicious. Can you

help us somehow deal with this? Um, and this is like one way you can do it. is like well I can help you but you can also write code like this that checks the deployments against you know what you've built and also like whatever protocol you may have with an auditor. So if you can have auditors plug into the system like that works pretty well. So instead of like having an environment variable here the way we did, you could imagine instead of making an HP request, you an auditor hub where you have the list of contracts that were approved by by this particular auditor and now like you kind of have an endto-end system without necessarily any of this manual stuff that I've used here for the demo.

Um, and on that note, I guess I'm happy to take any questions or give you back uh your time. All right. >> Thank you all.