<![CDATA[MEV DAO Notes]]>https://mevdao.hashnode.devRSS for NodeSun, 01 Nov 2026 11:55:08 GMT60<![CDATA[Ethereum MEV Bot Engineering: Atomic DEX Arbitrage, Aave V3 Liquidations & Scam Bot Detection]]>https://mevdao.hashnode.dev/ethereum-mev-bot-engineering-atomic-dex-arbitrage-aave-v3-liquidations-scam-bot-detectionhttps://mevdao.hashnode.dev/ethereum-mev-bot-engineering-atomic-dex-arbitrage-aave-v3-liquidations-scam-bot-detectionSun, 25 Oct 2026 14:02:28 GMTReal Ethereum MEV bots—whether atomic DEX arbitrage contracts, JIT liquidity engines, or Aave V3 / Morpho Blue liquidation searchers—are built as custom Rust/Go mempool engines paired with gas-optimized Solidity/Yul executor contracts that pay 85%–98% of gross profit to block builders via block.coinbase.transfer. Meanwhile, thousands of developers lose ETH every month to fake YouTube "Remix IDE ChatGPT Solidity MEV bot" scams that hide obfuscated attacker payout addresses.

This technical reference from MEV DAO documents real searcher economics, custom MEV bot architecture, and open-source scam bytecode detection.

Architecture & Execution Checklist

[Local Node / Mempool Stream] ---> [Foundry Anvil eth_call Simulation]
                                          |
                                          v
[X-Flashbots-Signature Auth]  ---> [eth_sendBundle -> Block Builders]

Key technical invariants to verify before broadcasting:

  1. Simulate state transitions at block.number + 1 using eth_callBundle or a pinned Foundry anvil --fork-url environment before signing live bundles.
  2. Compute effective bundle gas price (effectiveGasPrice) across all transactions in the bundle, including 0-gas sponsored victim transactions, and ensure it exceeds the target block's tail gas price.
  3. Multi-builder fan-out: Submit time-sensitive bundles simultaneously to relay.flashbots.net, Titan Builder, Beaverbuild, and Rsync Builder so you don't miss slots built by non-Flashbots relays.

Complete Technical Guides & Deep-Dive Runbooks in This Series

Below is the complete index of technical deep-dives, runnable Solidity/TypeScript templates, and step-by-step troubleshooting guides in this cluster:

Open-Source Reference Repositories

For production Ethereum sniping, compromised-wallet rescues, or custom MEV engineering, visit MEV DAO or start a 3-day trial.

]]><![CDATA[Flashbots Bundles & Private RPC Engineering Guide: eth_sendBundle, mev_sendBundle & Anvil Fork Testing]]>https://mevdao.hashnode.dev/flashbots-bundles-private-rpc-engineering-guide-eth-sendbundle-mev-sendbundle-anvil-fork-testinghttps://mevdao.hashnode.dev/flashbots-bundles-private-rpc-engineering-guide-eth-sendbundle-mev-sendbundle-anvil-fork-testingSun, 25 Oct 2026 14:02:12 GMTWhether you are building an atomic rescue script, a backrun searcher, or a private swap router, understanding the difference between user-facing private RPCs (rpc.flashbots.net, rpc.mevblocker.io) and searcher bundle relays (relay.flashbots.net via eth_sendBundle / mev_sendBundle) is essential.

This engineering guide synthesizes our MEV DAO benchmarks, troubleshooting checklists, and Foundry anvil --fork-url simulation workflows across every part of the Ethereum PBS (Proposer-Builder Separation) pipeline.

Architecture & Execution Checklist

[Local Node / Mempool Stream] ---> [Foundry Anvil eth_call Simulation]
                                          |
                                          v
[X-Flashbots-Signature Auth]  ---> [eth_sendBundle -> Block Builders]

Key technical invariants to verify before broadcasting:

  1. Simulate state transitions at block.number + 1 using eth_callBundle or a pinned Foundry anvil --fork-url environment before signing live bundles.
  2. Compute effective bundle gas price (effectiveGasPrice) across all transactions in the bundle, including 0-gas sponsored victim transactions, and ensure it exceeds the target block's tail gas price.
  3. Multi-builder fan-out: Submit time-sensitive bundles simultaneously to relay.flashbots.net, Titan Builder, Beaverbuild, and Rsync Builder so you don't miss slots built by non-Flashbots relays.

Complete Technical Guides & Deep-Dive Runbooks in This Series

Below is the complete index of technical deep-dives, runnable Solidity/TypeScript templates, and step-by-step troubleshooting guides in this cluster:

Open-Source Reference Repositories

For production Ethereum sniping, compromised-wallet rescues, or custom MEV engineering, visit MEV DAO or start a 3-day trial.

]]><![CDATA[Ethereum Sniper Bot Architecture: Block-0 Flashbots Execution, Honeypot Simulation & Fee Math]]>https://mevdao.hashnode.dev/ethereum-sniper-bot-architecture-block-0-flashbots-execution-honeypot-simulation-fee-mathhttps://mevdao.hashnode.dev/ethereum-sniper-bot-architecture-block-0-flashbots-execution-honeypot-simulation-fee-mathSun, 25 Oct 2026 14:01:20 GMTSame-block (Block-0) token sniping on Ethereum requires monitoring pending liquidity additions (addLiquidityETH, enableTrading, or Uniswap V3/V4 pool initialization), simulating buy-and-sell execution paths locally via eth_call / debug_traceCall to filter out honeypots and dynamic tax traps, and submitting an atomic Flashbots bundle directly to block builders (relay.flashbots.net, Titan, Beaverbuild, Rsync).

This engineering handbook covers the full execution stack, anti-snipe contract defenses, and why MEV DAO uses flat-fee execution (€200/month with a 3-day trial) instead of charging a 1% per-trade tax on every buy and sell.

Architecture & Execution Checklist

[Local Node / Mempool Stream] ---> [Foundry Anvil eth_call Simulation]
                                          |
                                          v
[X-Flashbots-Signature Auth]  ---> [eth_sendBundle -> Block Builders]

Key technical invariants to verify before broadcasting:

  1. Simulate state transitions at block.number + 1 using eth_callBundle or a pinned Foundry anvil --fork-url environment before signing live bundles.
  2. Compute effective bundle gas price (effectiveGasPrice) across all transactions in the bundle, including 0-gas sponsored victim transactions, and ensure it exceeds the target block's tail gas price.
  3. Multi-builder fan-out: Submit time-sensitive bundles simultaneously to relay.flashbots.net, Titan Builder, Beaverbuild, and Rsync Builder so you don't miss slots built by non-Flashbots relays.

Complete Technical Guides & Deep-Dive Runbooks in This Series

Below is the complete index of technical deep-dives, runnable Solidity/TypeScript templates, and step-by-step troubleshooting guides in this cluster:

Open-Source Reference Repositories

For production Ethereum sniping, compromised-wallet rescues, or custom MEV engineering, visit MEV DAO or start a 3-day trial.

]]><![CDATA[Ethereum Compromised Wallet & EIP-7702 Sweeper Rescue Handbook (2026 Reference)]]>https://mevdao.hashnode.dev/ethereum-compromised-wallet-eip-7702-sweeper-rescue-handbook-2026-referencehttps://mevdao.hashnode.dev/ethereum-compromised-wallet-eip-7702-sweeper-rescue-handbook-2026-referenceSun, 25 Oct 2026 13:59:26 GMTWhen an Ethereum private key or seed phrase leaks, automated sweeper bots monitor the address and drain any incoming ETH within milliseconds—long before you can broadcast a standard transfer or revoke transaction. Since the May 2025 Pectra upgrade (EIP-7702, transaction type 0x04), attackers also attach persistent 0xef0100 || delegate_address bytecode directly to externally owned accounts (EOAs), executing malicious receive() hooks inside the funding call itself.

This technical reference compiles the complete atomic Flashbots bundle (eth_sendBundle) rescue architecture, EIP-7702 delegation clearing workflow, and protocol-specific recovery runbooks maintained by MEV DAO.

Architecture & Execution Checklist

[Local Node / Mempool Stream] ---> [Foundry Anvil eth_call Simulation]
                                          |
                                          v
[X-Flashbots-Signature Auth]  ---> [eth_sendBundle -> Block Builders]

Key technical invariants to verify before broadcasting:

  1. Simulate state transitions at block.number + 1 using eth_callBundle or a pinned Foundry anvil --fork-url environment before signing live bundles.
  2. Compute effective bundle gas price (effectiveGasPrice) across all transactions in the bundle, including 0-gas sponsored victim transactions, and ensure it exceeds the target block's tail gas price.
  3. Multi-builder fan-out: Submit time-sensitive bundles simultaneously to relay.flashbots.net, Titan Builder, Beaverbuild, and Rsync Builder so you don't miss slots built by non-Flashbots relays.

Complete Technical Guides & Deep-Dive Runbooks in This Series

Below is the complete index of technical deep-dives, runnable Solidity/TypeScript templates, and step-by-step troubleshooting guides in this cluster:

Open-Source Reference Repositories

For production Ethereum sniping, compromised-wallet rescues, or custom MEV engineering, visit MEV DAO or start a 3-day trial.

]]><![CDATA[How to Revoke Token Approvals and Permit2 Signatures]]>https://mevdao.hashnode.dev/how-to-revoke-token-approvals-and-permit2-signatureshttps://mevdao.hashnode.dev/how-to-revoke-token-approvals-and-permit2-signaturesThu, 22 Oct 2026 21:55:07 GMTMost of the drained wallets I look at weren't hacked in the movie sense. Nobody broke any cryptography. The owner gave a contract permission to move their tokens, sometimes years ago, and someone eventually used it.

That permission is a token approval. And over the last few years a second kind has become common, one that most people don't even know they've given: Permit2 allowances and signed permits. Both can be cleaned up, but the way you do it is different, and there's one case where cleaning them up does nothing at all.

Let me go through it the way I'd do it on my own wallets.

The three kinds of permission you've probably granted

1. Classic ERC-20 approvals. When you swap a token for the first time, the dApp asks you to approve(spender, amount). Lots of interfaces default to an unlimited amount (2^256 - 1) so you never have to approve again. That approval sits on the token contract forever, until you change it.

2. NFT operator approvals. setApprovalForAll(operator, true) gives one address control over every NFT you hold in that collection, now and in the future. Marketplaces need it to list your stuff. Phishing sites love it for the same reason.

3. Permit2. Permit2 is a contract Uniswap deployed that many apps now use as a shared approval layer. You approve Permit2 once per token with a normal ERC-20 approval, and then individual apps get access through Permit2, either as a stored allowance (the AllowanceTransfer part) or through a one-time signature (the SignatureTransfer part).

The Permit2 detail that matters for security: a lot of it happens through signatures you sign off-chain. No transaction, no gas, nothing in your wallet history. MetaMask's own guide on signature phishing points out that attackers can sit on a signed Permit2 permit and use it later, when you've already forgotten about it.

Step 1: find what you've approved

Use a dedicated tool. Don't try to work it out from your transaction history.

  • revoke.cash lists ERC-20 approvals, NFT approvals and Permit2 allowances per chain. It also explains each type well in its approvals guide.
  • Etherscan has a Token Approval Checker under its tools menu that does the same for Ethereum.

Connect in read-only mode or just paste your address. You don't need to connect a wallet just to look.

When you go through the list, sort by risk:

  1. Unlimited approvals to anything you don't use anymore. Dead protocols, old bridges, random farms from 2021. If that contract has a bug or an upgradeable admin key gets compromised, your tokens are exposed.
  2. setApprovalForAll on valuable collections, especially to marketplaces you don't use.
  3. Approvals to unverified contracts or EOAs. An approval to a plain wallet address is almost never legitimate. That's a red flag.
  4. Permit2 allowances with long expirations.

Step 2: revoke the classic approvals

Revoking an ERC-20 approval is just another approval with amount zero:

IERC20(token).approve(spender, 0);

For NFTs:

IERC721(collection).setApprovalForAll(operator, false);

revoke.cash and Etherscan wrap these into a button, but under the hood that's all it is. Each revoke is a transaction and costs gas. On mainnet that adds up, which is why I'd rather revoke the dangerous ten than the harmless hundred.

Step 3: deal with Permit2

Permit2 needs a bit more thought, because there are three layers.

Layer 1: the ERC-20 approval to Permit2 itself. Permit2 can only move a token if you approved Permit2 on that token. Revoke that approval and every Permit2 path for that token is cut off: stored allowances and signed permits alike. If you suspect you signed something bad and don't know what, this is the hammer.

Layer 2: stored Permit2 allowances. These live inside the Permit2 contract, per token and per spender. Each has an amount and an expiration. You can set one to zero, or use lockdown, which takes a list of token/spender pairs and zeroes all of them in one transaction:

// AllowanceTransfer.sol
function lockdown(TokenSpenderPair[] calldata approvals) external;

Layer 3: permits you signed but nobody used yet. This is the scary one, because there's nothing on-chain to see. For AllowanceTransfer permits, Permit2 has invalidateNonces(token, spender, newNonce), which bumps your nonce so every older signature for that pair becomes invalid. The contract only lets you move the nonce forward a limited amount per call (up to 2^16), to stop griefing. For SignatureTransfer permits, there's invalidateUnorderedNonces(wordPos, mask), which marks specific nonces as used.

In practice, if you don't know exactly which signature you gave, doing layer 1 for the tokens you care about is faster and safer than hunting down nonces.

What about EIP-2612 permits?

Some tokens, USDC for example, support permit natively (EIP-2612). You sign a message, someone submits it, and it becomes a normal approval. A signed-but-unused permit stays valid until its deadline, and only stops working once the token's nonce for your address moves past it.

Once it's been used it's just a regular approval, so you revoke it like one. If you think someone has an unused permit from you, the reliable defence is to move the tokens to another address before they use it. MetaMask gives the same advice for signatures you can't revoke.

The case where revoking does nothing

Here's what people get wrong. If your private key or seed phrase leaked, approvals are irrelevant. The attacker doesn't need your permission to move tokens. They are you. They'll just call transfer directly.

Worse, every revoke you send costs ETH, and if there's a sweeper bot on the wallet, that ETH disappears before you can use it. I've seen people top up gas five or six times trying to revoke approvals on a wallet the attacker fully controls. Every time, the ETH was gone in the same block.

How to tell which situation you're in:

  • Approval/permit exploit: tokens left your wallet through transferFrom called by some contract or address. Your ETH is untouched. New ETH you send stays put.
  • Key compromise: ETH leaves the moment it arrives, tokens move with plain transfer calls from your own address, or your address suddenly has code on it. That last one is an EIP-7702 delegation, which I explain in my guide on how to check and remove a malicious 7702 delegation.

If it's a key compromise, stop revoking. You need a rescue: move the remaining assets out in one atomic Flashbots bundle where the gas money and the transfers land in the same block. I wrote the full process in how to rescue tokens from a compromised wallet with a sweeper bot.

Habits that keep you out of this mess

  • Approve exact amounts for one-off interactions. It costs you one extra transaction next time. That's cheap insurance.
  • Read what you sign. If a site asks for a signature and the wallet shows PermitSingle, PermitBatch or PermitTransferFrom, you're signing spending rights. A "login" or "claim" should never need that.
  • Use a separate hot wallet for minting, airdrops and new protocols. Keep long-term holdings in a wallet that never connects to anything new.
  • Do an approval audit every few months. Twenty minutes on revoke.cash is enough.
  • Use a hardware wallet for the cold wallet. It doesn't stop you from signing a bad permit, but it does stop malware from signing one without you.

Quick reference

  • ERC-20 approval: approve(spender, 0)
  • NFT operator: setApprovalForAll(operator, false)
  • All Permit2 access for a token: revoke the ERC-20 approval to the Permit2 contract
  • Permit2 stored allowances: lockdown([...pairs])
  • Unused Permit2 allowance signatures: invalidateNonces(token, spender, newNonce)
  • Unused Permit2 transfer signatures: invalidateUnorderedNonces(wordPos, mask)
  • Leaked key: don't revoke, rescue

If you already lost the race and the wallet is being swept, the MEVDAO Token Rescue Bot does the bundled rescue for you. It's part of the subscription along with the sniping tools. For anything weird, message me on Telegram.

I send tips like these every week on the MEV Secrets email list. You can join right below.

Originally published on the MEV DAO blog.

]]><![CDATA[How to Check and Remove a Malicious EIP-7702 Delegation]]>https://mevdao.hashnode.dev/how-to-check-and-remove-a-malicious-eip-7702-delegationhttps://mevdao.hashnode.dev/how-to-check-and-remove-a-malicious-eip-7702-delegationThu, 22 Oct 2026 21:54:44 GMTSince the Pectra upgrade went live on Ethereum mainnet in May 2025, I've been getting a new kind of message from people with compromised wallets. It's not the classic "a bot takes my ETH every time I send gas" anymore. Now it's "my wallet has code on it and I never deployed anything".

That's EIP-7702. It's a good upgrade. It lets a normal wallet (an EOA) point at a smart contract and behave like a smart account, which gives you batching, gas sponsorship and all that. But the same feature is a gift for anyone holding a leaked private key, because they can now attach their own sweeper contract to your address. And once that code is on your account, it runs every time someone sends you ETH.

In this guide I'll show you how to check whether your address has a delegation, how to tell a legit one from a malicious one, and how to clear it. I'll also explain why clearing it on its own usually isn't enough.

What a 7702 delegation actually is

EIP-7702 adds a new transaction type, 0x04, called a set-code transaction. Inside it there's a list of authorizations. Each authorization is a tuple signed by the account owner:

[chain_id, address, nonce, y_parity, r, s]

When that transaction is processed, the protocol writes a tiny piece of code to your account: the bytes 0xef0100 followed by the 20-byte address you delegated to. The spec calls this a delegation indicator. From then on, any call to your address executes the code that lives at that delegated address, in the context of your account. Your balance, your storage, your tokens.

Three details from the spec matter a lot when you're dealing with an attacker:

  • It's persistent. The delegation stays until another authorization replaces it. It doesn't expire.
  • It survives reverts. The spec says the delegation is not rolled back if the rest of the transaction fails.
  • chain_id 0 means every chain. An authorization signed with chain ID 0 is valid on any EVM chain that supports 7702, as long as the nonce matches there.

The spec authors were very aware of the risk. It literally warns that wallets shouldn't let apps prompt users for authorizations, and that a badly built delegate contract can hand an attacker near-complete control of the account.

Why a 7702 sweeper is worse than a normal sweeper

A classic sweeper bot watches the mempool and the chain. When ETH lands in your wallet, it signs a transaction to send it out. That's a race. A fast enough rescue, usually a Flashbots bundle, can win it.

A 7702 sweeper doesn't need to race. If the delegate contract has a receive() function that forwards ETH, the transfer that funds your wallet is the same call that empties it. There's no window. The ETH arrives and leaves inside one execution.

This isn't theoretical. Right after Pectra, Wintermute's research team flagged a family of copy-paste sweeper delegates they nicknamed "CrimeEnjoyor", and CoinDesk covered it. The contracts are basically a receive() that pushes everything to a hardcoded attacker address. They're cheap to deploy and attackers reuse them across thousands of leaked keys.

Step 1: check whether your address is delegated

You don't need any special tool. Just ask a node for the code at your address. With Foundry's cast:

cast code 0xYourAddress --rpc-url https://ethereum-rpc.publicnode.com

Or with raw JSON-RPC:

{"jsonrpc":"2.0","id":1,"method":"eth_getCode","params":["0xYourAddress","latest"]}

What the result means:

  • 0x means no code, so no delegation. You're a plain EOA.
  • 0xef0100 followed by 40 hex characters means you're delegated. Those 40 characters are the address of the contract that now controls how your account behaves.

So a result like 0xef0100 + 1111222233334444555566667777888899990000 means calls to your wallet run the code at 0x1111…0000. That address is made up just to show the format.

Block explorers increasingly label delegated EOAs on the address page, but the RPC answer is the source of truth. Do this on every chain you've used that has 7702 enabled, because of the chain ID 0 detail above.

Step 2: is it a delegation you made, or one an attacker made?

Not every delegation is bad. If you turned on a smart-account feature in your wallet, you'll have a delegation to your wallet provider's delegator contract, and that's fine.

Here's how I triage it:

  1. Did you enable a smart account feature? If not, and there's code on your address, assume compromise.
  2. Open the delegate address on Etherscan. Is the source verified? Who deployed it? A legit wallet delegator is verified, widely used and documented by the wallet. A sweeper is usually a tiny unverified contract, or a verified one whose receive() and fallback() forward funds to a fixed address.
  3. Look at the transaction that set it. It's a type-4 transaction. Who sent it? If it was sent by a random address that also funded lots of other victims, you have your answer.
  4. Watch what happens to incoming ETH. If every incoming transfer leaves in the same transaction, you're dealing with an auto-forwarding delegate.

There are two very different situations here, and the fix depends on which one you're in:

  • You signed a malicious authorization, for example on a phishing site, but your private key is still safe. This is the easier case.
  • Your private key or seed phrase leaked. The attacker can sign new authorizations whenever they want. This is the hard case.

Step 3: clear the delegation

The spec gives us a clean way out. If you sign an authorization that delegates to the zero address (0x0000000000000000000000000000000000000000), the protocol clears the code and resets your account to the empty code hash. You become a normal EOA again.

If your key is safe and you just signed something bad, this is usually all you need. Many wallets now have an option to switch a smart account back to a standard account, which does exactly this under the hood. Check your wallet's settings first. If yours doesn't, you can do it yourself. Recent versions of Foundry support signing authorizations, for example with cast wallet sign-auth, and sending them with cast send --auth. Check cast --help on your version, because these flags are new and still changing.

One nonce trap catches a lot of people. If the same account both sends the type-4 transaction and signs the authorization, the sender's nonce goes up before the authorizations are processed. So the authorization has to use current nonce + 1, not the current nonce. Get it wrong and the authorization is silently skipped. The transaction succeeds and nothing changes, which is very confusing at 3am.

The cleaner way is to have a different wallet send the transaction. With 7702, the sender (who pays gas) doesn't have to be the account being changed. Your safe wallet pays, and the compromised wallet only provides a signature. That means you don't need any ETH in the compromised wallet at all, which is great, because any ETH you send there gets swept.

Step 4: if the key is leaked, clearing alone won't save you

This is the part people don't want to hear. If the attacker has your key, clearing the delegation buys you nothing on its own. They'll just sign a new one and put the sweeper back, maybe in the very next block. They can also watch for your type-4 transaction and try to get theirs in first.

So with a leaked key, the delegation reset has to happen atomically with the rescue, in one bundle:

  1. A type-4 transaction sent from your safe wallet, carrying the compromised wallet's authorization to the zero address. This removes the sweeper code. Your safe wallet pays the gas.
  2. A plain ETH transfer from your safe wallet to the compromised one, just enough for the gas of the next steps. Because the code was cleared one transaction earlier, nothing forwards it away.
  3. The transfers that move your tokens, NFTs or positions out of the compromised wallet to the safe one.

(The other way is to delegate to a rescue contract you control instead of to zero, and let your safe wallet execute a batch through it. It's more powerful, but you have to trust that contract completely, so I only do this with code I've written or audited.)

You send all of it as a Flashbots bundle so it either lands in one block in exactly that order, or not at all. Nothing hits the public mempool, so the attacker's bot has nothing to react to.

There's an open-source example of this pattern, eth-rescue by mpeyfuss, which clears a 7702 delegation as part of a rescue flow. Read the code before you run anything with a private key in it. That's a general rule: don't paste a compromised key into random tools from a Telegram DM. Half the "rescue services" out there are the second scam.

After the rescue, treat the old address as burned. Don't send anything to it again. Airdrops and vesting unlocks that go to that address are a separate problem, and you'll need a bundle for each one when it happens.

Common mistakes I see

  • Sending ETH to "pay for gas" for the clean-up. With an auto-forwarding delegate, that ETH is gone instantly. Sponsor the gas from another wallet instead.
  • Only checking mainnet. If the authorization used chain ID 0, the attacker may have delegated you on other chains too.
  • Thinking revoking token approvals fixes it. Approvals and delegations are separate things. You should still revoke your token approvals and Permit2 allowances, but that won't remove code from your account.
  • Using a public RPC to send the fix. Anything in the public mempool can be seen and countered. Use a private relay or a bundle.

Quick checklist

  • Run eth_getCode on your address on every chain you use
  • If it starts with 0xef0100, look up the delegate contract
  • Key safe: sign an authorization to 0x0 (or use your wallet's "switch back" option)
  • Key leaked: bundle the delegation reset with the asset transfers, sponsored from a safe wallet
  • Move everything to a brand-new seed, not just a new account in the same wallet
  • Never fund the compromised address again

If you're stuck with a sweeper draining everything you send, the MEVDAO Token Rescue Bot is built for exactly that: it pulls your tokens out of the compromised wallet through Flashbots. It's included with the MEVDAO subscription next to the sniping group and the sniper bot. If your wallet has a 7702 delegation on it, or you've got complicated stuff like staked positions, vesting contracts or airdrops that unlock later, send me a message on Telegram first and we'll look at the delegation together.

And if you want more of this kind of thing every week, join the MEV Secrets email list right below.

Originally published on the MEV DAO blog.

]]>