Rust-Proofing Your Chains: A Deep Dive into Secure Rust Development Workflows

DeFi Security Summit at Devconnect Argentina 2025 · November 2025 · 4:45

Aellison Cassimiro, formal verification engineer at Runtime Verification, argues that Rust's growing role in blockchains demands secure development workflows. He covers critical security considerations for contracts and infrastructure, including design, methodology and tooling, and shares practical tools for hardening Rust code drawn from the company's experience on Solana and Stellar Soroban.

Speakers

Topics

From DeFi Security Summit at Devconnect Argentina 2025, hosted by DeFi Security Summit.

Transcript

Hello everyone, my name is Alison and I will be talking about securing uh your host code for your projects on and off chain. So it would be a controversial statement if I said this a couple of years ago, but I can now confidently say that Russ is the new backbone of uh web 3. So regardless of the protocol, if you use blockchains, if you are a web 3 user, it's very likely that you use the protocol or a entire chain that has it its smart contracts or its entire infrastructure written in Rust. So it's no wonder uh why uh Rust is great because of the speed and simplicity of

the code as well as the safety with special highlight on the memory safety that you need to have this reliability of systems that will be running all the time for a long time. Uh so no wonder why people are using it and the proof of it is the TLV that you have for all the blockchains involved. Uh Senena alone counts for $82 billion. uh it's easily uh it's a easy claim to prove that it's more than uh 100 billion billion USD in TLV between these blockchains and >> yeah if you are a user of web3 you are a part of this uh yeah one of the challenges that we face though is that

not all that glitters is gold so if was perfect you wouldn't have this uh map of outages in Solena or you wouldn't be having so many so much money being lost in hacks in the previous few years. Um, and that's because we are all human. We are all we developers, we are all human. We make mistakes. Uh, no wonder. So my tip for you in this presentation is that uh, understand yourself and you understand your enemy. That's probably some zoo. You can correct me outside. Uh I would say that for you to understand yourself a great concept uh to be clear about what you're trying to do with your protocol is to raise the invariance of

it. So invariants are things that are supposed to stay the same at all times. It's not supposed to change. If I talk about invariants here right now on Earth, I would say that gravity is an invariant. If I jump, I come back down. If I'm writing a protocol that is going to take Saul and wrap it and give you a token for it, uh I can say that an invariant for this protocol is that for every uh Saul that you provided, you will mint a uh wrapped version of that. Um so this is an invariant. The threat model part comes at identifying the ways that your protocol can be hurt mainly through the means of how can I interact with it. So evaluate the entirety of your code, your protocol, your

infrastructure, your smart contract and see how can I interact with it and what can I achieve with these interactions. The idea is to unite these two approaches to create your tests. So the tests are not just about uh making sure that what you developed supposed to work as it intended. You are supposed to look for corner cases when developing your tests. uh use invariant and threat modeling for that and then you can unite these concepts with your preferred meth uh methods of testings which by the way should be all of this and more if possible. Um yeah don't shy away from using multiple techniques as I said and mainly do not shy away from using multiple tools as

well and multiple strategies. So uh whenever uh we see developers out there creating projects they are uh very very frequently they focus on picking a tool a single tool for a testing harness for example and doing everything into that tool. It's a valid approach uh but nothing stopping you from putting as many tools as you need or want into your protocol in your uh project to test it. Uh, one very easy thing to do is to use share tooling for Rust. For example, the cargo uh, tools uh, that's just a line of in your terminal that can provide you with some quick and easy uh, low hanging fruits, long low hanging issues in your

project for you to fix. The idea is that you're going to explore the tools that are available for your ecosystem uh and mix them with uh whatever is available for us as well to achieve the best test coverage that you can. So do not shy away from any tech techniques, do not shy away from uh multiple tools and do not let your chains rest. Thank you. Thank you.