Solana Namespace - JSON-RPC Provider Authorization

CAIP-25

For context, see the CAIP-25 specification.

Rationale

In the Solana ecosystem, standardization of the RPC provider interface has centered on the Wallet Standard and Wallet Adapter open-source tooling. For the most part, progressive CAIP-25 negotiation and iteration is possible over a Wallet Standard connection, with the former inheriting the declaration of initial capabilities and permissions made in the latter as initial state for further negotation.

Network-Specific versus Namespace-Wide Scopes

Few use-cases incorporating multiple Solana-compatible networks require granular permissions or capability declarations per-chain, so a Solana-wide CAIP-217 authorization scope (keyed to the entire solana namespace rather than to a specific chain), with permissions and capabilities set and with only one member at a time in the chains array, is recommended in most cases.

Multichain Considerations

Developers addressing multichain use-cases incorporating non-Solana networks are RECOMMENDED to use distinct CAIP-217 authorization objects per chain type, in cases where those CAIP-25 capabilities and configurations can be deterministically mapped to Wallet Standard Multichain Extensions variables by a CAIP-25 provider.

Also, consumers of the Wallet Standard interface assume the WalletAdapterNetwork enum variable to be set to exactly one network at a time, so implementers are recommended to map only one chains member at a time to this standard interface, whether by ordering it by preference or by never allowing it to have more than one member at a time.

Setting Environmental Variables to pass via Wallet Standard

Wallet capabilities in the Wallet Standard model are declared upfront at time of connection and persisted as read-only constants. For maximum interoperability and stability, wallets are recommended to declare these variables explicitly in the scopedProperties object corresponding to each Solana scope they authorize when accepting a CAIP-25 connection. Note that the scopedProperties object is partitioned to parallel the sessionScopes, so duplicate entries need to be made for each Solana scope.

Examples

Example CAIP-25 Request

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "provider_authorize",
  "params": {
    "sessionScopes": {
      "bip122": { ... },
      "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp": { ... }
      "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1": { ... }
    },
  }
}

Example CAIP-25 Response

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "provider_authorize",
  "params": {
    "sessionScopes": {
      "bip122": { ... },
      "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp": { ... }
      "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1": { ... }
    },
    "scopedProperties": {
      "bip122": { ... }
      "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp": {
        "supportedTransactionVersions": ["legacy", "0"]
      }
      "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1": {
        "supportedTransactionVersions": ["0"]
      }
    }         
  }
}

References

• EIP155: Ethereum Improvement Proposal specifying generation and validation of ChainIDs
• Wallet Standard Interface specification
• Wallet Adapter Tooling
• Wallet Standard Multichain Extensions
• Transaction Version Declaration

Rights

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Jon Wong, Glitch, bumblefudge, "namespaces/solana-caip25: Solana Namespace - JSON-RPC Provider Authorization [DRAFT]," Chain Agnostic Namespaces, solana-caip25, February 2024 / February 2024. [Online serial]. Available: https://github.com/ChainAgnostic/namespaces/solana-caip25.md