From 8c3803678467a4810b1d3d9f84a0e5814dd8d592 Mon Sep 17 00:00:00 2001 From: sktbrd Date: Tue, 1 Sep 2026 13:54:53 -0300 Subject: [PATCH] fix(builder-codes): put the code length after the code in the example suffix MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The `dataSuffix` example encodes the length byte before the code. `ox`, which this page recommends, encodes it after — and the Base builder dashboard issues the same order ox produces. page: 0x07 62617365617070 00 8021... length first ox: 0x62617365617070 07 00 8021... length after the code Verified with ox 0.14.34: Attribution.toDataSuffix({ codes: ["baseapp"] }) // 0x62617365617070070080218021802180218021802180218021 Same 25 bytes, same id byte, same trailing 8021 magic — only the length byte moves. Worth fixing because the wrong order fails quietly. Feeding the current example to ox's own parser throws nothing and returns a valid-looking result whose code is reversed, resolving to no registered builder: transactions index as unattributed, the integrator earns nothing, and no error is raised anywhere. We caught it only by pinning our suffix byte-for-byte against the value our dashboard issued. --- docs/specifications/builder-codes/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/specifications/builder-codes/overview.mdx b/docs/specifications/builder-codes/overview.mdx index 31c9106e7..58d1629d8 100644 --- a/docs/specifications/builder-codes/overview.mdx +++ b/docs/specifications/builder-codes/overview.mdx @@ -98,7 +98,7 @@ Wallets supporting ERC-5792 can use the `DataSuffixCapability` for clean suffix ], capabilities: { dataSuffix: { - value: "0x07626173656170700080218021802180218021802180218021", + value: "0x62617365617070070080218021802180218021802180218021", optional: true } }