Protocol Map
WalletPair currently defines three normative protocols. They are not SDK layers and no capability-negotiation or generic application sub-protocol is defined.
| Specification | Responsibility | Public data |
|---|---|---|
| Encryption | QR pairing, X25519/HKDF keys, MessagePack, AEAD, replay protection | Channel ID, metadata, public keys, CAIP-2 suffix, timing, size |
| Relay | WebSocket validation, join events, in-channel forwarding | Connection query fields and unchanged application frames |
| Ethereum | EIP-1193 requests, responses, events, and method security rules | Authenticated eip155:<decimal> routing suffix |
How a request travels
- The dApp creates an EIP-1193 request and selects a canonical EIP-155 chain.
- The encryption layer MessagePack-encodes and seals it with the dApp-to-wallet key.
- The relay forwards the opaque
sealed@eip155:…text frame. - The wallet verifies the sequence and tag, decodes MessagePack, validates the request, and responds on the same suffix.
Future chain ecosystems need their own reviewed application specification. Do not infer support for Solana, Sui, Bitcoin, or any other ecosystem from the chain-agnostic encryption framing alone.