From e7df10caeed9173cb5e0daaf0a2d923ce11b416a Mon Sep 17 00:00:00 2001 From: thedavidmeister Date: Thu, 7 May 2026 13:39:58 +0400 Subject: [PATCH] specify ordering guarantees in LibFlow.flow NatSpec MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The previous "Guarantees ordering of the transfers" was vague — it didn't say which ordering. The function actually guarantees two distinct orderings: token-class (ERC20 → ERC721 → ERC1155) and within-class (array index order). NatSpec now spells out both so a caller relying on either does not have to read the source. Closes #381. Co-Authored-By: Claude Opus 4.7 (1M context) --- src/lib/LibFlow.sol | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/src/lib/LibFlow.sol b/src/lib/LibFlow.sol index 3bfe7ce9..480bd61f 100644 --- a/src/lib/LibFlow.sol +++ b/src/lib/LibFlow.sol @@ -141,8 +141,12 @@ library LibFlow { /// Processes a flow transfer. Firstly sets state for the interpreter on the /// interpreter store. Then processes the ERC20, ERC721 and ERC1155 transfers - /// in the flow. Guarantees ordering of the transfers but DOES NOT prevent - /// reentrancy attacks. This is the responsibility of the caller. + /// in this order: all ERC20 transfers in `flowTransfer.erc20` array + /// index order, then all ERC721 transfers in `flowTransfer.erc721` + /// array index order, then all ERC1155 transfers in + /// `flowTransfer.erc1155` array index order. + /// DOES NOT prevent reentrancy attacks. This is the responsibility of + /// the caller. /// `set` is skipped entirely when `kvs.length == 0`. Stores that need to /// observe every flow invocation (e.g. for audit logging) cannot rely on /// `set` being called for empty kvs.