MiloTruck

Background

In the current market, yield farmers have only 2 options: either deposit into a yield aggregator that completely manages their money for them, making all the risk assessments and moving their money between protocols, or just run everything on their own, moving their money continuously between protocols, at most using an auto-compounder on a single vault for some automation.

However, not everyone has the same risk profile and thus fully managed aggregators won't fit everyone, while on the other hand there's a big market of people that don't like constantly having to manage their positions and shuffle their funds. These two options are the 2 extremes, either fully managed or DYI.

Because of this I believe there's a market for users that want some automation while being able to set their own risk profile.

Idea

I propose a protocol where users deposit funds along with policies on how those funds can be deployed, and then the protocol optimizes their position within those boundaries and automat

Optimized lending protocol for redeemable assets

Currently a significant portion of usage across all lending markets comes from carry trades between an asset and their derivatives.

To explain how this works let's assume that on AAVE borrowing ETH costs 1%, but stETH yields 3%. This opens up a trade where you deposit stETH, borrow ETH, swap it for stETH and repeat the trade again, looping the position and arbing the rates. In this position you earn 3% but pay only 1%, so you're earning 2% net.

Some examples of these trades in the wild are:

Flux finance, a compound fork purely focused on borrowing stablecoins against treasuries for carry trades
AAVE, which has a 5.8bn stETH and ~1bn weETH, both used for looping against ETH. Together, these account for ~45% of aave's TVL
Morpho, which hosts users looping sUSDe against DAI
Compound, which hosted large arb trades against cbETH

Overview

Syncing an Ethereum node is largely reliant on latency and IOPS, I/O Per Second, of the storage. Budget SSDs will struggle to an extent, and some won't be able to sync at all. IOPS can roughly be used as proxy of / predictor for latency. Measuring latency directly is arguably better.

This document aims to snapshot some known good and known bad models.

The drive lists are ordered by interface and then by capacity and alphabetically by vendor name, not by preference. The lists are not exhaustive at all. @mwpastore linked a filterable spreadsheet in comments that has a far greater variety of drives and their characteristics. Filter it by DRAM yes, NAND Type TLC, Form Factor M.2, and desired capacity.

For size, 4TB is a very conservative choice. The smaller 2TB drive should last an Ethereum full node until at least sometime 2026, with the [pre-merge history expiry](https://hackmd.io/@hBXHLw_9Qq2va4pRt

 # Appendix
 The following sections contain reference material you may find useful in your
 Cairo journey.
 # Appendix A - Keywords
 The following list contains keywords that are reserved for current or future use by the Cairo language.
 There are three keyword categories:

	from attrs import define


	@define
	class Tick:
	fee_growth_outside: int

	def cross(self, fee_growth_global: int):
	self.fee_growth_outside = fee_growth_global - self.fee_growth_outside