name: blockchain-ethereum
description: >
Use this skill when asked about Ethereum internals, EVM deep dive, Ethereum consensus layer, execution clients, staking, EIPs, layer-2 scaling, account abstraction, PBS/MEV-Boost, EVM opcodes, and Ethereum protocol development. Languages: Go, Rust, C#, C++, Solidity. Covers EVM architecture (opcodes, gas metering, memory/storage model, EOF), execution clients (geth, reth, Nethermind, Erigon), consensus layer (Casper FFG, LMD-GHOST, beacon chain, attestation), staking and validators (32 ETH, withdrawal credentials, MEV-Boost, DVT, ePBS), account abstraction (ERC-4337, EntryPoint, paymasters, UserOp mempool), critical EIPs (1559, 4844, 4337, 3529, 2718), and L2 scaling (Optimism, Arbitrum, ZKsync, StarkNet, validium, data availability). Do NOT use for: Bitcoin protocol (use blockchain-bitcoin), non-EVM blockchains (use blockchain-core), or smart contract development (use blockchain-application).
version: "2.0.0"
author: "j4flmao"
license: "MIT"
tags: [blockchain, ethereum, evm, consensus, phase-blockchain]
Blockchain Ethereum
Purpose
Guide to Ethereum protocol engineering covering execution layer, consensus layer, staking, L2 scaling, and protocol evolution through EIPs. Covers both client implementation and protocol-level design.
Agent Protocol
Trigger
"Ethereum", "EVM", "Ethereum Virtual Machine", "opcode", "gas", "Ethereum consensus", "beacon chain", "Casper", "LMD-GHOST", "execution client", "geth", "reth", "Nethermind", "Erigon", "Ethereum staking", "validator", "MEV-Boost", "EIP", "EIP-1559", "EIP-4844", "EIP-4337", "account abstraction", "ERC-4337", "EntryPoint", "paymaster", "UserOp", "PBS", "proposer builder separation", "ePBS", "FOCIL", "Ethereum L2", "rollup", "Optimism", "Arbitrum", "ZKsync", "StarkNet", "layer 2", "data availability", "blob", "Ethereum light client"
Input Context
- Ethereum layer (execution/consensus/L2)
- Client implementation (geth/reth/Nethermind/Erigon)
- Protocol component (EVM/staking/EE/etc.)
- EIP/research area
- Performance requirements (TPS, latency, cost budget)
Output Artifact
Technical analysis or implementation guide covering the specified Ethereum protocol component with architecture, mechanisms, and trade-offs.
Response Format
- Scope: execution layer vs consensus layer vs L2 vs EIP
- Architecture: client implementation, component breakdown, data flow
- Key mechanisms: fork choice, finality, fee mechanism, staking
- Implementation: relevant code patterns, configuration, optimization
- Trade-offs: security vs performance, decentralization vs throughput
- Integration: how the component interacts with other Ethereum layers
Completion Criteria
- Architecture covers the specific layer with correct component references
- Mechanisms accurately reflect current Ethereum spec (as of latest hard fork)
- Implementation references real client code where applicable
- Trade-offs analyzed with specific metrics
- Future directions (upcoming EIPs, research areas) identified
Max Response Length
5000 tokens
Decision Trees
Ethereum Layer Architecture
Ethereum interaction type:
├── Running a node?
│ ├── Full node → Any EL + any CL client
│ │ ├── Go experience → geth + lighthouse
│ │ ├── Rust experience → reth + lodestar
│ │ ├── C#/.NET → Nethermind + teku
│ │ ├── Archival focus → Erigon + any CL
│ │ └── Resource constrained → reth + nimbus (lightest)
│ ├── Validator node → EL + CL + validator client
│ │ └── 32 ETH bonded per validator
│ └── Light node → Helios or similar (trustless, minimal resources)
├── Developing dApps?
│ ├── EVM interaction → eth_call, eth_sendRawTransaction
│ ├── Account abstraction → ERC-4337 EntryPoint
│ └── L2 deployment → OP Stack, Arbitrum Nitro, ZK stack
└── Protocol research?
├── EVM changes → EIP process (consider EOF, account abstraction)
├── Consensus changes → ePBS, FOCIL, SSF, Orbit SSF
└── L1→L2 → 4844 blobs, based rollups, preconfirmations
Client Selection Decision
Node requirements:
├── Mainnet, most popular → geth (Go) — reference implementation
├── High performance, sync speed → reth (Rust) — 2-3x faster sync
├── Enterprise, .NET ecosystem → Nethermind (C#) — good monitoring
├── Archival node, optimized storage → Erigon (Go) — 50% less storage
└── Lightweight, embedded → reth or custom Go light client
L2 Selection
Scaling need:
├── EVM-equivalent, mature → Optimism OP Stack
├── EVM-equivalent, fast → Arbitrum Nitro (multi-round fraud proof)
├── EVM-equivalent, ZK → Scroll, Linea (zkEVM type 2/3)
├── ZK, custom VM → ZKsync Era (zkEVM type 4)
├── ZK, STARK-based → StarkNet (Cairo VM)
└── Data availability only → EigenDA, Celestia (for sovereign rollups)
Validator Infrastructure Decision
Validator operations:
├── Solo staking (32 ETH, self-operated)
│ ├── Pros: Maximum rewards, no counterparty risk
│ └── Cons: Requires 32 ETH, technical operation, uptime monitoring
├── Staking pools (Lido, Rocket Pool)
│ ├── Lido: stETH token, permissioned node operators, ~30% of staked ETH
│ ├── Rocket Pool: rETH token, permissionless node operators, 8-32 ETH needed
│ └── Cons: Trust in pool smart contracts, MEV revenue sharing
├── DVT (Distributed Validator Technology)
│ ├── SSV Network: DVT multi-operator validators
│ ├── Obol: Distributed validator cluster
│ └── Pros: Fault tolerance, geographic distribution
└── CEX staking (Coinbase, Binance)
└── Convenient but centralized, regulatory risk
EVM Architecture
Opcode Categories
// Arithmetic: ADD, SUB, MUL, DIV, MOD, EXP
// Comparison: LT, GT, EQ, ISZERO
// Bitwise: AND, OR, XOR, NOT, SHL, SHR, SAR
// Storage: SLOAD (2100 cold, 100 warm), SSTORE (20000+)
// Memory: MLOAD, MSTORE (3 gas)
// Environment: ADDRESS, BALANCE, CALLER, ORIGIN, CALLVALUE
// Block: BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, PREVRANDAO (after merge)
// Control: JUMP, JUMPI, JUMPDEST, STOP, RETURN, REVERT
// Contract creation: CREATE, CREATE2
// Calls: CALL, STATICCALL, DELEGATECALL, CALLCODE
Gas Cost Table (Key Operations)
| Operation | Gas Cost | Notes |
|---|
| Base tx | 21,000 | Simple ETH transfer |
| SLOAD (cold) | 2,100 | First read of storage slot in tx |
| SLOAD (warm) | 100 | Subsequent reads in same tx |
| SSTORE (new) | 22,100 | Write to zero → non-zero |
| SSTORE (update) | 5,000 | Write to non-zero → non-zero |
| SSTORE (zero) | 2,900 | Write to non-zero → zero (refund 4,800) |
| CALL | 7,000 | Plus gas stipend if value sent |
| CREATE | 32,000 | Contract deployment base |
| SHA-256 | 60 + 12/word | Precompile at 0x02 |
| BN254 pairing | 45,000 + 34,000/point | Precompile at 0x08 |
| BLAKE2f | Variable | Precompile at 0x09 |
| KZG verification | 50,000 | PINTICE precompile (EIP-4844) |
EVM Memory Model
Stack: 1024-element max, 256-bit words
- Operations consume from top of stack
- DUP1-16, SWAP1-16 for manipulation
- Stack overflow at 1024 elements → revert
Memory: Linear byte array, expandable
- MLOAD/MSTORE: 3 gas (plus 3 gas per 32-byte word expansion)
- MCOSTY (EIP-5656): 3 gas for memory copy
- Memory expansion cost: highest accessed address dictates total cost
Storage: Persistent 256-bit key-value store
- 2^256 slots of 32 bytes each
- slot = keccak256(key) for mapping entries
- Packed storage: multiple variables in one slot if < 32 bytes
Calldata: Read-only input data for transaction/call
- CALLDATALOAD, CALLDATASIZE, CALLDATACOPY
- 4 gas per non-zero byte, 16 gas per zero byte (EIP-2028)
- 16 gas per non-zero byte for calldata in tx data
EOF (Ethereum Object Format)
Proposed EVM upgrade (Prague hard fork): separates code from data, adds section-based structure, enables static jumps, removes CODECOPY/CODESIZE gas issues. EOF contracts have preamble, code sections, data section. Backward-incompatible — only new EOF contracts. Benefits: improved gas metering, better static analysis, simplified client implementation.
Consensus Layer
Beacon Chain Architecture
// Attestation flow: validator observes head → signs attestation → gossiped → included in block
type Attestation struct {
AggregationBits []byte // Which validators attest
Data AttestationData
Signature BLSSignature // Aggregated BLS sig
}
type AttestationData struct {
Slot uint64
Index uint64 // Committee index
BeaconBlockRoot Hash // LMD-GHOST vote
Source Checkpoint // Casper FFG source
Target Checkpoint // Casper FFG target
}
Fork Choice (LMD-GHOST)
func ForkChoice(block Node, store Store) Node {
head := block
for {
children := store.GetChildren(head.Root)
if len(children) == 0 {
return head
}
// Weighted by attestation votes
best := children[0]
for _, child := range children[1:] {
if child.Weight > best.Weight {
best = child
}
}
head = best
}
}
Finality (Casper FFG)
// Justification: 2/3 supermajority on (source, target) checkpoint pair
// Finalization: consecutive justified checkpoints (source → target justified, target → target+1 justified)
// Reorg depth: finalized checkpoints cannot be reorged (economic security)
// Epoch boundary: every 32 slots (6.4 minutes)
// Finality time: typically 2 epochs (12.8 minutes) after block proposal
Validator Responsibilities
Per epoch (6.4 minutes, 32 slots):
├── Propose block (1 validator per slot, ~32K validators)
│ ├── Must include: EL block, attestations, slashings, deposits
│ └── Rewards: base reward * (effective balance / 32) * proposer_weight
├── Attest to head (all validators in one of 64 committees per slot)
│ ├── Vote for: LMD-GHOST head (latest block), FFG source, FFG target
│ └── Rewards: base reward * (effective balance / 32) * attestation_weight
└── Slashable offenses:
├── Double vote: included in two different blocks for same target
├── Surround vote: surrounds another vote (source > target or vice versa)
└── Proposer slashing: two different blocks proposed for same slot
Reward and Penalty Calculations
Base reward = effective_balance * (base_reward_factor) / sqrt(total_active_balance)
base_reward_factor = 64
Total reward per epoch = base_reward * (proposer_weight + attestation_weight + ...)
Proposer weight: 8/64 of base reward per proposed block
Attestation weight: 26/64 for source vote, 14/64 for target vote, 14/64 for head vote
Inactivity leak: when chain hasn't finalized for >4 epochs
- Penalty increases quadratically over time
- Max penalty: up to 60%+ of stake during prolonged inactivity
Critical EIPs
| EIP | Title | Impact |
|---|
| 1559 | Fee market change | Base fee burned, priority fee, block target 50% full |
| 2718 | Typed transaction envelope | Transaction type prefix, extensible tx format |
| 2929 | Gas cost increases for state access | Cold SLOAD 2100, warm SLOAD 100 |
| 3529 | Reduction in refunds | Reduced SELFDESTRUCT and SSTORE refunds |
| 3651 | Warm COINBASE | COINBASE address starts warm (saves 2100 gas) |
| 4337 | Account abstraction | UserOp mempool, EntryPoint contract, paymasters |
| 4788 | Beacon block root in EVM | BEACON_ROOT opcode for L1→L2 bridges |
| 4844 | Proto-danksharding | Blob-carrying transactions for L2 data availability |
| 5656 | MCOPY opcode | Memory copy opcode (3 gas) |
| 6780 | SELFDESTRUCT cleanup | SELFDESTRUCT only sends ETH, doesn't delete code |
Upcoming EIPs (Prague/Electra)
| EIP | Title | Purpose |
|---|
| 7002 | Execution layer withdrawal | Validator exits triggered from execution layer |
| 7251 | Compound consolidation | Validator max balance increases from 32 to 2048 ETH |
| 7549 | Move committee index out of attestation | Reduces attestation size, aggregation efficiency |
| 6110 | Supply validator deposits on execution layer | Deposit flow on EL instead of CL |
| 7685 | General purpose execution layer requests | Standardized EL→CL request format |
| 7702 | Set EOA account code | Temporary delegation for smart contract wallets |
| 7691 | Blob count increase | Increase max blob count per block for L2 scaling |
Account Abstraction (ERC-4337)
Architecture Components
// ERC-4337 flow:
// 1. User creates UserOp off-chain (signs with wallet)
// 2. User sends UserOp to bundler (separate mempool)
// 3. Bundler bundles multiple UserOps into a single transaction
// 4. Bundler submits to EntryPoint.handleOps()
// 5. EntryPoint calls account contract's validateUserOp()
// 6. Account contract verifies signature and pays gas (or via paymaster)
interface UserOperation {
sender: string; // Account contract address
nonce: uint256; // Anti-replay, sequential
initCode: bytes; // Account deployment code (if not deployed)
callData: bytes; // Intended execution data
callGasLimit: uint256; // Gas for execution
verificationGasLimit: uint256; // Gas for verification
preVerificationGas: uint256; // Gas for bundler overhead
maxFeePerGas: uint256; // EIP-1559 max fee
maxPriorityFeePerGas: uint256; // EIP-1559 priority fee
paymasterAndData: bytes; // Paymaster contract + data (if using paymaster)
signature: bytes; // User signature
}
Paymaster Types
| Type | Mechanism | Use Case |
|---|
| Verifying paymaster | Off-chain approval flow | Sponsored transactions for specific users |
| Token paymaster | Swap tokens for gas | Pay gas in ERC-20 instead of ETH |
| Deposit paymaster | Pre-deposit ETH | Enterprise accounts with gas budget |
| Hybrid | Deposit + verification | Tiered access for users |
L2 Scaling
Rollup Comparison
| Feature | Optimism (OP) | Arbitrum (Nitro) | ZKsync Era | StarkNet |
|---|
| Type | Optimistic | Optimistic | ZK (Type 4) | ZK (Type 4) |
| VM | EVM (OVM) | EVM (WAVM) | zkEVM (Synchrony) | Cairo VM |
| Fraud proof | Multi-round (ZKP) | Multi-round (bisection) | N/A (validity proof) | N/A (validity proof) |
| Challenge period | 7 days | 7 days | N/A | N/A |
| State commitment | L1 calldata/blobs | L1 calldata/blobs | L1 calldata/blobs | L1 calldata (compress) |
| Sequencer | Centralized (planned) | Centralized (planned) | Centralized | Centralized |
| Withdrawal time | ~7 days | ~7 days | ~30 min | ~30 min |
Data Availability Options
Data posting:
├── Calldata (legacy): Store all L2 tx data as calldata on L1
│ └── Cost: ~16 gas/byte, expensive for high-throughput L2s
├── Blobs (EIP-4844): Dedicated blob-carrying transactions
│ ├── Cost: ~1-3 gas/byte (temporary, ~90% reduction)
│ ├── Blob size: 128KB per blob, max 6 blobs per block (post-Electra)
│ └── Retention: ~18 days (not stored permanently on L1)
├── EigenDA: External data availability layer
│ ├── Cost: Very low (off-chain DA with attestation)
│ └── Trust: EigenDA operator set (restaked ETH)
└── Celestia: Modular DA network
├── Cost: Low (dedicated DA blockchain)
└── Trust: Celestia validator set
Based Rollups
Rollups that use L1 proposers as their sequencer. No separate sequencer set. L1 proposers include L2 transactions in their L1 blocks. Inherits L1 liveness and decentralization. Challenge: latency (L1 block time = L2 block time). Projects: Taiko, ethOS. Preconfirmation services can provide sub-second user experience.
Client Implementation Patterns
Geth (Go) Architecture
// Geth's struct node → etherbase → miner workflow
// Key internal packages:
// core/state: StateDB for account storage management
// core/vm: EVM interpreter (JIT for performance)
// eth: Ethereum protocol handler
// miner: Block producer (seal/consensus) + worker
// consensus/beacon: Engine API interface for CL
// ETH call flow for eth_call:
func (api *EthAPI) Call(args TransactionArgs, blockNrOrHash *rpc.BlockNumberOrHash) (hexutil.Bytes, error) {
state, header, err := api.getState(blockNrOrHash)
if err != nil { return nil, err }
msg := args.ToMessage(api.b.BaseFee)
result, err := api.b.CallContract(msg, header, state)
return result, nil
}
Reth (Rust) Architecture
// Reth uses staged sync pipeline:
// 1. Header stage: download block headers
// 2. Body stage: download block bodies (transactions)
// 3. Sender recovery stage: recover transaction senders
// 4. Execution stage: execute blocks, update state
// 5. Pruning stage: prune old state data
// Advantages over geth:
// - Staged pipeline enables parallel execution
// - Memory-mapped database (redb) reduces IO
// - Static dispatch for EVM (no interpreter overhead)
// - 2-3x faster initial sync
Security Considerations
Ethereum-Specific Attacks
| Attack | Description | Mitigation |
|---|
| Reorg | Chain reorganization before finality | Wait for finalization (>2 epochs) |
| Long-range attack | Attacker creates alternative chain from genesis | Weak subjectivity checkpoint, social consensus |
| Balance attack | Partition network + drain validators | Proposer boost (LMD-GHOST fix) |
| Verifier's dilemma | MEV-Boost relay censorship | FOCIL forced inclusion lists |
| L1→L2 withdrawal exploit | Exploit bridge before fraud proof window | Challenge period monitoring |
| Blob withholding | Sequencer withholds blob data | Blob forwarding network, KZG commitments |
Staking Risk Matrix
| Risk | Likelihood | Impact | Mitigation |
|---|
| Slashing for double sign | Low (with monitoring) | 1 ETH + removal | Use DVT, separate machines |
| Inactivity leak | Medium (during long outage) | Up to 60% of stake | Failover node, alerting |
| Execution client bug | Low | Potential slashing | Run minority client |
| Consensus client bug | Low | Potential slashing | Run minority client |
| MEV-Boost relay failure | Medium | Missed MEV revenue | Multi-relay configuration |
Rules
- Ethereum is a modular blockchain: execution layer (EVM) + consensus layer (beacon chain)
- Use Go for geth (most popular), Rust for reth (fastest), C# for Nethermind, Go for Erigon
- LMD-GHOST is fork choice; Casper FFG provides finality; together as Gasper
- EIP-1559: base fee burned, priority fee to validator, blocks target 50% full
- Always consider L1 vs L2 tradeoffs: security guarantees, finality, cost, latency
- Reference specific implementations for deep technical accuracy
- Account for MEV in protocol design — PBS/MEV-Boost is currently non-consensus
- L2 security derives from L1 data availability — verify L2 state roots on L1
- Staking: 32 ETH per validator, withdrawal credentials point to execution address
- Protocol upgrades via EIP process — each fork bundles multiple EIPs
- Account abstraction (ERC-4337) separates signature verification from execution
- EOF enables future EVM improvements by removing backward-compatibility constraints
- Client diversity is critical — no single client should have >33% market share
- MEV-Boost relay selection should prioritize decentralization, not just revenue
- Blob transactions (EIP-4844) are temporary — full danksharding is the long-term goal
References
- references/account-abstraction-erc4337.md — Account Abstraction (ERC-4337) Deep Dive
- references/blockchain-ethereum-advanced.md — Blockchain Ethereum Advanced Topics
- references/blockchain-ethereum-fundamentals.md — Blockchain Ethereum Fundamentals
- references/eips-deep-dive.md — Critical EIPs Deep Dive
- references/eth-consensus-layer.md — Ethereum Consensus Layer (Beacon Chain)
- references/evm-deep-dive.md — EVM Deep Dive
- references/execution-clients.md — Execution Clients
- references/layer2-scaling.md — Layer-2 Scaling
- references/pbs-mev-boost.md — Proposer-Builder Separation & MEV-Boost
- references/staking-and-validator.md — Staking and Validators
- references/ethereum-light-clients.md — Ethereum Light Clients
- references/blob-transactions-4844.md — Blob Transactions (EIP-4844)
- references/optimistic-vs-zk-rollups.md — Optimistic vs ZK Rollup Comparison
Architecture Decision Trees
Ethereum Development Strategy
├── Layer-2 deployment?
│ ├── Optimistic rollup → Optimism / Arbitrum (EVM equivalent, 7d challenge)
│ ├── ZK rollup → zkSync / StarkNet (fast finality, proving overhead)
│ └── L1 only → Ethereum mainnet (security at cost)
├── Account abstraction?
│ ├── Yes → ERC-4337 (smart accounts, paymasters, bundlers)
│ ├── EIP-7702 → Native account abstraction (future)
│ └── No → EOA-based (traditional)
├── Calldata optimization?
│ ├── EIP-4844 blobs → Rollups (lower L1 call data cost)
│ ├── Calldata compression → Custom compression for L2 batches
│ └── None → Standard calldata
└── MEV strategy?
├── Capture → PBS (MEV-Boost) for validators
├── Minimize → CowSwap / batch auctions for users
└── Ignore → Standard transaction submission
Decision criteria: Evaluate L2 needs, gas optimization, target users, and MEV exposure tolerance.
Implementation Patterns
ERC-4337 Account Abstraction
// blockchain-ethereum/contracts/SmartAccount.sol
pragma solidity ^0.8.20;
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
contract SmartAccount {
using ECDSA for bytes32;
address public owner;
function validateUserOp(UserOperation calldata userOp, bytes32 userOpHash) external returns (uint256) {
bytes32 hash = userOpHash.toEthSignedMessageHash();
require(owner == hash.recover(userOp.signature), "Invalid signature");
return 0; // validation gas
}
function execute(address dest, uint256 value, bytes calldata func) external {
require(msg.sender == address(this), "Only self-call");
(bool success,) = dest.call{value: value}(func);
require(success, "Execution failed");
}
}
EIP-4844 Blob Transaction
# blockchain-ethereum/blob_transaction.py
from eth_account import Account
from eth_account._utils.signing import sign_message_hash
class BlobTransaction:
def __init__(self, w3: Web3):
self.w3 = w3
def send_blob(self, blob_data: bytes, to: str) -> dict:
tx = {
"type": 0x03,
"chainId": self.w3.eth.chain_id,
"to": to,
"maxFeePerGas": self.w3.eth.gas_price * 2,
"maxPriorityFeePerGas": self.w3.eth.max_priority_fee,
"blobVersionedHashes": [self._kzg_commitment(blob_data)],
"maxFeePerBlobGas": 1000000000,
}
return self.w3.eth.send_transaction(tx)
Production Considerations
- Gas estimation: Use
eth_estimateGas with state override; account for L1 data fee on L2.
- Nonce management: Track nonces per address; handle reverted tx with nonce caching.
- Fee market: Set priority fee dynamically (Flashbots API); monitor base fee trends.
- L2 finality: Wait for L2 output root submission to L1 for canonical finality (7d Optimism, ~1h Arbitrum).
- Wallet compatibility: Test with MetaMask, WalletConnect, and Coinbase Wallet.
- Infrastructure: Deploy RPC nodes with redundancy; use load balancer for high-availability.
Anti-Patterns
| Anti-Pattern | Consequence | Solution |
|---|
| Setting all txs to 0 priority fee | Slow or stuck transactions | Use dynamic priority fee (1-5 gwei) |
| No L2-specific gas estimation | Failed L2 transactions | Use L2 gas oracle for estimation |
| Hardcoded chain ID | Replay on different chain | Read chain ID from contract/network |
| Ignoring EIP-1559 | Overpaying for gas | Use type-2 transactions (EIP-1559) |
| Single RPC for production | Downtime during RPC issues | Multiple RPC endpoints with fallback |
Performance Optimization
- Calldata compression: Compress calldata with custom encoding for L2 transactions to reduce L1 data fees.
- Batch transactions: Use Multicall (MakerDAO) to batch multiple calls into single transaction.
- Nonce pre-computation: Pre-compute nonces for parallel transaction submission.
- Blob gas optimization: Pack multiple rollup transactions into single blob (EIP-4844).
- Gas token refund: Use EIP-3298 removed; leverage EIP-1559 base fee refund calculations.
Security Considerations
- Replay protection: Include chain ID in EIP-712 signatures; verify in contract.
- Signature malleability: Use EIP-2 (s < secp256k1n/2) to prevent signature malleability.
- Access control for smart accounts: Implement social recovery; multi-owner approval for high-value operations.
- MEV protection: Use Flashbots Protect or CoW Swap for order-flow privacy.
- Contract verification: Publish source code on Etherscan; verify with Sourcify for multi-chain.
Phase
blockchain → blockchain-ethereum