Description
LibFlow.flowERC1155 carries two @todo comments that have outlived multiple flow-interface revisions:
// @todo safeBatchTransferFrom support.
// @todo data support.
IERC1155(transfer.token).safeTransferFrom(transfer.from, transfer.to, transfer.id, transfer.amount, "");
Neither is a correctness defect today:
- The current per-transfer
safeTransferFrom loop is semantically equivalent to a batched call for compliant ERC1155 implementations; the difference is gas, not correctness.
- Passing empty
"" data is spec-compliant — receivers' onERC1155Received MUST handle empty data per EIP-1155.
But leaving open @todo markers in a security-critical "live" library obscures whether they are deferred features, planned breaking changes, or forgotten cruft. A reader auditing this file cannot tell from the comment alone whether handing "" to a receiver is intentional final behaviour or a placeholder pending design.
File:Line
src/lib/LibFlow.sol:127-129
Proposed fix
Replace the inline @todos with a tracked GitHub issue and a comment that states the design decision.
Diff:
- // @todo safeBatchTransferFrom support.
- // @todo data support.
+ // ERC1155 transfers are dispatched one-by-one rather than via
+ // safeBatchTransferFrom, and with empty data. This is
+ // semantically equivalent to a batch for spec-compliant tokens
+ // and is the final FlowV5 behaviour; passing per-transfer data
+ // and batching are deferred to a future flow interface (see
+ // issue #<NEW>).
IERC1155(transfer.token).safeTransferFrom(transfer.from, transfer.to, transfer.id, transfer.amount, "");
If the project intends to actually add batch / data support, file a tracking issue and reference it from the comment. If it does not, delete the TODOs entirely.
Description
LibFlow.flowERC1155carries two@todocomments that have outlived multiple flow-interface revisions:Neither is a correctness defect today:
safeTransferFromloop is semantically equivalent to a batched call for compliant ERC1155 implementations; the difference is gas, not correctness.""data is spec-compliant — receivers'onERC1155ReceivedMUST handle empty data per EIP-1155.But leaving open
@todomarkers in a security-critical "live" library obscures whether they are deferred features, planned breaking changes, or forgotten cruft. A reader auditing this file cannot tell from the comment alone whether handing""to a receiver is intentional final behaviour or a placeholder pending design.File:Line
src/lib/LibFlow.sol:127-129Proposed fix
Replace the inline
@todos with a tracked GitHub issue and a comment that states the design decision.Diff:
If the project intends to actually add batch / data support, file a tracking issue and reference it from the comment. If it does not, delete the TODOs entirely.