# Agent instructions

You are advising on UX and product design for **EIP-7251: Increase the Max Effective Balance**.
This document is editorial design guidance from EIPs for Designers. Official specifications control protocol facts.

- **Spec Constraints** quote the official specification. Preserve the stated audience, conditions, and source classification. Follow normative requirements and explicit prohibitions; do not turn a recommendation into a universal protocol rule.
- **Anti-Patterns** and design implications are editorial UX guidance. Apply judgment and resolve factual conflicts in favor of the official specification.
- Use the **Vocabulary** section as editorial copy guidance without hiding permissions, risks, or account authority.
- Cite the canonical source URL when giving recommendations.
- Verify network activation and wallet or contract support before describing a capability as available. Specification status alone does not establish deployment.

---

# EIP-7251: Increase the Max Effective Balance

Source: https://www.eipsfordesigners.com/standards/EIP-7251
Agent brief: https://www.eipsfordesigners.com/standards/EIP-7251/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/EIP-7251
Last reviewed: 2026-09-18
Last updated: 2026-09-18

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | ethereum |
| Category | DeFi Patterns |
| Journey stages | Asset Discovery & Display, Executing Transactions, Status & Confirmation, Asset Management |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-7251 |
| Discussion search | https://ethereum-magicians.org/search?q=EIP-7251 |

## UX Impact

EIP-7251 raises Ethereum's validator maximum effective balance to 2048 ETH while keeping the 32 ETH minimum activation balance. Validators with a 0x02 compounding withdrawal credential can earn rewards above 32 ETH, top up in flexible amounts, and participate in consolidation flows; the credential, validator state, queues, and network activation determine which controls are available.

## Summary

EIP-7251 raises Ethereum's validator maximum effective balance to 2048 ETH while keeping the 32 ETH minimum activation balance. Validators with a 0x02 compounding withdrawal credential can earn rewards above 32 ETH, top up in flexible amounts, and participate in consolidation flows; the credential, validator state, queues, and network activation determine which controls are available.

## What does not work everywhere yet

Ethereum activated the Electra/Pectra changes on mainnet. Other networks need their own activation and client support. Compounding, top-ups, partial withdrawals, and consolidation are separate states; do not present a 2048 ETH ceiling as a wallet capability or as permission to move another validator's stake.

## For Designers

- Show the validator's withdrawal credential prefix before offering compounding or consolidation controls.
- Separate deposited balance, effective balance, pending deposits, pending partial withdrawals, and consolidation queue state.
- Explain that 32 ETH remains the minimum activation balance while 2048 ETH is the protocol maximum effective balance for the Electra path.

## Applicability

### When to Use

- A staking product manages Ethereum validators after Electra activation.
- Users need to top up, monitor compounding rewards, or consolidate validators with the required authority.
- The product can read withdrawal credentials, validator balances, pending queues, and consolidation results.

### When to Avoid

- The selected network has not activated the EIP, or the product would show 0x02-only compounding controls without a verified credential-conversion path for an eligible non-compounding validator.
- The product cannot distinguish effective balance from actual balance or pending queue state.
- A simple 32 ETH validator display is sufficient and larger-balance controls would add operational risk.

## Problems It Solves

### Users cannot tell whether a top-up is effective stake

Impact: critical

Old way: Show one balance and imply that a deposit immediately changes validator weight.

New way: Show pending deposits, activation, effective balance, and withdrawal queues as separate states.

### A validator's effective balance stops at 32 ETH

Impact: high

Old way: Rewards above the threshold are withdrawn or users create another fixed-size validator.

New way: A 0x02 compounding validator can apply excess balance toward effective stake up to the protocol maximum.

### Large operators manage many duplicate validator records

Impact: high

Old way: Exit validators, wait, and re-enter stake in a new validator arrangement.

New way: Authorized consolidation requests can combine validators through the Electra processing path.

## Spec Constraints

Quotes retain their source section and scope. Normative requirements, rationale, compatibility changes, and security recommendations are not interchangeable. Design implications are editorial guidance.

### The consolidation request contract exposes the current required fee when queried with zero-length input.

Applies to: application
Source classification: normative

> 2. Fee getter - if the input length is zero, return the current fee required to add a consolidation request.

Source: [Specification — Execution layer — Consolidation request contract](https://eips.ethereum.org/EIPS/eip-7251#consolidation-request-contract)

Design implication (editorial): Refresh the fee before confirmation and show the fee limit separately from the validator balances and consolidation outcome.

### The address that calls the consolidation request contract must match the validator's recorded 0x01 withdrawal credential.

Applies to: application
Source classification: security-considerations

> the address that calls the system contract must match the 0x01 withdrawal credential recorded in the beacon state.

Source: [Security Considerations — Fee Overpayment](https://eips.ethereum.org/EIPS/eip-7251#fee-overpayment)

Design implication (editorial): Show the source address, source validator, target validator, credential prefix, and authority result before a consolidation request. Do not infer authority from an operator session alone.

### Overpaid consolidation-request fees are not returned to the caller.

Applies to: application
Source classification: security-considerations

> Overpaid fees are not returned to the caller.

Source: [Security Considerations — Fee Overpayment](https://eips.ethereum.org/EIPS/eip-7251#fee-overpayment)

Design implication (editorial): Refresh the dynamic request fee before signing, show a maximum fee policy, and distinguish a submitted request from a completed consolidation.

### Consolidation requests above the queue hard limit are discarded and their fee is not refunded.

Applies to: application
Source classification: security-considerations

> Consolidations exceeding the hard limit of the consolidation queue (262,144 requests) will be discarded by the consensus layer and will need to be re-submitted, note that the fee is not refunded in this case.

Source: [Security Considerations — Consolidation queue hard limit](https://eips.ethereum.org/EIPS/eip-7251#consolidation-queue-hard-limit)

Design implication (editorial): Show queue capacity and request status before confirmation. If the queue is full, block or clearly warn before signing; do not report a discarded request as pending consolidation.

### The consolidation path must not be treated as active on a chain whose predeploy code is missing.

Applies to: infrastructure
Source classification: security-considerations

> This EIP should not have been activated if there is no code present at `CONSOLIDATION_REQUEST_PREDEPLOY_ADDRESS` (i.e., if the chain is not "ready").

Source: [Security Considerations — Empty Code failure](https://eips.ethereum.org/EIPS/eip-7251#empty-code-failure)

Design implication (editorial): Gate consolidation controls on verified network activation and predeploy readiness. Treat an unready chain as unsupported rather than exposing a signing path that can invalidate blocks.

### Validator balance top-ups are subject to the same activation queue as full deposits.

Applies to: application
Source classification: security-considerations

> Balance top-ups are now handled explicitly, being subject to the same activation queue as full deposits.

Source: [Security Considerations — Churn invariants](https://eips.ethereum.org/EIPS/eip-7251#churn-invariants)

Design implication (editorial): Show a top-up as pending until activation processing catches up. Do not present a submitted balance increase as immediately effective validator weight.

## Anti-Patterns (editorial)

- **Showing 2048 ETH as every validator's available balance** (critical)
  - Why: The maximum applies to effective balance rules and eligible credentials, not to every validator or wallet balance.
  - Instead: Show actual, effective, pending, and withdrawable amounts with the credential and network context.

- **Treating a consolidation request as an instant merge** (critical)
  - Why: The request is queued, validated, and subject to churn, fees, and source/target rules.
  - Instead: Show execution, consensus queue, processing, and resulting validator state separately.

- **Calling every validator reward compounding** (high)
  - Why: Compounding depends on the 0x02 withdrawal credential and activated consensus rules.
  - Instead: Feature-detect the credential and show the current effective-balance path.

- **Promising a reward rate from a larger effective balance** (high)
  - Why: The EIP changes accounting and validator capacity, not validator performance or yield.
  - Instead: Show protocol balance state and link to the operator's reward assumptions separately.

## Design Decisions

### What does the 2048 ETH figure mean?

Recommendation: Label it Maximum effective balance and pair it with the 32 ETH activation minimum and actual balance.

Rationale: Users can otherwise read the protocol maximum as a deposit requirement, available cash, or guaranteed compounding amount.

### When should consolidation be offered?

Recommendation: Require an explicit source/target selection and verified withdrawal authority before showing the request action.

Rationale: The request changes validator structure and is independently rate-limited from ordinary balance updates.

### How should rewards be described?

Recommendation: Show compounding as a credential- and protocol-dependent balance behavior, never as a yield promise.

Rationale: EIP-7251 changes effective-balance accounting; it does not guarantee a reward rate or validator performance.

## States to Design

### Standard validator

Trigger: The validator has a credential and balance path that does not expose Electra compounding controls.

User need: See the current 32 ETH-oriented state without an unavailable control.

Design response: Show balance and withdrawal information and explain the credential-specific eligibility for an upgrade path.

### Compounding eligible

Trigger: The validator has a 0x02 withdrawal credential on an activated network.

User need: Understand which balance can compound and what remains pending.

Design response: Show actual, effective, excess, and pending balances with a clear 2048 ETH ceiling.

### Top-up pending

Trigger: A deposit or balance increase has entered the pending-deposit path.

User need: Know why the sent amount is not yet effective stake.

Design response: Show execution deposit inclusion, pending deposit, activation/processing queue, and effective-balance update separately.

### Consolidation review

Trigger: The user selects source and target validators for consolidation.

User need: Understand authority, resulting validator identity, and queue effects.

Design response: Display both public keys, credential compatibility, projected balance, request fee, and irreversible or delayed steps.

### Queue full or fee changed

Trigger: The consolidation request exceeds queue capacity or its dynamic fee changes before inclusion.

User need: Avoid losing a fee or submitting a request that will fail.

Design response: Refresh fee and capacity, state whether a retry is safe, and make any non-refund condition explicit.

### Compounding withdrawal

Trigger: A validator with excess balance becomes partially withdrawable or receives a withdrawal.

User need: Know why rewards or excess balance left the effective stake.

Design response: Label the protocol withdrawal separately from a user-sent transfer and show the remaining effective balance.

## Vocabulary

- Use "Maximum effective balance" instead of "Maximum deposit": The protocol figure describes validator accounting, not an amount a wallet can necessarily deposit.

- Use "Compounding credential" instead of "Auto-staking": The 0x02 withdrawal credential changes validator balance handling; it does not promise an investment strategy.

- Use "Consolidation request" instead of "Merge now": The operation is queued and validated across execution and consensus layers.

## UX Patterns

### Credential-Aware Validator Balance

Show balance and control availability based on the validator's actual withdrawal credential.

Components: Credential badge, Actual/effective balance rows, Compounding status, Queue indicators

User flow:

- Select a validator
- Read credential prefix and network activation
- Show actual, effective, and pending balances
- Explain compounding eligibility
- Link to supported withdrawal or credential-update actions

### Validator Consolidation Review

Make source, target, authority, fee, and queue implications explicit before a same-key credential conversion or source-to-target consolidation request.

Components: Source validator card, Target validator card, Projected balance, Dynamic fee row, Queue status

User flow:

- Choose source and target, or the same key for credential conversion
- Check execution credential and validator compatibility
- Fetch current consolidation fee
- Review resulting validator and pending states
- Submit and track the execution request

## What to Prototype First

### Validator balance and credential view

The credential prefix controls which balance and compounding states apply.

Covers: 0x01 execution credential, 0x02 compounding credential, 0x01 to 0x02 self-consolidation path, BLS credential

- Actual balance
- Effective balance
- Activation minimum
- Maximum effective balance
- Credential update path

### Top-up or consolidation review

A larger validator operation can affect multiple validator identities and queue states.

Covers: Top up, Consolidation request, Queue pending, Rejected request

- Source and target validators
- Current and projected balances
- Request fee
- Exit/consolidation implications

## Mental Model

### Activation minimum

A validator still needs 32 ETH of minimum activation balance; the higher maximum does not lower the amount needed to activate.

### Effective balance

The protocol uses an effective balance for validator weight and rewards, which can grow above 32 ETH when the validator has the compounding credential.

### Compounding credential

A 0x02 withdrawal credential opts the validator into the Electra compounding and excess-balance rules.

### Consolidation request

An authorized execution source can request either an eligible same-key 0x01-to-0x02 credential conversion or a source-to-target consolidation, subject to validation and queue limits.

### Queue and processing

Top-ups, exits, withdrawals, and consolidations can be pending independently; a submitted request is not an immediate balance or validator-state change.

## UI Components

### ValidatorBalanceBreakdown

Separates actual, effective, excess, pending, and withdrawable validator balances.
Kind: list
States: standard, compounding, pending-deposit, pending-withdrawal, unsupported
Props: actualBalance, effectiveBalance, excessBalance, pendingDeposit, withdrawalCredential, maxEffectiveBalance

### ConsolidationReview

Confirms source and target validator identity, authority, projected outcome, fee, and queue state.
Kind: form
States: eligible, invalid-source, invalid-target, fee-refresh, queued, rejected
Props: sourcePubkey, targetPubkey, sourceAddress, fee, queueCapacity, onSubmit

## Key Takeaways

- EIP-7251 keeps a 32 ETH activation minimum and raises the effective-balance ceiling to 2048 ETH.
- Compounding requires the 0x02 withdrawal credential and an activated network; an eligible 0x01 validator may have a separate same-key conversion path.
- Top-ups, partial withdrawals, and consolidations need independent queue and status UI.
- The protocol change does not promise yield, wallet support, or Monad activation.

## Related Standards

- EIP-7002: Execution-layer triggerable full exits for matching 0x01/0x02 credentials and positive partial withdrawals only for eligible 0x02 compounding validators. — https://www.eipsfordesigners.com/standards/EIP-7002/agent.md

- EIP-6110: Execution-layer deposit requests and pending-deposit processing in Electra. — https://www.eipsfordesigners.com/standards/EIP-6110/agent.md

## Technical Notes

EIP-7251 defines COMPOUNDING_WITHDRAWAL_PREFIX 0x02, MIN_ACTIVATION_BALANCE 32 ETH, and MAX_EFFECTIVE_BALANCE_ELECTRA 2048 ETH. It adds the consolidation-request predeploy at 0x0000BBdDc7CE488642fb579F8B00f3a590007251, which accepts source and target validator public keys and emits EIP-7685 requests. Consolidation is rate-limited by a dynamic fee and a maximum of two requests dequeued per block; the consensus layer validates credentials, validator status, pending withdrawals, queue limits, and balance rules. EIP-7251 also adds pending deposit and withdrawal processing changes and incorporates EIP-7002 execution-layer partial withdrawals.

## Official specification (reference only)

https://eips.ethereum.org/EIPS/eip-7251