 Hello everyone, welcome to this lightning talk about the unspecified evaluation order in Solidity or how our colleague, Tinan Richard, who unfortunately couldn't make it to Bogota, won the underhanded Solidity Contest. The goal of the underhanded Solidity Contest is to write harmless or unsuspicious looking smart contracts with hidden bugs or pitfalls, thereby exposing weird behavior in Solidity in a fun way. Let's jump right in. Here's an example from the Solidity docs. What it's basically saying is the evaluation order of expressions is not specified. If function f takes two arguments which refer to function calls to functions g and h, it's unclear in which order they are evaluated. Either function g is evaluated first or function h is evaluated first, but we can never be sure which one. Obviously, function f is evaluated last because it depends on the result of the other functions. Let's consider this example. Let's say we call a function with an argument of two. What's the correct result here? Is it four or five? Well, it depends on the evaluation order and it's not really specified for the Solidity compiler. This is not unique to Solidity. Insufficient specification of expected behavior can be found in all kinds of different programming languages. A big adage for everyone involved. Does this matter in practice? Yes, of course. It does as it can lead to unexpected behavior results. By analyzing the code generator of the Solidity compiler, our collector found three cases of unusual evaluation orders which this talk is about. Yes, most of the time evaluation order is as expected from left to right, but not always. The first two examples are the opcodes admod and mulmod. Here, the evaluation order surprisingly is from right to left. If we evaluate f of two, it first evaluates a, increments it by one and only later evaluates the first argument which results in admod with argument three instead of two as you might have expected. Interestingly, this is actually documented in the Solidity. However, not where you expect. In Solidity, there are currently two ways on how code can be compiled. The default code generation and the new code generation via the UL IR pipeline. In the documentation describing the UL pipeline, it's actually documented that here the evaluation order will no longer be from right to left, but also left to right. The most interesting one is the order of evaluation inside events. This one is really special. The parameters are evaluated in a bizarre order. First, the indexed parameters are evaluated from right to left. Second, the remaining parameters are evaluated from left to right. Wow, who knew that? With SolidityDef has this in mind when coding. No one, right? This can lead to really strange or unexpected behavior. And this is what Tinan leveraged and used for his submission to the underhanded Solidity Contest 2022. He wrote a simple decentralized exchange where liquidity providers and the admin shared the collected fees. In a legitimate dex, the admin shouldn't be able to screw over the liquidity providers by changing the fees afterwards. This is the heart of Tinan's submission. Looks legit, right? What's wrong here? Let's see. So the admin calls functions change admin fees once he wants to update the fee. It looks like function retire all admin fees called first, which execute claim fee and distributes the fees based on the old fee amount to the liquidity provider before calling set new admin fee, which updates the admin fee to the new admin fee. But remember what we just learned before? Indexed events are evaluated from right to left. So actually, set admin fees evaluated first, so the fee is updated and only afterwards retire old admin fee distributes the liquidity fee to the liquidity providers based on the new fee. Really surprising. So one important thing to mention here, the Solidity Compiler asset has two ways to compile code. The default way and the new way using the Yule IR pipeline. In the Yule IR pipeline, this is no longer true, there the function evaluation order is strictly from left to right. However, per default, the Solidity Compiler uses the old code generation, but this may change at any time in the future. Thanks a lot. Happy to take any question. One minute left.