RLP decoders accept trailing bytes after valid data items

[afurm]

Summary

RLP scalar/data decoders accept inputs that contain a valid first RLP data item followed by trailing bytes. For example, decodeUint256(0x0102) returns 1, and decodeBytes(0x83646f6780) returns 0x646f67 (dog) while silently ignoring the trailing byte.

Expected behavior

The top-level scalar/data decoders should reject inputs that are not exactly one complete RLP data item, matching the behavior already enforced by decodeList.

Actual behavior

readUint256 checks only that _decodeLength returns ItemType.Data, and readBytes does the same. Neither checks that the decoded item consumes the full provided slice, so decodeBool, decodeUint256, decodeBytes32, decodeBytes, and decodeString can accept malformed input with trailing data.

Reproduction

await mock.$decodeUint256("0x0102") // returns 1
await mock.$decodeBytes("0x83646f6780") // returns 0x646f67
await mock.$decodeString("0x83646f6780") // returns dog

Impact

This is a correctness issue for consumers validating untrusted RLP payloads through these typed helpers. Malformed payloads can be accepted as if they were canonical single-item inputs.

[Amxx]

It is standard in solidity to ignore trailing bytes. For example, the built in abi.decoder will not fail if extra bytes are present. For consistency, we decided to build our RLP decoder with the same properties.

IMO, these extra bytes do not make the decoding ambiguous in any way. The fact that RLP encoding encodes the length of the data before the data makes means the extra bytes can't possibly be integrated into the decoding output. With the output not being ambiguous, we feel its better to have a smart contract process such inputs than to revert, leading to possible locks (unrecoverable value?)

Please do not open any PR until a decision has been made on wether we want this addressed or not.

[JunaidCD]

Hello @Amxx , I can see both sides here. The trailing bytes don't affect the decoded value itself since RLP already encodes lengths explicitly, but I also understand why some callers may want stricter validation guarantees for top-level payloads.

Would it make sense to support an opt-in strict decoding mode instead of changing the current default behavior?

[BhariGowda]

Acknowledging @Amxx's note happy to keep this draft/on-hold until the team decides on the desired behavior. If the opt-in strict mode approach @JunaidCD suggested is the direction, I can update the implementation accordingly.