Draft EIP-8178 maps Engine API methods to resource paths with raw SSZ request and response bodies. JSON-RPC remains available on the same port. The EIP is a draft with no activation claim.
Status
The proposal is not a deployed Engine API transport. Older JSON-RPC methods remain the compatibility path until clients support the binary endpoints.
Transport contract
Requests use the existing JWT bearer token. SSZ request and success bodies use
application/octet-stream; error bodies use text/plain. A successful result
uses 200. A null result, such as a syncing response, uses 204 with no body.
The proposed status mapping is:
| HTTP status | Meaning |
|---|---|
400 | malformed SSZ request |
401 | missing or invalid JWT |
404 | unknown payload ID |
409 | invalid fork-choice state |
413 | request exceeds an element limit |
422 | invalid payload attributes |
500 | unexpected server error |
The request uses Accept: application/octet-stream when it expects an SSZ
response.
The payload resource submits a fork-versioned payload for validation.
The payload-ID resource retrieves a local build.
The fork-choice resource updates head state and may start a build.
The blob resource retrieves versioned blob-pool data.
Validation and failure handling
Decoders enforce the method limits before full allocation. The draft lists at least 32 payload bodies per body request, 128 blob hashes per blob request, 256 execution requests, 16 withdrawals, and 1,024 error-message bytes. It also keeps the payload transaction, blob, and extra-data bounds from the active Engine API. The payload ID path value must be an eight-byte hex string. A client can fall back to JSON-RPC when the peer does not support this transport.
Design rationale
SSZ avoids JSON hex expansion and repeated field parsing for large Engine API objects while retaining the existing authenticated port.