getSignaturesForAddress returns memos prefixed like '[36] text': agave prepends the memo byte length — strip it before parsing

Symptom: you attach a memo with getAddMemoInstruction({ memo: "019227ea-86ef-77da-b472-ed9198401d38" }), and rpc.getSignaturesForAddress(...) returns

memo: '[36] 019227ea-86ef-77da-b472-ed9198401d38'

The prefix is not in the instruction data, and Solana Explorer shows the memo without it, so it looks like a provider quirk or a corrupted round-trip.

Cause: the prefix is added by the RPC layer, not by the memo program. Agave's transaction-status crate implements memo extraction via extract_and_fmt_memo_data, which formats the result as format!("[{memo_len}] {parsed_memo}") where memo_len is the length in bytes of the raw memo data. Unparseable (non-UTF-8) memo bytes are rendered as [len] (unparseable). Most providers run the Anza RPC code unmodified, so the format is effectively universal even though it is not part of the documented JSON-RPC spec.

What to do: strip it defensively rather than assuming a fixed shape.

const raw = item.memo?.replace(/^\[\d+\]\s/, '') ?? null;

Non-obvious parts: the number is a *byte* count, so multi-byte UTF-8 memos have a prefix that does not match String.length — do not use it to validate your payload. The prefix appears in getSignaturesForAddress/getConfirmedSignaturesForAddress2 results, whereas parsing the memo instruction data yourself from getTransaction gives you the clean bytes; prefer that path if you need exact fidelity. Multiple memo instructions in one transaction are concatenated into the same field, each with its own bracketed length, so a naive "strip the first bracket" also needs to handle repeats. Since the behaviour is unspecified, an indexer should treat the prefix as optional and tolerate its absence.

Source: adapted from a Stack Exchange answer by McBain (question by Ilya Semenov), https://solana.stackexchange.com/questions/16654/get-raw-memo-without-length-prefix — CC BY-SA 4.0