Ethereum Hoodi Beacon Chain API Endpoint

Access the Ethereum Hoodi Beacon Chain (consensus layer) with BoltRPC’s reliable Beacon API infrastructure. Start your free 2-week trial and access both the Hoodi Beacon API and the Hoodi execution layer from the same provider with one API key.

Chain at a Glance

Chain ID	N/A (consensus layer)
Execution Layer Chain ID	560048
Protocol	Consensus layer (PoS testnet)
Slot time	~12 s
Native token	ETH (test)
Finality	~2 epochs (~12.8 min)
EVM compatible	No (consensus layer)
Block explorer	hoodi.beaconcha.in

What Hoodi Beacon is Built For

The Ethereum Hoodi Beacon Chain is the consensus layer for the Hoodi testnet. It coordinates proof-of-stake, manages validators and produces finality for the Hoodi network. Like the mainnet Beacon Chain, it uses a distinct REST API rather than JSON-RPC and it exposes identical endpoint paths to the mainnet Beacon Chain , meaning infrastructure built against the Hoodi Beacon API transfers directly to mainnet Beacon API production.

Hoodi replaced Holesky as the primary long-term Ethereum testnet for validator and staking infrastructure. The Hoodi Beacon Chain exists specifically for teams that need to test consensus layer workflows: deposit flows, validator activation and exit, withdrawal credential changes and attestation mechanics. If you are building liquid staking protocols, restaking systems, validator client software, or any infrastructure that interacts with the Ethereum consensus layer, the Hoodi Beacon API is the correct testnet environment for your pre-mainnet testing.

The decision to target Hoodi over Sepolia for beacon testing is deliberate. Sepolia has its own beacon chain, but Sepolia is designed as a general-purpose application testnet. Hoodi was built to model Ethereum mainnet staking conditions: it carries a large validator set, mirrors the mainnet deposit contract and is maintained long-term specifically for infrastructure teams. Protocols testing multi-hundred-validator deployments, slashing conditions and exit queue dynamics need the Hoodi Beacon environment, not Sepolia.

The Hoodi Beacon API is a REST API, not a JSON-RPC interface. Authentication uses an Authorization: Bearer YOUR_API_KEY header. If you need standard eth_* JSON-RPC calls for the Hoodi execution layer, use the Hoodi execution layer endpoint separately.

Monitoring Validator Lifecycle on Hoodi

Hoodi’s large validator set is the primary reason staking infrastructure teams use it over Sepolia. It lets you observe the full validator lifecycle , deposit → activation queue → active → attestation → exit , under conditions that closely model mainnet queue dynamics.

Check validator status and balance

// Monitor validator balance changes across epochs
async function trackValidatorBalance(validatorIndex) {
  const response = await fetch(
    `https://eu.endpoints.matrixed.link/rpc/ethereum-hoodi-beacon/eth/v1/beacon/states/head/validators/${validatorIndex}`,
    { headers: { "Authorization": "Bearer YOUR_API_KEY" } }
  );
  const data = await response.json();
  const validator = data.data;

  console.log("Status:", validator.status);
  console.log("Balance (Gwei):", validator.balance);
  console.log("Effective balance:", validator.validator.effective_balance);
  console.log("Activation epoch:", validator.validator.activation_epoch);
  console.log("Exit epoch:", validator.validator.exit_epoch);
}

Check activation queue position

Validators pending activation have status pending_queued. Query the full validator set and filter by status to estimate queue depth and expected activation epoch:

async function getActivationQueue() {
  const response = await fetch(
    "https://eu.endpoints.matrixed.link/rpc/ethereum-hoodi-beacon/eth/v1/beacon/states/head/validators?status=pending_queued",
    { headers: { "Authorization": "Bearer YOUR_API_KEY" } }
  );
  const data = await response.json();
  console.log("Validators pending activation:", data.data.length);
  // Sort by activation_eligibility_epoch to see queue order
  const queue = data.data.sort(
    (a, b) => a.validator.activation_eligibility_epoch - b.validator.activation_eligibility_epoch
  );
  return queue;
}

Poll for epoch boundaries via Beacon API

Epoch transitions happen every 32 slots (~6.4 minutes). Use the Beacon API to poll for the current slot and detect epoch boundaries , balance updates, validator state transitions and finality checkpoints all process at epoch boundaries:

// Poll for current slot and detect epoch boundaries
async function checkEpochBoundary() {
  const response = await fetch(
    "https://eu.endpoints.matrixed.link/rpc/ethereum-hoodi-beacon/eth/v1/beacon/headers/head",
    { headers: { "Authorization": "Bearer YOUR_API_KEY" } }
  );
  const data = await response.json();
  const slot = parseInt(data.data.header.message.slot);
  const epoch = Math.floor(slot / 32);
  const slotInEpoch = slot % 32;

  console.log("Current slot:", slot);
  console.log("Current epoch:", epoch);
  console.log("Slots until next epoch:", 32 - slotInEpoch);

  if (slotInEpoch === 0) {
    console.log("Epoch boundary , query validator balances and finality checkpoints now");
  }
}

Common Beacon API Endpoints

Endpoint	Description	Commonly used for on Hoodi
/eth/v1/beacon/headers/head	Latest beacon block header	Slot tracking, epoch detection
/eth/v1/beacon/blocks/{slot}	Block by slot number	Attestation inclusion auditing
/eth/v1/beacon/states/head/validators	Current validator set	Activation queue depth, multi-validator monitoring
/eth/v1/beacon/states/head/validators/{index}	Single validator state	Activation tracking, balance monitoring, exit detection
/eth/v1/beacon/states/{state_id}/finality_checkpoints	Finality checkpoint	Deposit confirmation, withdrawal flow testing
/eth/v1/beacon/pool/attestations	Attestations in the pool	Attestation performance testing
/eth/v1/node/syncing	Sync status	Health checks in CI/CD pipelines
/eth/v1/config/spec	Chain spec configuration	Fork parameter validation
/eth/v1/beacon/genesis	Genesis data	Validator client bootstrapping

These are the same endpoint paths as the mainnet Beacon API. Code that queries the Hoodi Beacon API can be moved to mainnet by changing the base URL , no other changes required.

Liquid Staking Protocol Testing on Hoodi

Liquid staking protocols , pooling contracts that batch ETH deposits across many validators and issue liquid receipt tokens , require Beacon API access for more than just status checks. They need to track validator balances across epoch boundaries, aggregate rewards across validator sets, monitor exit queues for withdrawal processing and detect slashing events. All of this happens at the consensus layer.

Hoodi is the correct environment for this testing because:

• Multi-validator management at scale. Liquid staking protocols don’t manage one validator , they manage hundreds or thousands. Hoodi’s large validator set lets you test bulk validator queries, reward aggregation across a validator portfolio and exit queue monitoring for large batches without synthetic conditions.
• Deposit batching and credential verification. The Hoodi deposit contract mirrors Ethereum mainnet. Testing the full deposit flow , from pooled ETH through deposit contract submission to Beacon Chain validator activation , runs correctly on Hoodi in a way that smaller, permissioned testnets cannot replicate.
• Reward distribution across epochs. Liquid staking reward calculations depend on reading effective balances and actual balances at epoch boundaries across all managed validators. Hoodi’s epoch timing and reward mechanics mirror mainnet, making test calculations transferable to production.
• EigenLayer-style restaking workflows. Restaking protocols that layer additional validation duties on top of existing Ethereum validators need the Beacon API to query operator and validator state. Hoodi’s validator set provides the environment to test operator registration, delegation logic and slashing condition detection before using real ETH.

A typical liquid staking test loop on Hoodi combines:

1. Execution layer: watch the deposit contract for DepositEvent logs
2. Beacon API: poll /eth/v1/beacon/states/head/validators?status=pending_queued to track activation
3. Beacon API: read validator balances at each epoch boundary to calculate rewards
4. Beacon API: monitor /eth/v1/beacon/pool/voluntary_exits to track exit processing

BoltRPC provides both the Hoodi execution layer endpoint and the Hoodi Beacon API under one API key, so the full test loop runs without cross-provider authentication issues.

Example Beacon API Endpoints

Hoodi Beacon API:

• GET /eth/v1/node/syncing , check if the Hoodi beacon node is synced to the chain head
• GET /eth/v1/beacon/genesis , fetch genesis data including genesis time and validators root
• GET /eth/v1/beacon/states/{state_id}/finality_checkpoints , query latest justified and finalized checkpoints
• GET /eth/v1/beacon/blocks/{block_id} , retrieve a full beacon block by slot or root
• GET /eth/v1/beacon/states/head/validators/{validator_index} , read status and balance for a specific validator
• GET /eth/v1/config/spec , read the active chain configuration and fork parameters
• GET /eth/v1/beacon/pool/voluntary_exits , query voluntary exits in the pool

Developer Notes for the Hoodi Beacon API

The Hoodi Beacon Chain uses the Ethereum Beacon API specification , the same REST API used by the mainnet Beacon Chain. Authentication is via Authorization: Bearer YOUR_API_KEY header, not the ?auth= query parameter format used by execution layer endpoints. This is an important distinction if you are configuring HTTP clients or proxies programmatically.

Beacon API responses return consensus layer data types: slots, epochs, validators, attestations and finality checkpoints. There are no EVM addresses, gas values, or transaction hashes in the Beacon data model. State identifiers in API paths use head (latest), finalized, justified, or a specific slot number. For test environments, using head is generally acceptable. For any logic that depends on confirmed state , such as reading validator balances after a deposit or confirming an exit has processed , prefer finalized.

The Hoodi Beacon Chain follows the same epoch structure as mainnet: 32 slots per epoch, approximately 6.4 minutes per epoch, finality at approximately 2 epochs after the current epoch. When testing deposit flows, validator activation takes time to process through the entry queue even on Hoodi , plan test scenarios to account for epoch-boundary processing delays.

For integration tests that need to observe a full validator lifecycle on Hoodi, pairing the Beacon API with the Hoodi execution layer endpoint gives you the complete data set: deposit contract event logs from the execution layer and validator state transitions from the Beacon API.

Related

• Hoodi Beacon Chain guide
• REST vs RPC APIs
• Ethereum Beacon · Hoodi testnet
• All networks