This was the most elegant solution we could come up with at the moment for having the proper adapter in the builder.
Notes:
- The default adapter bytecode in tycho-simulation is still loaded at compile time.
- If the adapter bytecode is passed to the decoder, it will be loaded dynamically at runtime and used instead the bytecodes in tycho-simulation.
- The adapter bytecode is used in the builder to get capabilities and thus spot prices before returning the state, so just overwriting the adapter in the state is way too cumbersome. We went with this solution since it was the lesser evil, even though we know it leaks VM-specific info to non-vm protocols (which was already being done anyway with the balances).
* feat: Pass adapter contract to decoder
This was the most elegant solution we could come up with at the moment for having the proper adapter in the builder.
Notes:
- The default adapter bytecode in tycho-simulation is still loaded at compile time.
- If the adapter bytecode is passed to the decoder, it will be loaded dynamically at runtime and used instead the bytecodes in tycho-simulation.
- The adapter bytecode is used in the builder to get capabilities and thus spot prices before returning the state, so just overwriting the adapter in the state is way too cumbersome. We went with this solution since it was the lesser evil, even though we know it leaks VM-specific info to non-vm protocols (which was already being done anyway with the balances).
* feat: Take a struct of vm_attributes instead of just adapter path
So that we don't need to change the interface in the future
* chore: remove comment - we are no longer blocked
This is fixed with the latest change to pass adapter contract to decoder
* feat: Use DecoderContext instead of VMAttributes
- More easily extendable
- Doesn't break the existing decoder interface
---------
Co-authored-by: TAMARA LIPOWSKI <data.lipowski@extaccount.com>
