tempo: transferWithMemo encoder accepts a non-hex memo and emits undecodable calldata

[mehmetkr-31]

Describe the bug

TempoMethod._encode_transfer_with_memo validates the memo's length but not that it is hexadecimal, then concatenates it into the calldata:

memo_clean = memo[2:] if memo.startswith("0x") else memo
if len(memo_clean) != 64:
    raise ValueError(f"memo must be exactly 32 bytes (64 hex chars), got {len(memo_clean)}")
return f"0x{selector}{to_padded}{amount_padded}{memo_clean.lower()}"

A 64-character non-hex memo passes that check and produces a transferWithMemo call no node can decode.

The two memo paths in this SDK disagree on the same input. The splits path goes through get_transfers and _parse_memo_bytes, which decodes the hex and raises VerificationError; the single-transfer path in TempoMethod.charge passes the raw string to the encoder. The memo arrives from the challenge's methodDetails, so it is server-supplied rather than caller-controlled.

This is not a security issue as far as I can tell — the calldata is malformed rather than misdirected, so the transaction is rejected rather than sent somewhere unintended. Filing it publicly on that basis.

Steps to reproduce

from mpp.methods.tempo.client import TempoMethod

encode = TempoMethod._encode_transfer_with_memo
address = "0x70997970c51812dc3a010c7d01b50e0d17dc79c8"

print(encode(None, address, 500000, "0x" + "zz" * 32))

Observed:

0x95777d59...07a120zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz

Whitespace ("0x" + " a" * 32) and non-ASCII ("0x" + "é" * 64) are accepted the same way. The sibling path rejects the first of those:

>>> from mpp.methods.tempo.intents import _parse_memo_bytes
>>> _parse_memo_bytes("0x" + "zz" * 32)
VerificationError: Invalid memo hex: 0xzzzz...

Logs

No response

Platform(s)

Mac (Apple Silicon), Linux (x86)

Container Type

Not running in a container

What version/commit are you on?

main — 9793ef5 (also present in 0.10.0)

If you've built from source, provide the full command you used

No response

---

Suggested fix

Decode the memo and emit memo_bytes.hex(), which also normalizes the output to canonical lowercase. Keeping the length check first preserves its message and position, so existing callers see no change.

I have this ready with tests on mehmetkr-31:fix/validate-memo-hex-on-encode (commit 35a4857): non-hex, whitespace and non-ASCII memos rejected; a short memo still reports the length error; uppercase hex normalizes. 808 passed, 41 skipped; ruff clean.

I could not open it as a pull request — this repository currently limits opening pull requests to collaborators — so the branch is on my fork if it is useful. Happy to adjust the approach.

The Go SDK made the same change in tempoxyz/mpp-go#100, which rejects non-hexadecimal 32-byte memos in EncodeTransferWithMemo.

Disclosure: I used an AI assistant while investigating and preparing this; the analysis and conclusions are my own to defend.

Code of Conduct

• I agree to follow the Code of Conduct

[mehmetkr-31]

I have a fix ready for this, but I cannot open a pull request — the repository currently limits PR creation to collaborators, so the compare page refuses it. The branch is pushed and can be pulled or cherry-picked as is:

mehmetkr-31:fix/validate-transfer-memo-hex @ f75269c
main...mehmetkr-31:pympp:fix/validate-transfer-memo-hex

What it does. Decodes the memo instead of only measuring it, so the encoder and the splits path agree on the same input:

try:
    memo_bytes = bytes.fromhex(memo_clean)
except ValueError as err:
    raise ValueError(f"memo must be hex, got {memo!r}") from err
if len(memo_bytes) != 32:
    raise ValueError(f"memo must be exactly 32 bytes (64 hex chars), got {len(memo_bytes)}")
return f"0x{selector}{to_padded}{amount_padded}{memo_bytes.hex()}"

Re-encoding the decoded bytes also normalizes case and rejects embedded whitespace, which bytes.fromhex would otherwise tolerate — "0x" + " a" * 32 is 64 characters and passed the old length check.

Coverage. A TestTransferWithMemoEncoding class: non-hex memos with and without the 0x prefix, the whitespace case, wrong-length memos still rejected with the existing message, valid memos accepted and normalized with calldata staying selector + 3 ABI words, and an explicit assertion that both memo paths accept and reject the same set of inputs. Four of the eight fail on main and pass on the branch. Full suite 817 passed, 41 skipped; ruff check and ruff format --check clean.

Prior art. mpp-go made the same change in tempoxyz/mpp-go#100, so this brings the Python SDK to parity rather than introducing a new rule.

Happy to open it as a PR if the restriction is lifted or if you would rather I did something else with the branch.

[mehmetkr-31]

Refreshed against current main (9677fac), since the branch I linked earlier was cut from 2b9a376 and main has moved six commits since.

Rebased, no conflicts: mehmetkr-31:fix/validate-transfer-memo-hex @ e2c4cf7
main...mehmetkr-31:pympp:fix/validate-transfer-memo-hex

I also re-confirmed the report still stands on 9677fac before touching anything — the encoder still measures the memo without decoding it:

memo_clean = memo[2:] if memo.startswith("0x") else memo
if len(memo_clean) != 64:
    raise ValueError(f"memo must be exactly 32 bytes (64 hex chars), got {len(memo_clean)}")
return f"0x{selector}{to_padded}{amount_padded}{memo_clean.lower()}"

so "0x" + "zz" * 32 still produces calldata whose trailing word is not hex.

Both memo paths agree on the branch:

input	encoder	_parse_memo_bytes
"0x" + "zz"*32	ValueError: memo must be hex	VerificationError
"0x" + " a"*32 (64 chars, whitespace)	ValueError: memo must be hex	VerificationError
"0x" + "ab"*10	ValueError: ... exactly 32 bytes	VerificationError
"0x" + "ab"*32	accepted	accepted
"0x" + "AB"*32	accepted, normalized to lowercase	accepted

876 passed, 41 skipped on current main; ruff check and ruff format --check clean.

Still unable to open this as a PR — the repository limits PR creation to collaborators — so the branch is pushed and current if you would like to pull it.