From 436c1bc55e8ef0cb26d2bc5de4c27b9925a2a4f2 Mon Sep 17 00:00:00 2001 From: Mikhail Kalinin Date: Thu, 2 Feb 2023 10:25:22 +0400 Subject: [PATCH] Fix `exchangeCapabilities` examples --- src/engine/common.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/engine/common.md b/src/engine/common.md index 791a3663a..ada881082 100644 --- a/src/engine/common.md +++ b/src/engine/common.md @@ -164,13 +164,13 @@ Execution layer clients **MUST** support `engine_exchangeCapabilities` method, w 2. Request and response lists **MUST** contain Engine API methods that are currently supported by consensus and execution client software respectively. Name of each method in both lists **MUST** include suffixed version. Consider the following examples: * Client software of both layers currently supports `V1` and `V2` versions of `engine_newPayload` method: - * params: `["engine_newPayloadV1", "engine_newPayloadV2", ...]`, + * params: `[["engine_newPayloadV1", "engine_newPayloadV2", ...]]`, * response: `["engine_newPayloadV1", "engine_newPayloadV2", ...]`. * `V1` method has been deprecated and `V3` method has been introduced on execution layer side since the last call: - * params: `["engine_newPayloadV1", "engine_newPayloadV2", ...]`, + * params: `[["engine_newPayloadV1", "engine_newPayloadV2", ...]]`, * response: `["engine_newPayloadV2", "engine_newPayloadV3", ...]`. * The same capabilities modification has happened in consensus layer client, so, both clients have the same capability set again: - * params: `["engine_newPayloadV2", "engine_newPayloadV3", ...]`, + * params: `[["engine_newPayloadV2", "engine_newPayloadV3", ...]]`, * response: `["engine_newPayloadV2", "engine_newPayloadV3", ...]`. 3. The `engine_exchangeCapabilities` method **MUST NOT** be returned in the response list.