Why Does Everyone Else Catch the Opportunity While I Read the Postmortem?

There has been another security incident in crypto.

I came across an on-chain postmortem. Its author estimated that someone had made about $3.47 million from ETH price differences amid the turmoil. Staring at that figure, I had the same familiar thought:

Why does everyone else catch the opportunity while I read the postmortem afterward?

This time, I had to look into it. I wanted a script to keep watch for me. Even a small share of the opportunity would be something!

But further down, another line in the post stood out: according to the author, the address that made the most had already deposited 37 million USDC in Aave beforehand. The $3.47 million figure was also the author's estimate, before on-chain transaction fees.

That cooled my enthusiasm a little. Their capital was already in place. I had not even worked out how the opportunity arose or what I should be watching.

So that was where I would start.

I gave the original post and my ideas to my Codex agent:

Help me design a tool to run on FMZ. First, monitor price differences for me and investigate the conditions when you find a lead. I will confirm when to borrow and sell tokens, decide whether to add collateral and continue borrowing and selling, and finally buy back and repay in batches.

In this article, I will follow the original post's reasoning and work through that process.

Someone Is in a Hurry to Buy ETH. Can I Sell It to Them?

According to the original author, someone was urgently converting assets such as USDT into ETH. Those large purchases pushed up prices in particular on-chain markets. Exchanges had suspended withdrawals, so cheaper ETH could not immediately be moved on-chain.

From another perspective, the trade is straightforward: the buyer is willing to pay more in stablecoins to get ETH quickly. Anyone who can supply ETH at that moment has a chance to sell at a favorable price. The phrase "selling stablecoins cheaply" refers to accepting a worse exchange rate when converting them into ETH.

Arbitrageurs sell ETH into those expensive markets, economically supplying what the buyer needs and taking the other side of the trade. Transactions typically take place through DEX pools; the two people do not have to be matched directly. The opportunity comes from the premium paid by that urgent buying demand. How Uniswap works

But what if I do not have any ETH?

Then I can post collateral, borrow ETH, and sell the borrowed tokens. No inventory? Borrow against collateral and sell short. Aave provides a way to borrow on-chain spot assets. Whether the trade makes money still depends on the cost of buying them back and repaying later.

The next line in the original post turns this operation into a loop:

Deposit the stablecoin proceeds back in, then keep borrowing and selling.

Add the sale proceeds as collateral and, if borrowing limits, liquidity, and other conditions permit, borrow another batch of ETH and sell again. Borrowing and selling can continue in successive rounds, but the ETH debt accumulates too. The position is not fully closed until the tokens are bought back and the debt is repaid.

Consider a hypothetical example, assuming sufficient collateral is already in place and the borrowing conditions permit it. First, borrow 1 ETH and sell it for 2,600 USDC. Add the proceeds as collateral, then borrow another 1 ETH and sell that for 2,600 USDC as well. Total sale proceeds are now 5,200 USDC, and the debt is 2 ETH plus interest.

If the ETH can later be bought back for 2,300 USDC each, buying back the principal costs 4,600 USDC. The difference between sale and purchase prices is 600 USDC, before interest and fees. If the buyback price rises to 3,000 USDC, that difference becomes a loss of 800 USDC, with fees still to be accounted for.

One distinction matters here: Aave's oracle price is used for valuation and risk calculations; it is not a price at which you can sell tokens. If the oracle values ETH at $2,300, that does not mean I can buy 1 ETH on Aave for $2,300. Aave borrowing guide

Once that is clear, the script's job becomes concrete: find where ETH can be sold at a premium, while also tracking how many tokens I owe and how much it would cost to buy them back.

Watch for Me First, Then Tell Me Whether the Trade Is Feasible

If my phone rings in the middle of the night and only says "ETH price difference detected," I still have to get up and check several different pages.

What I want to save is the time spent finding the right interfaces, checking conditions, and calculating fees on the spot.

The initial monitoring scope is Binance, OKX, Uniswap on Ethereum, PancakeSwap on BNB Chain, and Aerodrome on Base. I want to watch markets related to both BTC and ETH, but each asset and pool needs to be verified. Different wrapped assets cannot be treated as the same token just because their names look similar. For execution, the first version will focus on borrowing ETH through Aave on Ethereum.

After detecting a significant deviation, the program should investigate using the quantity I intend to trade: how much the sale would actually return, what the fees would be, whether Aave still allows the collateral and borrowing operations, whether enough tokens are available, and how much my account can borrow.

CEX quotes serve as references for detecting deviations; DEX quotes determine the terms of actual execution. The program must also check whether the quote stablecoin itself is behaving abnormally. I am looking for ETH that has been bid up in a particular market. The alert should separately show "how much higher the price is than the reference" and "how much it would cost to buy back now," so I can see whether this trade still requires waiting for the price to fall.

Only after those conditions are clear is it worth waking me up.

After the First Sale, I Still Need to Decide Whether to Continue

Next, the FMZ page should show me a concrete plan: how much ETH to borrow, where to sell it, the minimum proceeds I will accept, the estimated fees, and the cumulative token debt after execution.

The program should borrow and sell according to that plan only after I confirm. If the market has moved outside the approved price range, it should obtain a fresh quote. FMZ interaction commands can provide an entry point for these operations; the agent still needs to connect the appropriate interfaces to implement them. FMZ interaction commands

After the first sale, if the premium remains, I can choose to add some of the proceeds as collateral and borrow and sell another batch.

At that point, the most important figure on the page is "how much ETH I will owe in total if I continue." It should also show the collateral, available wallet funds, and health factor—the remaining margin before the lending position faces liquidation. The amount I am allowed to borrow is not necessarily the amount I want to borrow.

Every addition of collateral and every further round of borrowing and selling must therefore have a new preview and require my confirmation, subject to preset limits on total debt and the health factor. The amount of stablecoins received from sales and the portion already committed as collateral must also be tracked separately.

If the ETH is borrowed but the sale fails, the program should stop and deal with that loan. If a transaction is still awaiting confirmation, clicking again must not trigger a duplicate loan.

I want the tool to handle these details so that every decision to continue comes with a clear account of the position.

When It Is Time to Exit, Where Does the Buyback Money Come From?

Following the process through reveals another easy-to-miss question: if all the sale proceeds have been deposited back into Aave, what will I use to buy back the ETH?

A collateral balance and a wallet balance are not the same thing.

The design therefore needs to provide for buyback funding. One option is to reserve some stablecoins. Another is to withdraw collateral in batches, when the health factor and pool liquidity permit, and use it to buy tokens for repayment. Each step needs its own feasibility check. The design cannot assume that all collateral can be withdrawn at any time. Aave withdrawal guide

When I decide to buy back, the page should show where the money for that batch will come from, how much ETH it can buy, and how much debt will remain after repayment. After confirmation, it should execute and update the records. If the exit requires several batches, each batch should be confirmed separately.

Buyback monitoring also cannot focus only on prices that would make a profit. If ETH continues rising, the buyback cost increases. As the debt valuation rises, the health factor may also fall. The program should alert me to both the cost of buying back and the position's risk, instead of waiting indefinitely for a price decline that may never come. Aave health factor guide

Finally, buying the ETH back is not the end. It must actually be repaid to Aave, with the principal, interest, and remaining debt reconciled. The final result can be calculated only once this position is settled. Any pre-existing positions must be accounted for separately. Aave repayment guide

That completes the loop described in the original post:

Detect a premium → verify the conditions → manually confirm borrowing and selling → add collateral and continue borrowing and selling as needed → manually confirm staged buybacks and repayments → reconcile debt and actual cash flows.

Handing This Workflow to My Codex

That is the task I am giving the agent: from identifying a price difference, through each additional round of borrowing and selling, to buying back and repaying, the FMZ page should always show where I am in the process and how many tokens I still owe.

For now, this is still a requirements design. I will share the code and actual operating results once the work is complete.

The next time a similar opportunity appears, I hope to have a familiar tool ready: check the conditions, review the accounts, and then decide whether to act.

Even a small share of an opportunity would be something. First, I need to understand how to sell the tokens I borrow—and how to repay them afterward.

The Prompt for Codex

            text
            
            
Please design an FMZ price-monitoring and manual-trading tool that follows the original post's workflow: post stablecoins as collateral → borrow ETH → sell at a premium → manually confirm additional collateral and further borrowing and selling → buy back ETH in batches and repay principal and interest in full. Provide an implementation plan first; do not deploy it for live trading directly.

Original background post:
https://x.com/0xNaiXi/status/2115967318274789609

Strategy objective: capture local ETH premiums created by urgent conversion demand, supplying spot ETH by borrowing against collateral, then seeking to buy back and repay. "No inventory? Borrow against collateral and sell short." Without a hedge, the position remains exposed to rising ETH prices; the current premium must not be treated as locked-in profit.

Monitor Binance and OKX spot markets, along with BTC- and ETH-related markets on Uniswap (Ethereum), PancakeSwap (BNB Chain), and Aerodrome (Base). Verify token contracts, wrapped assets, and differences in quote currencies. For execution, the first version should implement only the ETH/WETH workflow between one explicitly identified Aave market on Ethereum and a DEX, with no automatic cross-chain transfers.

1. Monitor first, then verify. Normalize prices to a common quote currency and distinguish a local ETH premium from an abnormal quote currency. After detecting a lead, obtain executable quotes for the specified quantity and check fees, quote freshness, Aave supply and borrowing restrictions, pool liquidity, and the account's collateral eligibility. Display CEX reference prices, Aave oracle valuations, and executable buy and sell quotes separately. A future buyback price is only an assumption and must not be used to display locked-in profit.

2. Support manually controlled cycles of borrowing and selling. For the initial collateral deposit, borrowing and selling, adding sale proceeds as collateral, and further borrowing and selling, first show the corresponding plan and execute only after my confirmation. Each preview should show quantities, price boundaries, fees, and the resulting cumulative debt and health factor. Expired quotes or conditions outside the approved boundaries require renewed confirmation. Allow the position to be increased before all debt has been repaid, subject to a total-debt cap, a minimum health factor, and reserved buyback funds. Do not run an unlimited automatic loop.

3. Complete the buyback and repayment process. Continuously display the current buyback cost, actual principal and interest due, wallet funds, and withdrawable collateral. Fund buybacks from reserves or eligible collateral withdrawals, checking the health factor and liquidity at each step. Show any funding shortfall when funds are unavailable. After my confirmation, buy back and repay in batches, then query the remaining debt until this position is settled. Adding collateral is not repayment, and buying ETH without actually repaying it to Aave does not settle the position either.

4. Record and handle exceptions. Distinguish pre-existing positions from this tool's operations while assessing risk across the entire account. Record actual cash flows, fees, collateral, and debt without deducting fees twice. Repeated clicks must not trigger duplicate trades. If borrowing succeeds but selling fails, allow me to confirm repayment of the unsold tokens. If the status is unknown, query it first and pause subsequent operations. Restore unfinished records after a restart.

Verify the official FMZ and protocol documentation, then provide a concise interaction design, required interfaces and credentials, execution states, and exception handling. Without confirmation, monitor only. Do not invent interface support, code, tests, or returns.

Beta Strategy Tool

https://www.fmz.com/strategy/552643

This strategy has not been validated through live trading. It is shared solely for discussion and learning.