From 4cd83ee4b8abf63437aea2dd9df68b9b3b83bdb8 Mon Sep 17 00:00:00 2001 From: Ethan Date: Tue, 18 Aug 2026 05:16:53 +0100 Subject: [PATCH] Fix the migration notes for base-0004 in app/upgrades/data/changes.ts. ## Description The previous text described TEE signer registry handling, which belongs to the base-0001 Multiproofs upgrade rather than Engine API usage. The notes now reflect the requirements documented in the Azul engine-api-usage specification: V5 payload envelopes, engine_newPayloadV4, and the required empty blob and execution request fields. ## Change Updated migrationNotes for base-0004 to match the Engine API behavior documented in engine-api-usage. This removes the unrelated TEE/Nitro prover guidance and replaces it with migration guidance directly derived from the upgrade specification. --- app/upgrades/data/changes.ts | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/app/upgrades/data/changes.ts b/app/upgrades/data/changes.ts index 451c80d..6b21179 100644 --- a/app/upgrades/data/changes.ts +++ b/app/upgrades/data/changes.ts @@ -217,7 +217,7 @@ export const changes: Change[] = [ summary: "At and after Azul activation, block production and import use the following Engine API methods: engine_getPayloadV5 returns a V5 envelope, but the contained execution payload is still V4-shaped. As a result, payload insertion continues through engine_newPayloadV4 (there is no engine_newPayloadV5 path used by Base Azul clients).

Azul constraints for this flow:

", migrationNotes: - 'Use the registry as the source of accepted TEE signer identities instead of hard-coding Nitro prover signers.', + 'Node clients and libraries should handle the V5 payload envelope with an empty blobsBundle, continue inserting payloads through engine_newPayloadV4, and send empty expectedBlobVersionedHashes and executionRequests arrays.', lastUpdated: '2026-04-12', relatedRepos: [], githubIssues: [],