Pathfinder felts (and other numbers) are serialized (everywhere their serialization is needed) to hexadecimal strings ("0x123456789abcdef") and deserialized from that format, with the prefix considered optional (so that "123456789abcdef" will also parse). This works, but is not strictly following the JSON-RPC spec, which generally considers the prefix mandatory, e.g. when specifying
"STORAGE_KEY": {
"type": "string",
"title": "Storage key",
"$comment": "A storage key, represented as a string of hex digits",
"description": "A storage key. Represented as up to 62 hex digits, 3 bits, and 5 leading zeroes.",
"pattern": "^0x(0|[0-7]{1}[a-fA-F0-9]{0,62}$)"
},
(as well as in other places). The non-prefixed format is also incompatible with Juno, and potentially confusing: for serialized numbers containing just digits (like "123456789"), it isn't immediately obvious whether they're decimal or hexadecimal.
The "0x" prefix should be made mandatory (with deserialization failing for strings that don't have it), at least at the JSON-RPC interface.
Pathfinder felts (and other numbers) are serialized (everywhere their serialization is needed) to hexadecimal strings ("0x123456789abcdef") and deserialized from that format, with the prefix considered optional (so that "123456789abcdef" will also parse). This works, but is not strictly following the JSON-RPC spec, which generally considers the prefix mandatory, e.g. when specifying
(as well as in other places). The non-prefixed format is also incompatible with Juno, and potentially confusing: for serialized numbers containing just digits (like "123456789"), it isn't immediately obvious whether they're decimal or hexadecimal.
The "0x" prefix should be made mandatory (with deserialization failing for strings that don't have it), at least at the JSON-RPC interface.