Naming Conventions

This section is advisory.

Naming Conventions

The agentic commerce protocols are structurally different, so a single wire format cannot apply everywhere. The LCP standard defines three conventions depending on the field type.

String Fields: The lcp: Prefix

For string fields (e.g., MPP opaque, ACP metadata values), use the lcp: prefix with a type indicator:

lcp:{type}:{value}

Self-identifying — any parser checks startsWith("lcp:"), then reads the type to know how to resolve the value.

Parsing rule: Split on the first colon to get lcp (the namespace). Split on the second colon to get the type. Everything after the second colon is the value (which may itself contain colons, e.g., in URLs).

Structured JSON: The legalContext Key

For structured JSON fields (e.g., ACP session metadata, A2A task metadata, UCP extensions), use a standard key — "legalContext" — with type and value fields:

{
  "legalContext": {
    "type": "sha256",
    "value": "0x7f83b165..."
  }
}

Raw Byte Fields

For raw byte fields (e.g., TIP-20 32-byte memo), no prefix — there is no room. The per-protocol integration guide defines the meaning for that specific field.

Note: MPP's SDK auto-generates an attribution memo in the TIP-20 memo field only when no user-provided memo is present. Providing a contentHash replaces the default attribution. See the MPP integration page for details.

Known Types

The type set is extensible. This is not a closed set.

New types can be added without changing the specification.