Current behavior
We use informal network strings like hathor:privatenet, hathor:testnet, hathor:mainnet. These are close to CAIP-2 but not formally registered.
Required behavior
The x402 V2 spec uses CAIP-2 chain identifiers. For EVM chains this is eip155:<chainId>, for Solana solana:<genesisHash>.
Hathor needs a CAIP-2 namespace. The format should be:
hathor:mainnet
hathor:testnet
hathor:privatenet
This is already what we use, but it needs to be:
- Formally documented as Hathor's CAIP-2 namespace
- Registered with ChainAgnostic/namespaces
- Used consistently across all protocol messages
Changes needed
All files
- Audit all hardcoded network strings and ensure they follow
hathor:<network> format consistently
- The
config.network value should be used everywhere instead of hardcoded strings
External
Current network strings in code
The resource server has hathor:${config.network} in some places, which is correct. The facilitator has some hardcoded hathor:privatenet strings that need to use config.
References
Current behavior
We use informal network strings like
hathor:privatenet,hathor:testnet,hathor:mainnet. These are close to CAIP-2 but not formally registered.Required behavior
The x402 V2 spec uses CAIP-2 chain identifiers. For EVM chains this is
eip155:<chainId>, for Solanasolana:<genesisHash>.Hathor needs a CAIP-2 namespace. The format should be:
This is already what we use, but it needs to be:
Changes needed
All files
hathor:<network>format consistentlyconfig.networkvalue should be used everywhere instead of hardcoded stringsExternal
hathornamespaceCurrent network strings in code
The resource server has
hathor:${config.network}in some places, which is correct. The facilitator has some hardcodedhathor:privatenetstrings that need to use config.References