Jared's dominance
Last year MEV bot operator jaredfromsubway.eth made headlines for generating significant profits from his sandwich strategy.
Intuitively, this didn't make sense to me. In my mind, sandwiching was a relatively low risk strategy with no asset exposure, and block builder auctions should drive profits to zero. Even if building a sandwich bot were technically challenging, the profits would justify the cost, leading Jared to quickly encounter fierce competition.
But that clearly wasn't the case and taking a closer look at some of his sandwiches gave me a clue what could've been going on.
Sandwich operator portfolio considerations
To execute a sandwich attack, the bot needs access to the asset the trader is selling, and this asset typically needs to be held in inventory for the bot to remain competitive. Bots don't mind holding stablecoins and ETH, but volatile shitcoins like $CHIB and $WALZ are a different story. The inevitable drop in price can erase all profits and jeopardize the entire operation.
One could hedge this risk by shorting these tokens, but that's only viable for tokens listed on futures markets and with sufficient liquidity. Additionally, the funding fee needs to be taken into account.
As an alternative to holding the asset before the sandwich attack, on-the-spot acquisition can be a viable option in some cases, provided there's deep enough liquidity on a different market than where the sandwich is occurring. The problem is that shitcoins usually lack liquidity, making it difficult to stay competitive by buying them on the spur of the moment from a different venue.
It's worth noting that collateralized lending through platforms like Aave could potentially solve this, as borrowing and repayment could occur within the same block. However, it's uncommon for newly launched shitcoins to be listed and available for collateralized borrowing due to their volatility, lack of sustained demand, and the risk of oracle manipulation in low-liquidity environments.
Accounting for these risks and trade-offs, most bots only sandwich trades that involve stablecoins, less volatile assets, or other liquid assets they can easily hedge.
But not Jared ...
Jared's risk-on sandwiches
Jared's most profitable sandwiches were those targeting trades selling "shitcoins". This strategy faced little to no competition, allowing him to capture the gains directly instead of auctioning them off to block builders.
However, a question remains: how could Jared afford to maintain an inventory of these shitcoins?
Robert Miller shed light on Jared's strategy in a tweet, pointing out that Jared bought his tokens early, before they pumped. By already being significantly in profit on these shitcoins, Jared wasn't risking anything by keeping them in his sandwich portfolio - he was essentially playing with house money. Other sandwich operators had no chance of catching up unless they had also acquired the tokens early enough.
Supply and demand
If Jared's rival sandwich bots had access to a sufficient amount of shitcoins without actual exposure, they could compete with him, taking a slice of the profitable pie. This represents the demand side for shitcoins!
On the other side, there are shitcoin holders who are simply holding their tokens and might be enthusiastic about earning additional yield on their coins. This is a potential supply side!
So why didn't these two sides come together? In other words, why didn't shitcoin holders lend their assets to sandwich bots?
Currently, no market exists to facilitate this operation, and there are several aspects to consider regarding the feasibility of such a market. For one, even if it's technically possible to create it, a key question is whether the spread between lenders and borrowers could be narrow enough to support a liquid market. In other words, can an interest rate that satisfies both parties be agreed upon?
Furthermore, even if a mutually agreeable interest rate can be established, the profitability of the market itself must be considered. Is there sufficient incentive to create and maintain such a platform?
While these questions are important, they fall outside of the scope of this article. Instead, we will focus on the technical feasibility of the lending operation itself.
The core issue lies, as with any other lending scenario, in how to ensure the borrower doesn't run away with the money.
For strategies that complete in a single transaction, this isn't problematic as they occur in an unbreakable atomic unit. An example is atomic arbitrage, where a flash loan is used to borrow and repay funds within a single transaction.
However, sandwich attacks don't occur within a single transaction, so the same guarantees don't hold. Sandwich attacks typically involve at least three separate transactions, meaning the lender would need some assurance that the sandwich operator would repay the loan later in the block. This is not trivial to guarantee on blockchains such as Ethereum, as the chain's rules don't recognize a bundle of transactions as a cohesive unit where sequence and inclusion should be preserved, and where failed execution of one part can roll back the whole sequence of transactions.
There might, however, be some ways to work around these traditional guarantees. Let's explore them in the following section.
Intrablock Lending
In the previous section we identified potential market demand for a protocol that would facilitate asset lending within a single block. We'll refer to this concept as intrablock lending, an idea previously explored by Santiago Palladino in 2021 and later revisited by Alex Watts late last year.
We will investigate a version of intrablock lending without collateral requirement and explore some ways of providing a guarantee that a borrower will return the assets at the end of the block under certain conditions. The first one is inspired by sandwich bots, who also need some confidence that their set of transactions won't be picked out and exploited.
Bundle-Based Intrablock Lending
Vulnerability of sandwich attacks
A sandwich attack works by front-running a victim's trade. The attacker buys a significant amount of tokens before the victim, inflating the price. The victim then buys tokens at this inflated price, thus increasing the price further. Finally, the attacker sells the previously bought tokens and profits from the price increase.
During this process, the sandwich bot exposes itself to a potential attack vector. A second attacker could sandwich the bot's first transaction and the original victim transaction, effectively turning the predator into prey.
However, the ability to exploit a sandwich attack is not available to just anyone. It requires an entity with sufficient privileges to reorder transactions in the next block.
Block builders possess this capability. Yet, if they plan to stay in the game long term, they have no incentive to exploit sandwich attacks. The original attacker shares a portion of the revenue with them, so exploiting would be akin to killing the golden goose.
Given this context, could a similar strategy be applied to intrablock lending?
Design
Let's consider how intrablock lending could be implemented using bundles.
- Lender locks tokens: The lender (e.g., a shitcoin holder) locks their assets into a contract and specifies the fee at which their assets can be borrowed.
- Borrower locks an asset for fee payment: To discourage spamming, some assets can be locked and later used to cover the cost incurred by lending transactions.
- Bundle submitted to the intermediary: The borrower submits their bundle to the intermediary with details for how much to borrow and in which asset. The intermediary facilitates the transactions between the lender and borrower.
- Intermediary checks validity of submission.
- Original bundle wrapped into a new bundle: The intermediary repackages transactions from the submitted bundle into a new one. In this new bundle, the original bundle is frontrunned by a transaction transferring assets to the borrower and backrunned by a transaction checking all borrowed funds are returned.
- Wrapped bundle verified: The bundle is simulated to check the borrower does indeed return the borrowed funds.
- Wrapped bundle sent to the builder: The bundle is sent to the builder with the condition that the whole bundle should fail if the last transaction fails.
Now lets put on our black hats ...
Exploit or not to exploit, that is the question
Exploitation by a builder
While there's no absolute guarantee that a block builder will respect the submitted bundle or that a validator won't leak it, strong economic incentives discourage intentional exploitation, similar to the dynamics we observed with sandwich bots.
If a block builder exploits a bundle, they risk more than just losing the client they've exploited. Other clients, fearing they might be next, could abandon the builder, potentially resulting in significant revenue loss. This outcome is generally not in the builder's best interest.
However, this incentive structure only holds for builders planning to remain operational for an extended period. If the immediate gains from an exploitation outweighs potential future profits, a builder might choose to defect. Consequently, only top-tier builders with substantial reputational and financial stakes can be considered reliable participants in this system.
It's important to note that the potential gains from exploiting intrablock lending are significantly higher than those from exploiting sandwich attacks. In sandwich attacks, a malicious actor can only capture the slippage, whereas in intrablock lending, the entire pool of available assets could be drained.
As of now, it's unclear what the maximum safe balance for lending might be to minimize the risk of exploitation by malicious builders or validators. To gain better insight into this limit, a study of the economic, social, and legal implications would be necessary.
Despite these risks, with intrablock lending sandwiching could theoretically generate more overall profits for builders and validators than it does today. By fostering increased competition and auctioning off more value, it could lead to a more dynamic market compared to a scenario where only a single actor (like Jared) dominates.
Exploitation by the intermediary
Facilitating intrablock lending requires an intermediary to provide services to borrowers by attracting and safeguarding liquidity, as well as constructing transaction bundles. This intermediary needs full access to all available liquidity and the transactions for which borrowers want to acquire assets. Given the potential for significant profit through exploitation of either or both of these responsibilities, robust checks and balances are necessary to keep the intermediary accountable.
To discourage defection, the intermediary must stake something of greater value than the potential profits from exploiting the system. There are several approaches to consider:
- Monetary Stake: If the stake is monetary, it creates a clear limit on the system's liquidity capacity. However, this limit may fluctuate with changes in the underlying asset values. Simply staking a significant amount isn't sufficient; a comprehensive system to monitor and evaluate the intermediary's behavior is also required. Furthermore, finding an actor willing to risk such a substantial amount of capital could prove challenging.
- Reputational Stake: Alternatively, the intermediary could stake its reputation, similar to the approach taken by builders and relays. For instance, a MEV-Boost relay could potentially fill this role, leveraging its existing reputation and incentives to collaborate with builders. However, care must be taken not to overburden or dilute the relay's existing reputational commitments.
- Trusted Execution Environment (TEE): Another approach is to implement the intermediary within a Trusted Execution Environment. This could provide a certain level of confidence that the intermediary cannot exploit either the lender or the borrower. However, it's important to note that TEEs are not infallible and can be exploited.
Among the three approaches reputation and TEE based ones seem the most promising. Further research into these approaches, including potential hybrid solutions, would be necessary to assess their viability.
Reorgs and missed slots
In Ethereum's Proof-of-Stake (PoS) system, reorgs could pose significant risks to intrablock lending protocols. During a reorg, transactions from abandoned blocks may become visible to the network, creating a window for potential exploitation. An attacker could potentially cherry pick these leaked transactions, including those that transfer assets while excluding return-check transactions, thereby manipulating the intended lending process.
Simply restricting transactions to a specific block number proves insufficient as a safeguard. In a reorg scenario, a different validator could construct a block with the same number, potentially incorporating leaked transactions. This vulnerability necessitates a more robust approach to transaction timing and validity.
To counter these risks, it's crucial to tie transactions to specific slots rather than just block numbers. Although direct access to the slot number isn't available in the execution layer, it can be indirectly accessed via block.timestamp, which in PoS is strictly determined by the slot number.
Using block.timestamp as a proxy for slot number can help ensure transactions are valid only for the intended slot. This prevents exploitation of intrablock lending in the event of transaction leakage during the reorg.
The bottom line is that the intrablock lending with bundles is possible, but there are some pitfalls that present significant risk and cost.
- Trusted roles: The system heavily relies on intermediaries and the block builders where all need to have a substantial stake in the system for it to work as intended.
- Top builders only: Only top-tier builders with established reputations are suitable for this role. Their existing reputation serves as a deterrent against malicious behavior, as any exploitation could jeopardize their business. Although this implies that the system would only function for blocks created by these top builders, it's worth noting that the top few builders are responsible for constructing the vast majority of blocks.
- Intermidary with reputational/monetary stake or inside a TEE: Intermediary could be an existing actor with solid reputation, like MEV-Boost relays, or could leverage the power of TEEs and move trust assumptions elsewhere. Alternatively, monetary stake is possible, but could introduce more complications than benefits.
- Lending limited to once per block. Although it is difficult to say how important this feature would be in practice, intrablock lending via bundles would be limited by lending to once per block, as intermediaries can't control block construction.
Intrablock lending via bundles presents the concept in its simplest form, although with some operational risks. Now, building on this, let's explore an alternative approach that attempts to mitigate some of these mentioned risks.
Block Builder-Facilitated Lending
An alternative approach to intrablock lending involves the block builder directly facilitating the process as part of its regular operations. This model shares many similarities with the previously described bundle-based approach, with the key difference being that the intermediary and the builder are the same entity, eliminating the need for bundles.
In this scenario, the block builder can directly insert and order transactions within the block, offering several advantages and considerations:
- Reduced Risk of Misbehavior: By combining the roles of intermediary and builder, the number of actors who could potentially exploit the system is reduced. While the total risk remains similar, it's concentrated in a single, more easily monitored entity.
- Liveness Tied to Builder's Market Share:
- Liquidity and service availability are specific to the particular builder.
- The liquidity limit depends on the value of the builder's reputation.
- Only one of the top builders can offer such service.
- If the builder drops off charts so does the service.
- The service is only active when the builder wins the PBS auction.
- Increased Lending Frequency: Unlike the bundle-based approach, the builder can facilitate multiple lending operations within a single block, potentially increasing the system's efficiency and utility.
- Economic Considerations: For top builders, the decision to offer this service depends on its profitability compared to other opportunities. Given the lucrative nature of block building, the returns from intrablock lending must be substantial to justify the required resources and attention.
This approach streamlines the intrablock lending process by eliminating the need for a separate intermediary, potentially increasing efficiency and reducing points of failure in the system. Nevertheless, it still leaves a lot to be desired, some of which is addressed with the following approach.
SUAVE Approach
While we previously considered TEEs for intermediaries, it's worth exploring their potential for block builders as well. Flashbots' SUAVE project offers a promising solution: a programmable block builder operating within a TEE. This approach introduces several interesting aspects to intrablock lending:
- Shifted Trust Assumptions: The primary trust shifts from the block builder to the TEE manufacturers. This reliance on hardware security means the integrity of the system depends on the manufacturer's ability to produce secure chips and maintain their safety over time.
- Streamlined Integration and Maintenance: SUAVE's infrastructure allows for simple integration and low-cost maintenance. Developers need only write the lending logic once, then leverage the existing SUAVE framework for execution.
- Enhanced Liveness and Accessibility: The viability of intrablock lending services expands beyond individual builders. Any builder utilizing SUAVE can potentially offer these services, tying the system's liveness to the collective market share of all SUAVE builders rather than a single entity.
- Security Considerations: TEEs are not infallible and exploits of TEEs, though rare, have occurred.
SUAVE's TEE-based approach offers enhanced security and accessibility for intrablock lending. While it mitigates some trust issues and could increase participation, it also introduces new concerns around hardware security and risk assessment that require careful consideration.
Final Thoughts
Summary
This writeup explored the concept of intrablock lending through the lens of Jared's sandwich strategy. It began by illustrating how intrablock lending could potentially redistribute some of Jared's profits. Subsequently, various implementation approaches were discussed, each with distinct benefits and limitations.
While technically feasible, building such a system presents significant challenges and considerations. We examined three potential approaches:
- Bundle-Based Method: Offers simplicity but depends heavily on trusted intermediaries, which introduces dependency and potential risk.
- Block Builder-Centric Approach: Streamlines the process by integrating the intermediary role with the block builder but ties the service to the market share of specific builders, which may limit its applicability.
- SUAVE's TEE Infrastructure: Shifts trust assumptions away from traditional intermediaries to TEEs, potentially increasing accessibility and security, but introduces concerns about hardware security and the reliability.
Future directions
Future research should focus on quantifying risks, exploring additional use cases, and comparing intrablock lending with alternative financial instruments. The technical challenges, particularly in transaction bundling and TEE security.
Additionally, for the product to be successful, several market-research questions listed below should be addressed:
- Economic Viability: Can borrowing rates be agreed upon that satisfy both lenders and borrowers? Would the potential returns justify the risks and attention span to attract lenders?
- Market Dynamics: Will the trading volume of volatile assets ("shitcoins") on Ethereum remain significant enough to justify this service? How might changing market conditions affect the viability of intrablock lending? Could this concept be applied to other ecosystem, such as Solana?
- Alternative Use Cases: Beyond sandwiching, are there other potential applications for intrablock lending that could broaden its utility and appeal?
- Collateral Requirements: How might the introduction of full or partial collateral requirements affect the system's security and efficiency?
Conclusion
Intrablock lending pushes the boundaries of what is possible within a single Ethereum block. But while it's exciting, I believe practical implementation should be approached with caution.
The goal of this article is to spark a conversation about the possibilities and challenges of intrablock lending, rather than to advocate for immediate development. As the DeFi landscape continues to evolve, it will be interesting to see if, and how, concepts like this shape the future of decentralized finance.
How would you use intrablock lending?
Big thanks to Markus, Alex Watts and Eden team for review and suggestions.
Disclaimer: Some readers might frown upon my choice of a use case for intrablock lending, raising moral concerns about sandwiching. I acknowledge that sandwich attacks harm user experience and reduce market efficiency, they are used here merely as a hypothetical example of intrablock lending's utility, given the absence of other clear use cases. Another disclaimer I want to make is that by no means I am trying to deminish the sophistication of Jared's operation outside of shitcoins. While I speculate that his success is largly due to the aforementioned strategy, it is likely not the sole reason.