8ef061fd758242f34ea562e3861aeb6a3d9377d7
[copied from exact same reasoning with execution code-checking] I was inspired to do this because, when disabling the slither check for the staticcall when calling the callback verifier, I realized it's not clear from the same contract that we have already checked for contract code existence when setting the verifier. This made me feel uneasy, as this contract can then not stand alone and must rely on the higher level contract to safely check for code existence, otherwise the staticcall is unsafe. Keeping this logic in a separate contract seems error-prone to me, as we may remove the check for code existence without immediately realizing the implications of doing so. For this reason I have organized it as follows: - Logic/tests relating to proper roles/access control in the main TychoRouter. - Lower-level logic/tests that check contract validity before setting the callback verifier in the CallbackVerificationDispatcher
Tycho Execution
TODO: add banner
Tycho Execution makes it easy to trade on different DEXs by handling the complex encoding for you. Instead of creating custom code for each DEX, you get a simple, ready-to-use tool that generates the necessary data to execute trades. It’s designed to be safe, straightforward, and quick to set up, so anyone can start trading without extra effort.
Contract Analysis
We use Slither to detect any potential vulnerabilities in our contracts.
To run locally, simply install Slither in your conda env and run it inside the foundry directory.
conda create --name tycho-execution python=3.10
conda activate tycho-execution
pip install slither-analyzer
cd foundry
slither .
Description
Languages
Rust
90.1%
JavaScript
5.9%
Python
3.6%
Solidity
0.4%