From 585851e84e3a1c8c7799721740645837b5654235 Mon Sep 17 00:00:00 2001 From: thedavidmeister Date: Thu, 7 May 2026 13:29:29 +0400 Subject: [PATCH] document io byte layout above flowInit assembly MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The assembly block reading `flowInputs`/`flowOutputs` from the deployer-returned `io` bytes had no comment explaining the layout — why `add(io, 0x20)` skips the bytes length word and why bytes 0 and 1 are the relevant offsets. Added a per-block comment naming the deployer's per-source `(inputs, outputs)` byte-pair convention and the single-source flow entrypoint that pins source 0. Closes #350. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/concrete/Flow.sol | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/src/concrete/Flow.sol b/src/concrete/Flow.sol index 476e1aaf..5d4abaf1 100644 --- a/src/concrete/Flow.sol +++ b/src/concrete/Flow.sol @@ -200,6 +200,13 @@ contract Flow is ERC721Holder, ERC1155Holder, Multicall, ReentrancyGuard, IInter config.deployer.deployExpression2(config.bytecode, config.constants); { + // `io` is a `bytes` array. The deployer encodes per- + // source `(inputs, outputs)` pairs as consecutive + // bytes, with source 0 first. Flow only uses one + // source (`FLOW_ENTRYPOINT == 0`), so byte 0 is + // `flowInputs` and byte 1 is `flowOutputs`. + // `add(io, 0x20)` skips the bytes-length word to + // land on the first data word. uint256 flowInputs; uint256 flowOutputs; assembly ("memory-safe") {