Back-Testing Transaction Policies with Cryo & Analysis of Preventable DEX Slippage

Misconfigured transactions, user errors and malicious transaction requests are responsible for a large amount of preventable losses in crypto. Automated transaction policies at the wallet or RPC layer are one approach to mitigating these losses. In this article, we present a library for decoding transaction payloads to detect max slippage of DEX transactions on Uni V2, V3, and Universal Router, a policy implemented as RPC middleware, and a method for using Cryo with Python to back test the effectiveness and calculate preventable slippage of previously executed trades

What Is A Transaction Policy (and why)?

Smart contracts define the permissible actions of a protocol; however, permissable actions are very different from optimal actions. This gap leads to scenarios where decentralized application users are vulnerable to exploitation due to transaction misconfigurations.

This isn’t a flaw of smart contracts, but it highlights a gap in the traditional Web3 stack of application, wallet, contracts, and neutral RPCs. Many user protection features are ill-suited for the smart contract layer as they would be overly restrictive and break the open, composable nature of DeFi. And while applications and wallets can help educate and guide users towards safe transactions, they can benefit from an additional external validation of the user’s intended actions.

We introduce transaction policies as an RPC middleware to perform the validation and act as a check on transactions coming from wallets. This middleware is supported by a robust policy framework which interprets complex transactions, adds critical context, and takes action to protect users from mistakes or malicious activity.

By including opt-in rules on the RPC layer we can preserve the neutrality of underlying protocols while enabling protections chosen by the user.

Slippage Detection Transaction Policy

In the Shield3 framework, policy modules are constructed using Banyan, a policy language forked from AWS Cedar and tailored for Ethereum transactions. These policies define the logic to decode, validate, and route transactions safely.

For example, the policy detailed below is designed to determine the potential risks and outcomes of broadcasting a swap transaction with the Uniswap Universal Router. It considers factors like maximum allowable slippage, triggering additional confirmations or halting transactions if needed. These policies can also be configured to reroute transactions to private pools to mitigate public mempool manipulation risks.

Validation Example

This transaction is a an example of the worst case scenario in transaction misconfiguration. Looking at the decoded input data we can see the minimum amount out for the swap is 0, allowing an MEV bot to temporarily manipulate the pools surounding this transaction to extract a profit, leaving the trader with nearly 0 DAI in exchange for their 45,000 USDT.

On a network fork taken at the block number of this transaction, we can simulate broadcasting this transaction to an RPC URL with the policy middleware enabled and we receive the following message:

With this result the transaction would not have been broadcast and would have saved the trader from the $45k USD loss.

Evaluating Policy Efficacy

In the above scenario it is trivial to detect the preventable loss of the transaction if the user’s wallet had been connected to a protected RPC. However, to assess the efficacy and potential impact of this policy, we can analyze historical trade data from the Uniswap router contracts. By identifying all transactions where traders incurred suboptimal pricing and simulating these transactions with the policy engine, we can learn how widespread swap transaction misconfiguration is, and what could be prevented in the future.

Gathering Historical Data

With Cryo we can gather historical logs for transactions with event signatures matching swaps on the Uniswap routers, and then use the Uniswap pool addresses to validate the results.

For a full walkthrough of the analysis see the article here: https://hackmd.io/bTqWXR3LRjyO9e38VZtKvA#Gathering-Historical-Data

Methodology for Analysis

The Contextooor Library provides utilites and code snippets to the policy engine execution step.

In order to analyze the maximum potential slippage given an encoded transaction payload, the library performs the following steps:

1. De-serialize the transation
2. Identify the router version & ABI based on the contract address
3. Decode the trade path
4. Using the token addresses in the trade path, call the correct factory to get the pool address
5. On the pool contract, call getReserves or slot0 to derive the optimal rate
6. Take the inverse of the optimal rate if token addresses are not ordered
7. Aggregate the rates together to provide the least amount of slippages possible. Sometimes paths will diverge, and often times paths perform similar swaps concurrently. All paths with the same start token are aggregated by weighted average (weighted by amount out)
8. Compare the path’s optimal rate to the specified amount out and amount in found in the input data.

Proposed Future Enhancements

The library and analysis method are currently tailored from the Uniswap router contracts. In the near future the policy & libraries will be updated to support additional AMMs and swap types.

Conclusion

This article outlines the role of policy frameworks in optimizing user interactions and preventing exploits of misconfigured transactions, a well as techniques for testing policies against historical datasets of transactions using Cryo.

Further Reading and Resources

• Banyan Middleware Library: https://github.com/0xShield3/banyan
• Contextooor: https://github.com/davidthegardens/contextooor
• Automating Compliance & Security with Shield3: https://medium.com/block-science/automating-compliance-and-security-with-shield3-3174f6be3fcc