From 3c0f6f62a95a795f932db72fa4cb607972a1e9cb Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 6 Feb 2024 18:43:07 -0800 Subject: [PATCH 01/21] solana/caip25.md initial draft, missing examples --- solana/caip25.md | 66 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 solana/caip25.md diff --git a/solana/caip25.md b/solana/caip25.md new file mode 100644 index 00000000..4f6b7994 --- /dev/null +++ b/solana/caip25.md @@ -0,0 +1,66 @@ +--- +namespace-identifier: solana-caip25 +title: Solana Namespace - JSON-RPC Provider Authorization +author: Jon Wong (@jnwng), Glitch (@glitch) bumblefudge (@bumblefudge) +discussions-to: https://github.com/anza-xyz/wallet-adapter/issues/807 +status: Draft +type: Standard +created: 2024-02-05 +updated: 2024-02-05 +requires: ["CAIP-25", "CAIP-217"] +--- + +# 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 Adapter] standard and open-source tooling. +For the most part, progressive [CAIP-25] negotiation and iteration is possible over a [Wallet Adaptor] connection, with the former inheriting the declaration of initial capabilities and permissions made in the latter as initial state. + +## 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 with identical permissions and capabilities across one or more chains is recommended in most cases. + +Multi-chain use-cases incorporating non-Solana chains should use distinct [CAIP-217] authorization objects per chain type, in cases where those [CAIP-25] capabilities and configurations can be deterministically mapped to [Wallet Adapter Multichain Extensions] variables by a [CAIP-25] provider. + +## Session Properties + +Wallet capabilities in the [Wallet Adapter] model are declared upfront at time of connection and persisted as read-only constants, so wallets are recommended to declare them explicitly in the `sessionProperties` object in a [CAIP-25] interaction for maximum interoperability and stability. +Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, so to avoid collisions the following properties names are recommended for easy mapping to WalletAdapter properties: + +|`sessionProperties` key in [CAIP-25] expression|[WalletAdapter] mapping|values|documentation|reference implementation| +|`solanaTransactionVersion`|`SolanaTransactionVersion`|`0` or `legacy` (default)|[solana.com][Transaction Version Declaration]|[github.com][Transaction Version Refimpl] +|`solanaTransactionCommitment`|`SolanaTransactionCommitment`|`finalized` (default), `confirmed`, `processed`|[solana.com][State Commitment Declaration]|[github.com][State Commitment Refimpl]| + +As these properties are mandatory and required for stability in [Wallet Adapter] connections, [CAIP-25] providers MAY inject defaults for all of the above based on prior knowledge or out-of-date registries. +For this reason, wallets are RECOMMENDED to set them explicitly even if not requested by their counterparty to avoid default values growing stale. + +## Examples + +TBD + +## References + +- [EIP155][]: Ethereum Improvement Proposal specifying generation and validation of ChainIDs +- [Wallet Adapter Standard][Wallet Adapter]: Interface specification +- [Wallet Adapter Tooling] +- [Wallet Adapter Multichain Extensions] +- [Transaction Version Declaration] +- [State Commitment Declaration] + +[Wallet Adapter Multichain Extensions]: https://github.com/wallet-standard/wallet-standard/blob/master/EXTENSIONS.md +[Transaction Version Declaration]: https://solana.com/docs/core/transactions/versions#current-transaction-versions +[Transaction Version Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L31 +[State Commitment Declaration]: https://solana.com/docs/rpc#configuring-state-commitment +[State Commitment Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L66 +[Wallet Adapter Tooling]: https://github.com/anza-xyz/wallet-adapter/tree/master?tab=readme-ov-file#wallet-adapter +[Wallet Adapter]: https://wallet-standard.github.io/wallet-standard/ +[CAIP-25]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-25.md +[CAIP-217]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-217.md +[EIP155]: https://eips.ethereum.org/EIPS/eip-155 + +## Rights + +Copyright and related rights waived via CC0. From 36d3e6311b307a2c5785a62405735568f8fcf3df Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 6 Feb 2024 18:56:00 -0800 Subject: [PATCH 02/21] fix typos and link name convention --- solana/caip25.md | 41 +++++++++++++++++++++-------------------- 1 file changed, 21 insertions(+), 20 deletions(-) diff --git a/solana/caip25.md b/solana/caip25.md index 4f6b7994..1fbd509d 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -16,26 +16,27 @@ _For context, see the [CAIP-25][] specification._ ## Rationale -In the Solana ecosystem, standardization of the RPC provider interface has centered on the [Wallet Adapter] standard and open-source tooling. -For the most part, progressive [CAIP-25] negotiation and iteration is possible over a [Wallet Adaptor] connection, with the former inheriting the declaration of initial capabilities and permissions made in the latter as initial state. +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 with identical permissions and capabilities across one or more chains is recommended in most cases. +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 identical permissions and capabilities across one or more chains, is recommended in most cases. -Multi-chain use-cases incorporating non-Solana chains should use distinct [CAIP-217] authorization objects per chain type, in cases where those [CAIP-25] capabilities and configurations can be deterministically mapped to [Wallet Adapter Multichain Extensions] variables by a [CAIP-25] provider. +Multi-chain use-cases incorporating non-Solana chains should 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. ## Session Properties -Wallet capabilities in the [Wallet Adapter] model are declared upfront at time of connection and persisted as read-only constants, so wallets are recommended to declare them explicitly in the `sessionProperties` object in a [CAIP-25] interaction for maximum interoperability and stability. -Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, so to avoid collisions the following properties names are recommended for easy mapping to WalletAdapter properties: +Wallet capabilities in the [Wallet Standard] model are declared upfront at time of connection and persisted as read-only constants, so wallets are recommended to declare them explicitly in the `sessionProperties` object in a [CAIP-25] interaction for maximum interoperability and stability. +Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, which may span multiple types of networks all declaring `sessionProperties`, so to avoid collisions the following properties names are recommended for easy mapping to the **case-sensitive** properties names in the [Wallet Standard]: |`sessionProperties` key in [CAIP-25] expression|[WalletAdapter] mapping|values|documentation|reference implementation| -|`solanaTransactionVersion`|`SolanaTransactionVersion`|`0` or `legacy` (default)|[solana.com][Transaction Version Declaration]|[github.com][Transaction Version Refimpl] -|`solanaTransactionCommitment`|`SolanaTransactionCommitment`|`finalized` (default), `confirmed`, `processed`|[solana.com][State Commitment Declaration]|[github.com][State Commitment Refimpl]| +|---|---|---|---|---| +|`SolanaTransactionVersion`|`SolanaTransactionVersion`|`0` or `legacy` (default)|[solana.com][Transaction Version Declaration]|[github.com][Transaction Version Refimpl]| +|`SolanaTransactionCommitment`|`SolanaTransactionCommitment`|`finalized` (default), `confirmed`, `processed`|[solana.com][State Commitment Declaration]|[github.com][State Commitment Refimpl]| -As these properties are mandatory and required for stability in [Wallet Adapter] connections, [CAIP-25] providers MAY inject defaults for all of the above based on prior knowledge or out-of-date registries. -For this reason, wallets are RECOMMENDED to set them explicitly even if not requested by their counterparty to avoid default values growing stale. +As these properties are mandatory and required for stability in [Wallet Standard] connections, [CAIP-25] providers MAY inject defaults for all of the above based on prior knowledge or out-of-date registries. +For this reason, wallets are RECOMMENDED to set them explicitly even if not requested by their counterparty to avoid inaccurate values being injected. ## Examples @@ -44,19 +45,19 @@ TBD ## References - [EIP155][]: Ethereum Improvement Proposal specifying generation and validation of ChainIDs -- [Wallet Adapter Standard][Wallet Adapter]: Interface specification -- [Wallet Adapter Tooling] -- [Wallet Adapter Multichain Extensions] -- [Transaction Version Declaration] -- [State Commitment Declaration] - -[Wallet Adapter Multichain Extensions]: https://github.com/wallet-standard/wallet-standard/blob/master/EXTENSIONS.md +- [Wallet Standard][] Interface specification +- [Wallet Adapter][] Tooling +- [Wallet Standard Multichain Extensions][] +- [Transaction Version Declaration][] +- [State Commitment Declaration][] + +[Wallet Adapter]: https://github.com/anza-xyz/wallet-adapter/tree/master?tab=readme-ov-file#wallet-adapter +[Wallet Standard]: https://wallet-standard.github.io/wallet-standard/ +[Wallet Standard Multichain Extensions]: https://github.com/wallet-standard/wallet-standard/blob/master/EXTENSIONS.md [Transaction Version Declaration]: https://solana.com/docs/core/transactions/versions#current-transaction-versions [Transaction Version Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L31 [State Commitment Declaration]: https://solana.com/docs/rpc#configuring-state-commitment -[State Commitment Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L66 -[Wallet Adapter Tooling]: https://github.com/anza-xyz/wallet-adapter/tree/master?tab=readme-ov-file#wallet-adapter -[Wallet Adapter]: https://wallet-standard.github.io/wallet-standard/ +[State Commitment Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L660 [CAIP-25]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-25.md [CAIP-217]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-217.md [EIP155]: https://eips.ethereum.org/EIPS/eip-155 From 86ac2f8660ed3e849738c3b649213bc39b5762fb Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 6 Feb 2024 18:58:44 -0800 Subject: [PATCH 03/21] wordsmithing --- solana/caip25.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/solana/caip25.md b/solana/caip25.md index 1fbd509d..07910ae4 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -30,12 +30,12 @@ Multi-chain use-cases incorporating non-Solana chains should use distinct [CAIP- Wallet capabilities in the [Wallet Standard] model are declared upfront at time of connection and persisted as read-only constants, so wallets are recommended to declare them explicitly in the `sessionProperties` object in a [CAIP-25] interaction for maximum interoperability and stability. Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, which may span multiple types of networks all declaring `sessionProperties`, so to avoid collisions the following properties names are recommended for easy mapping to the **case-sensitive** properties names in the [Wallet Standard]: -|`sessionProperties` key in [CAIP-25] expression|[WalletAdapter] mapping|values|documentation|reference implementation| +|`sessionProperties` key in [CAIP-25] expression|[Wallet Adapter] mapping|values|documentation|reference implementation| |---|---|---|---|---| |`SolanaTransactionVersion`|`SolanaTransactionVersion`|`0` or `legacy` (default)|[solana.com][Transaction Version Declaration]|[github.com][Transaction Version Refimpl]| |`SolanaTransactionCommitment`|`SolanaTransactionCommitment`|`finalized` (default), `confirmed`, `processed`|[solana.com][State Commitment Declaration]|[github.com][State Commitment Refimpl]| -As these properties are mandatory and required for stability in [Wallet Standard] connections, [CAIP-25] providers MAY inject defaults for all of the above based on prior knowledge or out-of-date registries. +As these properties are mandatory and required for stability in [Wallet Standard] connections, [CAIP-25] providers MAY inject defaults if any of the above are not set explicitly by a wallet. For this reason, wallets are RECOMMENDED to set them explicitly even if not requested by their counterparty to avoid inaccurate values being injected. ## Examples From c50089748e58336b74847fb87236be40b57478be Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 6 Feb 2024 19:01:09 -0800 Subject: [PATCH 04/21] wordsmithing --- solana/caip25.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/solana/caip25.md b/solana/caip25.md index 07910ae4..b2b8784d 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -23,7 +23,9 @@ For the most part, progressive [CAIP-25] negotiation and iteration is possible o 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 identical permissions and capabilities across one or more chains, is recommended in most cases. -Multi-chain use-cases incorporating non-Solana chains should 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. +## Multi-Chain Considerations + +Developers addressing multi-chain 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. ## Session Properties From 5e4243cb6471a2b209a7e78b045f6201b2d47377 Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 6 Feb 2024 19:03:11 -0800 Subject: [PATCH 05/21] fix typo --- solana/caip25.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solana/caip25.md b/solana/caip25.md index b2b8784d..5367536f 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -59,7 +59,7 @@ TBD [Transaction Version Declaration]: https://solana.com/docs/core/transactions/versions#current-transaction-versions [Transaction Version Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L31 [State Commitment Declaration]: https://solana.com/docs/rpc#configuring-state-commitment -[State Commitment Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L660 +[State Commitment Refimpl]: https://github.com/anza-xyz/wallet-standard/blob/2c354cf07daa1d440ba9631fcefc5c00b07aa9dd/packages/core/features/src/signTransaction.ts#L66 [CAIP-25]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-25.md [CAIP-217]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-217.md [EIP155]: https://eips.ethereum.org/EIPS/eip-155 From 2cbce8b9cb90cc05a692397a678042e969a4f92e Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Tue, 6 Feb 2024 20:54:43 -0800 Subject: [PATCH 06/21] Update solana/caip25.md apologies! Co-authored-by: Glitch <66949816+glitch-txs@users.noreply.github.com> --- solana/caip25.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/solana/caip25.md b/solana/caip25.md index 5367536f..0fde6816 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -1,7 +1,7 @@ --- namespace-identifier: solana-caip25 title: Solana Namespace - JSON-RPC Provider Authorization -author: Jon Wong (@jnwng), Glitch (@glitch) bumblefudge (@bumblefudge) +author: Jon Wong (@jnwng), Glitch (@glitch-txs) bumblefudge (@bumblefudge) discussions-to: https://github.com/anza-xyz/wallet-adapter/issues/807 status: Draft type: Standard From a97e6cbaf6388e8e239d9c266c20ab6fe5a3a9e3 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 14 Feb 2024 15:07:31 -0800 Subject: [PATCH 07/21] Update solana/caip25 to mention WalletAdapterNetwork variable in Wallet Standard interface --- solana/caip25.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/solana/caip25.md b/solana/caip25.md index 0fde6816..82fe58d9 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -21,7 +21,9 @@ For the most part, progressive [CAIP-25] negotiation and iteration is possible o ## 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 identical permissions and capabilities across one or more chains, is recommended in most cases. +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. + +Implementers wishing to conform to the Solana [Wallet Standard][] should note that the `WalletAdapterNetwork` enum variable is set to only one network at a time, and thus are recommended to map only one `chains` member at a time to this standard interface. ## Multi-Chain Considerations From 52b6644cbedc6e1d86c146650ee08b8a18ca66d5 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 14 Feb 2024 15:14:10 -0800 Subject: [PATCH 08/21] wordsmith previous commit --- solana/caip25.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/solana/caip25.md b/solana/caip25.md index 82fe58d9..6b10eefd 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -23,11 +23,11 @@ For the most part, progressive [CAIP-25] negotiation and iteration is possible o 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. -Implementers wishing to conform to the Solana [Wallet Standard][] should note that the `WalletAdapterNetwork` enum variable is set to only one network at a time, and thus are recommended to map only one `chains` member at a time to this standard interface. - ## Multi-Chain Considerations -Developers addressing multi-chain 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. +Developers addressing multi-chain 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. ## Session Properties From 71fd5c3a57fde00abd3d79d9462f4bb03131087a Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Mon, 27 May 2024 19:14:38 +0200 Subject: [PATCH 09/21] add example --- solana/caip25.md | 28 ++++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/solana/caip25.md b/solana/caip25.md index 6b10eefd..cc053b43 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -32,7 +32,7 @@ Also, consumers of the [Wallet Standard][] interface assume the `WalletAdapterNe ## Session Properties Wallet capabilities in the [Wallet Standard] model are declared upfront at time of connection and persisted as read-only constants, so wallets are recommended to declare them explicitly in the `sessionProperties` object in a [CAIP-25] interaction for maximum interoperability and stability. -Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, which may span multiple types of networks all declaring `sessionProperties`, so to avoid collisions the following properties names are recommended for easy mapping to the **case-sensitive** properties names in the [Wallet Standard]: +Note that the `sessionProperties` object is shared across any and all namespaces in a given wallet<>application session, which may span multiple types of networks all declaring `sessionProperties`, so to avoid collisions the following properties names are recommended for easily mapping to the **case-sensitive** properties names in the [Wallet Standard]: |`sessionProperties` key in [CAIP-25] expression|[Wallet Adapter] mapping|values|documentation|reference implementation| |---|---|---|---|---| @@ -44,7 +44,31 @@ For this reason, wallets are RECOMMENDED to set them explicitly even if not requ ## Examples -TBD +Example CAIP-25 Request + +```json + +{ + "id": 1, + "jsonrpc": "2.0", + "method": "provider_authorize", + "params": { + "optionalScopes": { + "eip155": { ... }, + "solana": { ... } + }, + "sessionProperties": { + "capabilities": { ... } + "eip155": { ... } + "solana": { + "SolanaTransactionVersion": "0", + "SolanaTransactionCommitment": "finalized" + } + } + } +} + +``` ## References From 5c515816a2828914bb77a3ed92f9445d2e29f785 Mon Sep 17 00:00:00 2001 From: Philip Halsall Date: Mon, 3 Jun 2024 15:56:46 +0700 Subject: [PATCH 10/21] updating links to docs --- mina/caip2.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mina/caip2.md b/mina/caip2.md index 47c0e5d3..02411283 100644 --- a/mina/caip2.md +++ b/mina/caip2.md @@ -35,7 +35,7 @@ The type of network may be: - devnet, indicating a stable copy of the network used for developer testing. - testnet, indicating a less stable copy of the network where new features can be deployed and tested. -The names chosen above are taken from the signature schema's for each blockchain and current network identifiers can be found in the documentation [here](https://docs2-git-major-upgrade-minadocs.vercel.app/node-operators) +The names chosen above are taken from the signature schema's for each blockchain and current network identifiers can be found in the documentation [here](https://docs.minaprotocol.com/node-operators) ## Syntax From 39f733e3d5e36c2ec3141ce9d3117f0bfa93ca20 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 5 Jun 2024 16:35:56 +0200 Subject: [PATCH 11/21] add modern address types and decorators to bip122/caip10 --- bip122/caip10.md | 67 +++++++++++++++++++++++++++++++++++------------- 1 file changed, 49 insertions(+), 18 deletions(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index 3a304ea7..31f879cd 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -1,30 +1,54 @@ --- namespace-identifier: bip122-caip10 title: BIP122 Namespace - Addresses -author: Simon Warta (@webmaster128), ligi , Pedro Gomes (@pedrouid) +author: Simon Warta (@webmaster128), ligi , Pedro Gomes (@pedrouid), bumblefudge (@bumblefudge) discussions-to: https://github.com/ChainAgnostic/namespaces/pulls/3 status: Draft type: Standard created: 2019-12-05 -updated: 2022-03-27 +updated: 2024-06-05 requires: ["CAIP-2", "CAIP-10"] replaces: CAIP-4 --- -# CAIP-10 - *For context, see the [CAIP-10][] specification.* ## Rationale While Ethereum "accounts" were the unstated norm in the definition of -[CAIP-10][], the "script hashes" addressing schemed defined by [BIP13][] map +[CAIP-10][], the "script hashes" addressing scheme defined by [BIP13][] map well enough to "account"-model blockchains that these can be described by a -CAIP-10 reference. +CAIP-10 reference as "addresses". Other aspects of the UTXO wallet and transaction model (choice of inputs, arbitrary data in witness sections of a segwit transaction, multi-party signature methods, etc.) are topics of ongoing research and community input is welcome, although additional CAIPs may be needed to specify them for chain-agnostic purposes. ## Syntax -See [Specification section of BIP13](https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki#Specification). +At time of writing, only three kinds of address are currently in wide use, with a fourth mostly obsolete in modern usage. +All four, in their most common ASCII base-encodings (base-58-btc, bech32, and bech32m; see below) are of a short enough length to simply include them in their entirety as the `account_address` segment of a [CAIP-10] identifier. +This choice not to transform or subset addresses preserves checksum, sortability, and detectability features of all three modern address types, while also minimizing collision risk. + +In order of their adoption, the four types of addresses in Bitcoin are: + +1. Legacy address, aka pay-to-publickey-hash (P2PKH). These begin with `1` and are [base58btc]-encoded. Defined in the [bitcoin whitepaper][], these are exceedingly rare in contemporary practice due to higher transaction fees and limited functionality compared to the newer types described below. Legacy addresses are not derived from "extended keys" as per the subsequent [BIP44] standard, but are rather hashes of unique public keys, which makes them a weak analogue to addresses in "account-model" systems; for these reasons, they are excluded from [CAIP-10] usage. +2. Pay-to-script-hash (P2SH) address. These were specified in the early [BIP13], and swiftly became the dominant address and signature type in the early years of Bitcoin usage after becoming supported by a [soft fork][BIP16] in 2012. They are [base58btc]-encoded and always begin with `3` in ASCII form. +3. Native Segregated-Witness Address (SegWit), aka pay-to-wrapped-publickey-hash (P2WPKH) Address. The derivation of these was standardized in [BIP84], and the soft-fork supporting them at the protocol level coordinated by [BIP141]. They are encoded into ASCII according to the [`bech32`][BIP173] algorithm, and always begin with `bc1q`. At time of press, these are nearly universal due to lower transaction fees and higher security than older types. +4. Taproot (P2TR). They are encoded into ASCII according to the [`bech32m`][BIP350] algorithm, and always begin with `bc1q`. Not all wallets support taproot addresses at time of writing, but a Taproot address is required to claim the output of an Ordinal-minting transaction (i.e., a special satoshi) and Taproot addresses have certain privacy properties (on-chain obfuscation of multisig scripts, for example) that drive ongoing adoption. + +### Validation + +With the exception of the first, all three can be rudimentarily validated with the following regular expression: + +`^(bc1|3)[a-km-zA-HJ-NP-Z1-9]{25,34}$` + +For more precise validation, it is recommended to first detect the type from the prefix as mentioned above, then compute the type-specific checksum as specified in the corresponding Bitcoin Improvement Proposals linked above. + +### Decorators + +In the Bitcoin development community, certain user experience conventions have arisen that can be opted into by applications and wallets, yet are, strictly speaking, not part of the bitcoin protocol and leave no on-chain artefacts in transaction history. +By analogy to web standards, these are best designated with a matrix parameter (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. + +For example, some wallets segregate Ordinals from regular native-currency balance by receiving them in a dedicated address, to avoid an Ordinal being counted towards spendable balance, or being included unwittingly as an input to a regular (non-Ordinal) transaction. +In this case, the matrix parameter `#ordinal` should be added to an address as specifically earmarked for special treatment by the wallet. +Conversely, Ordinal-aware wallets might mark the other side of this segregation by explicitly marking an address as a `#payment` address; a client unaware of this convention could, of course, ignore or drop these and treat both as addresses capable of payments, and developers are advised not to assume Ordinals-awareness in wallet just because it uses the CAIP-10 standard or a CAIP-10-aware library. ### Backwards Compatibility @@ -33,16 +57,19 @@ CAIP-2 chainId delimited by the at sign (@) #### Legacy example -`128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6@bip122:000000000019d6689c085ae165831e93` +`35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N@bip122:000000000019d6689c085ae165831e93` ## Test Cases -``` -# Bitcoin mainnet -bip122:000000000019d6689c085ae165831e93:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +```bash +# Bitcoin mainnet, P2SH address type +bip122:000000000019d6689c085ae165831e93:35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N + +# Litecoin, SegWit +bip122:12a765e31ffd4059bada1e25190f6e98:bc1q42lja79elem0anu8q8s3h2n687re9jax556pcc -# Litecoin -bip122:12a765e31ffd4059bada1e25190f6e98:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 +## Bitcoin mainnet, Taproot address type (Ordinals Decorator) +bip122:000000000019d6689c085ae165831e93:bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e#ordinal ``` ## References @@ -51,15 +78,19 @@ bip122:12a765e31ffd4059bada1e25190f6e98:128Lkh3S7CkDTBZ8W7BbpsN3YYizJMp8p6 - [BIP21][]: Bitcoin Improvement Proposal specifying `bitcoin` URI scheme - [BIP122][]: Bitcoin Improvement Proposal specifying `blockchain` URI scheme +[base58btc]: https://datatracker.ietf.org/doc/html/draft-msporny-base58-02 [BIP13]: https://github.com/bitcoin/bips/blob/master/bip-0013.mediawiki +[BIP16]: https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki [BIP21]: https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki +[BIP44]: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki +[BIP84]: https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki [BIP122]: https://github.com/bitcoin/bips/blob/master/bip-0122.mediawiki -[CAIP-2]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-2.md +[BIP141]: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki +[BIP173]: https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki +[BIP350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki +[bitcoin whitepaper]: https://www.ussc.gov/sites/default/files/pdf/training/annual-national-training-seminar/2018/Emerging_Tech_Bitcoin_Crypto.pdf [CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md -[CAIP-19]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-19.md -[CAIP-21]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-21.md -[CAIP-22]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-22.md ## Rights -Copyright and related rights waived via CC0. +Copyright and related rights waived via CC0. \ No newline at end of file From 3b1e5a6a5f096f67b71d762640a681b144ecd21e Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 5 Jun 2024 17:37:45 +0200 Subject: [PATCH 12/21] note network-specific address prefixes and add more examples from other chains --- bip122/caip10.md | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index 31f879cd..d67b6a38 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -26,20 +26,24 @@ At time of writing, only three kinds of address are currently in wide use, with All four, in their most common ASCII base-encodings (base-58-btc, bech32, and bech32m; see below) are of a short enough length to simply include them in their entirety as the `account_address` segment of a [CAIP-10] identifier. This choice not to transform or subset addresses preserves checksum, sortability, and detectability features of all three modern address types, while also minimizing collision risk. -In order of their adoption, the four types of addresses in Bitcoin are: +In order of their adoption on Bitcoin mainnet, the four types of addresses in Bitcoin are: 1. Legacy address, aka pay-to-publickey-hash (P2PKH). These begin with `1` and are [base58btc]-encoded. Defined in the [bitcoin whitepaper][], these are exceedingly rare in contemporary practice due to higher transaction fees and limited functionality compared to the newer types described below. Legacy addresses are not derived from "extended keys" as per the subsequent [BIP44] standard, but are rather hashes of unique public keys, which makes them a weak analogue to addresses in "account-model" systems; for these reasons, they are excluded from [CAIP-10] usage. -2. Pay-to-script-hash (P2SH) address. These were specified in the early [BIP13], and swiftly became the dominant address and signature type in the early years of Bitcoin usage after becoming supported by a [soft fork][BIP16] in 2012. They are [base58btc]-encoded and always begin with `3` in ASCII form. -3. Native Segregated-Witness Address (SegWit), aka pay-to-wrapped-publickey-hash (P2WPKH) Address. The derivation of these was standardized in [BIP84], and the soft-fork supporting them at the protocol level coordinated by [BIP141]. They are encoded into ASCII according to the [`bech32`][BIP173] algorithm, and always begin with `bc1q`. At time of press, these are nearly universal due to lower transaction fees and higher security than older types. +2. Pay-to-script-hash (P2SH) address. These were specified in the early [BIP13], and swiftly became the dominant address and signature type in the early years of Bitcoin usage after becoming supported by a [soft fork][BIP16] in 2012. They are [base58btc]-encoded and always begin with `3` in ASCII form on Bitcoin mainnet. +3. Native Segregated-Witness Address (SegWit), aka pay-to-wrapped-publickey-hash (P2WPKH) Address. The derivation of these was standardized in [BIP84], and the soft-fork supporting them at the protocol level coordinated by [BIP141]. They are encoded into ASCII according to the [`bech32`][BIP173] algorithm, and always begin with `bc1q` on Bitcoin mainnet. At time of press, these are nearly universal due to lower transaction fees and higher security than older types. 4. Taproot (P2TR). They are encoded into ASCII according to the [`bech32m`][BIP350] algorithm, and always begin with `bc1q`. Not all wallets support taproot addresses at time of writing, but a Taproot address is required to claim the output of an Ordinal-minting transaction (i.e., a special satoshi) and Taproot addresses have certain privacy properties (on-chain obfuscation of multisig scripts, for example) that drive ongoing adoption. +Note that many forks and variants within the BIP122 design space use different literals to compute addresses, leading to different prefixes and checksum mechanisms on Bitcoin testnet and on other chains in the family of related networks. + ### Validation -With the exception of the first, all three can be rudimentarily validated with the following regular expression: +With the exception of the first, all three can be rudimentarily validated with the following regular expression for Bitcoin mainnet: `^(bc1|3)[a-km-zA-HJ-NP-Z1-9]{25,34}$` -For more precise validation, it is recommended to first detect the type from the prefix as mentioned above, then compute the type-specific checksum as specified in the corresponding Bitcoin Improvement Proposals linked above. +Rough validation for other networks can be achieved by updating the prefixes in the first enumeration of literals for the network-specific address-types targeted, and (if needed) updating the minimum and maximum lengths accordingly. + +For more precise validation, it is recommended to first detect the type from the prefix as mentioned above, then compute the type-specific checksum as specified in the corresponding Bitcoin Improvement Proposals linked above (taking into account different literals for most networks). ### Decorators @@ -47,8 +51,9 @@ In the Bitcoin development community, certain user experience conventions have a By analogy to web standards, these are best designated with a matrix parameter (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. For example, some wallets segregate Ordinals from regular native-currency balance by receiving them in a dedicated address, to avoid an Ordinal being counted towards spendable balance, or being included unwittingly as an input to a regular (non-Ordinal) transaction. -In this case, the matrix parameter `#ordinal` should be added to an address as specifically earmarked for special treatment by the wallet. -Conversely, Ordinal-aware wallets might mark the other side of this segregation by explicitly marking an address as a `#payment` address; a client unaware of this convention could, of course, ignore or drop these and treat both as addresses capable of payments, and developers are advised not to assume Ordinals-awareness in wallet just because it uses the CAIP-10 standard or a CAIP-10-aware library. +In this case, the matrix parameter `#ordinal` could be added to communicate to a counterparty that the preceding address has been specifically earmarked for receiving only Ordinal-marked Satoshis and not for general use. +Conversely, Ordinal-aware wallets might mark the other side of this segregation by explicitly marking an address as a `#payment` address. +A client unaware of this convention could, of course, ignore or drop these matrix parameters and treat both as addresses capable of payments, and developers are advised not to assume Ordinals-awareness in a given wallet just because it uses the [CAIP-10] standard or a CAIP-10-aware library. ### Backwards Compatibility @@ -62,14 +67,24 @@ CAIP-2 chainId delimited by the at sign (@) ## Test Cases ```bash -# Bitcoin mainnet, P2SH address type +# Bitcoin mainnet, P2SH address bip122:000000000019d6689c085ae165831e93:35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N -# Litecoin, SegWit -bip122:12a765e31ffd4059bada1e25190f6e98:bc1q42lja79elem0anu8q8s3h2n687re9jax556pcc +# Bitcoin testnet, Segwit address +bip122:000000000933ea01ad0ee984209779ba:tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7 -## Bitcoin mainnet, Taproot address type (Ordinals Decorator) +# Bitcoin mainnet, Taproot address type (Ordinals Decorator) bip122:000000000019d6689c085ae165831e93:bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e#ordinal + +# Dogecoin, Legacy address +bip122:1a91e3dace36e2be3bf030a65679fe82:AC8Q9Z4i4sXcbW7TV1jqrjG1JEWMdLyzcy + +# Dogecoin, Native Segwit address +bip122:1a91e3dace36e2be3bf030a65679fe82:DLCDJhnh6aGotar6b182jpzbNEyXb3C361 + +# Litecoin, Native SegWit +bip122:12a765e31ffd4059bada1e25190f6e98:ltc1q8c6fshw2dlwun7ekn9qwf37cu2rn755u9ym7p0 + ``` ## References From 2d594430dde822158bda154b7cf2963c83d6ba23 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 5 Jun 2024 19:36:43 +0200 Subject: [PATCH 13/21] add better examples generated by RareData --- bip122/caip10.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index d67b6a38..a95c7d54 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -53,7 +53,7 @@ By analogy to web standards, these are best designated with a matrix parameter ( For example, some wallets segregate Ordinals from regular native-currency balance by receiving them in a dedicated address, to avoid an Ordinal being counted towards spendable balance, or being included unwittingly as an input to a regular (non-Ordinal) transaction. In this case, the matrix parameter `#ordinal` could be added to communicate to a counterparty that the preceding address has been specifically earmarked for receiving only Ordinal-marked Satoshis and not for general use. Conversely, Ordinal-aware wallets might mark the other side of this segregation by explicitly marking an address as a `#payment` address. -A client unaware of this convention could, of course, ignore or drop these matrix parameters and treat both as addresses capable of payments, and developers are advised not to assume Ordinals-awareness in a given wallet just because it uses the [CAIP-10] standard or a CAIP-10-aware library. +A client unaware of this convention could, of course, ignore or drop these matrix parameters and treat both as addresses capable of payments, and developers are advised not to assume Ordinals-awareness in a given wallet just because it uses the CAIP-10 standard or a CAIP-10-aware library. ### Backwards Compatibility @@ -70,21 +70,27 @@ CAIP-2 chainId delimited by the at sign (@) # Bitcoin mainnet, P2SH address bip122:000000000019d6689c085ae165831e93:35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N -# Bitcoin testnet, Segwit address +# Bitcoin mainnet, Native SegWit address (P2WPKH) +bip122:000000000019d6689c085ae165831e93:bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk + +# Bitcoin testnet, Native SegWit address (P2WPKH) bip122:000000000933ea01ad0ee984209779ba:tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7 -# Bitcoin mainnet, Taproot address type (Ordinals Decorator) +# Bitcoin mainnet, Taproot address with Ordinals decorator bip122:000000000019d6689c085ae165831e93:bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e#ordinal -# Dogecoin, Legacy address -bip122:1a91e3dace36e2be3bf030a65679fe82:AC8Q9Z4i4sXcbW7TV1jqrjG1JEWMdLyzcy +# Dogecoin mainnet, P2PKH address +bip122:1a91e3dace36e2be3bf030a65679fe82:DBcZSePDaMMduBMLymWHXhkE5ArFEvkagU -# Dogecoin, Native Segwit address -bip122:1a91e3dace36e2be3bf030a65679fe82:DLCDJhnh6aGotar6b182jpzbNEyXb3C361 +# Dogecoin testnet, P2PKH address +bip122:bb0a78264637406b6360aad926284d54:nXprPppuYCyxrrW6eVh4koUz8kTFrAvGo8 -# Litecoin, Native SegWit +# Litecoin mainnet, Native SegWit address (P2WPKH) bip122:12a765e31ffd4059bada1e25190f6e98:ltc1q8c6fshw2dlwun7ekn9qwf37cu2rn755u9ym7p0 +# Litecoin testnet, Native SegWit address (P2WPKH) +bip122:4966625a4b2851d9fdee139e56211a0d:tltc1qlustmw64lgd744h45n0t07wxnxw8pmv2sv07r9 + ``` ## References From e12f95ba3462b785507755998a0651f616f294b2 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 5 Jun 2024 20:28:01 +0200 Subject: [PATCH 14/21] reorder examples generated by RareData --- bip122/caip10.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index a95c7d54..e95b77d4 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -1,7 +1,7 @@ --- namespace-identifier: bip122-caip10 title: BIP122 Namespace - Addresses -author: Simon Warta (@webmaster128), ligi , Pedro Gomes (@pedrouid), bumblefudge (@bumblefudge) +author: Simon Warta (@webmaster128), ligi , Pedro Gomes (@pedrouid), bumblefudge (@bumblefudge), RareData (@RareData) discussions-to: https://github.com/ChainAgnostic/namespaces/pulls/3 status: Draft type: Standard @@ -73,12 +73,12 @@ bip122:000000000019d6689c085ae165831e93:35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N # Bitcoin mainnet, Native SegWit address (P2WPKH) bip122:000000000019d6689c085ae165831e93:bc1qwz2lhc40s8ty3l5jg3plpve3y3l82x9l42q7fk -# Bitcoin testnet, Native SegWit address (P2WPKH) -bip122:000000000933ea01ad0ee984209779ba:tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7 - # Bitcoin mainnet, Taproot address with Ordinals decorator bip122:000000000019d6689c085ae165831e93:bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e#ordinal +# Bitcoin testnet, Native SegWit address (P2WPKH) +bip122:000000000933ea01ad0ee984209779ba:tb1qrp33g0q5c5txsp9arysrx4k6zdkfs4nce4xj0gdcccefvpysxf3q0sl5k7 + # Dogecoin mainnet, P2PKH address bip122:1a91e3dace36e2be3bf030a65679fe82:DBcZSePDaMMduBMLymWHXhkE5ArFEvkagU From fac4c2c6fe194342ef282d00a875961d31a2dfb4 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Thu, 6 Jun 2024 08:55:23 +0200 Subject: [PATCH 15/21] Fine-tune the network-specificity language --- bip122/caip10.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index e95b77d4..06bac308 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -30,7 +30,7 @@ In order of their adoption on Bitcoin mainnet, the four types of addresses in Bi 1. Legacy address, aka pay-to-publickey-hash (P2PKH). These begin with `1` and are [base58btc]-encoded. Defined in the [bitcoin whitepaper][], these are exceedingly rare in contemporary practice due to higher transaction fees and limited functionality compared to the newer types described below. Legacy addresses are not derived from "extended keys" as per the subsequent [BIP44] standard, but are rather hashes of unique public keys, which makes them a weak analogue to addresses in "account-model" systems; for these reasons, they are excluded from [CAIP-10] usage. 2. Pay-to-script-hash (P2SH) address. These were specified in the early [BIP13], and swiftly became the dominant address and signature type in the early years of Bitcoin usage after becoming supported by a [soft fork][BIP16] in 2012. They are [base58btc]-encoded and always begin with `3` in ASCII form on Bitcoin mainnet. -3. Native Segregated-Witness Address (SegWit), aka pay-to-wrapped-publickey-hash (P2WPKH) Address. The derivation of these was standardized in [BIP84], and the soft-fork supporting them at the protocol level coordinated by [BIP141]. They are encoded into ASCII according to the [`bech32`][BIP173] algorithm, and always begin with `bc1q` on Bitcoin mainnet. At time of press, these are nearly universal due to lower transaction fees and higher security than older types. +3. Native Segregated-Witness Address (SegWit), aka pay-to-wrapped-publickey-hash (P2WPKH) Address. The derivation of these was standardized in [BIP84], and the soft-fork supporting them at the protocol level on Bitcoin mainnet was coordinated by [BIP141]. They are encoded into ASCII according to the [`bech32`][BIP173] algorithm, and always begin with `bc1q` on Bitcoin mainnet. At time of press, these are nearly universal due to lower transaction fees and higher security than older types. 4. Taproot (P2TR). They are encoded into ASCII according to the [`bech32m`][BIP350] algorithm, and always begin with `bc1q`. Not all wallets support taproot addresses at time of writing, but a Taproot address is required to claim the output of an Ordinal-minting transaction (i.e., a special satoshi) and Taproot addresses have certain privacy properties (on-chain obfuscation of multisig scripts, for example) that drive ongoing adoption. Note that many forks and variants within the BIP122 design space use different literals to compute addresses, leading to different prefixes and checksum mechanisms on Bitcoin testnet and on other chains in the family of related networks. @@ -43,7 +43,7 @@ With the exception of the first, all three can be rudimentarily validated with t Rough validation for other networks can be achieved by updating the prefixes in the first enumeration of literals for the network-specific address-types targeted, and (if needed) updating the minimum and maximum lengths accordingly. -For more precise validation, it is recommended to first detect the type from the prefix as mentioned above, then compute the type-specific checksum as specified in the corresponding Bitcoin Improvement Proposals linked above (taking into account different literals for most networks). +For more precise validation, it is recommended to first detect the type from the prefix as mentioned above, then compute the type-specific checksum as specified in the corresponding Bitcoin Improvement Proposals linked above (taking into account that networks other than Bitcoin mainnet use different literals, affecting not just the prefixes but also the checksum algorithms). ### Decorators @@ -114,4 +114,4 @@ bip122:4966625a4b2851d9fdee139e56211a0d:tltc1qlustmw64lgd744h45n0t07wxnxw8pmv2sv ## Rights -Copyright and related rights waived via CC0. \ No newline at end of file +Copyright and related rights waived via CC0. From 000941bc7b9704557f7cc2283a56bc5abc9eaff1 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Wed, 12 Jun 2024 17:58:53 +0200 Subject: [PATCH 16/21] address obstropolous nits --- solana/caip25.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/solana/caip25.md b/solana/caip25.md index cc053b43..bf0c52e7 100644 --- a/solana/caip25.md +++ b/solana/caip25.md @@ -1,7 +1,7 @@ --- namespace-identifier: solana-caip25 title: Solana Namespace - JSON-RPC Provider Authorization -author: Jon Wong (@jnwng), Glitch (@glitch-txs) bumblefudge (@bumblefudge) +author: Jon Wong (@jnwng), Glitch (@glitch-txs), bumblefudge (@bumblefudge) discussions-to: https://github.com/anza-xyz/wallet-adapter/issues/807 status: Draft type: Standard @@ -19,13 +19,13 @@ _For context, see the [CAIP-25][] specification._ 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 +## 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. -## Multi-Chain Considerations +## Multichain Considerations -Developers addressing multi-chain 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. +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. From f1b5354fcf08c1c53fdee5ecd0cd896528d4895a Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Fri, 14 Jun 2024 23:25:20 +0200 Subject: [PATCH 17/21] html typo --- _includes/caiptable.html | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/_includes/caiptable.html b/_includes/caiptable.html index e1a27cb1..36b55fc4 100644 --- a/_includes/caiptable.html +++ b/_includes/caiptable.html @@ -24,13 +24,14 @@ Namespace - CAIP profiles + CAIP profiles Informative Context 2 10 19 + 25 122 @@ -71,6 +72,11 @@ X {% endif %} + + {% if namespace contains "caip25.md" %} + X + {% endif %} + {% if namespace contains "caip122.md" %} X From ac23979c1614d36118444be70a8279950c3cdfb5 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Mon, 17 Jun 2024 20:13:35 +0200 Subject: [PATCH 18/21] apply silverpill's terminology fix --- bip122/caip10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index 06bac308..a560ec74 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -48,7 +48,7 @@ For more precise validation, it is recommended to first detect the type from the ### Decorators In the Bitcoin development community, certain user experience conventions have arisen that can be opted into by applications and wallets, yet are, strictly speaking, not part of the bitcoin protocol and leave no on-chain artefacts in transaction history. -By analogy to web standards, these are best designated with a matrix parameter (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. +By analogy to web standards, these are best designated with a fragment identifier (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. For example, some wallets segregate Ordinals from regular native-currency balance by receiving them in a dedicated address, to avoid an Ordinal being counted towards spendable balance, or being included unwittingly as an input to a regular (non-Ordinal) transaction. In this case, the matrix parameter `#ordinal` could be added to communicate to a counterparty that the preceding address has been specifically earmarked for receiving only Ordinal-marked Satoshis and not for general use. From d2a098524ea6a5a4828c82b3c471bd611d8af613 Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Mon, 17 Jun 2024 20:16:55 +0200 Subject: [PATCH 19/21] Update silverpill's terminological fix with RFC normref --- bip122/caip10.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/bip122/caip10.md b/bip122/caip10.md index a560ec74..a60b8bc9 100644 --- a/bip122/caip10.md +++ b/bip122/caip10.md @@ -48,7 +48,7 @@ For more precise validation, it is recommended to first detect the type from the ### Decorators In the Bitcoin development community, certain user experience conventions have arisen that can be opted into by applications and wallets, yet are, strictly speaking, not part of the bitcoin protocol and leave no on-chain artefacts in transaction history. -By analogy to web standards, these are best designated with a fragment identifier (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. +By analogy to web standards, these are best designated with "fragment identifier" of the sort specified in the [URL standard][RFC-1738] (i.e., a `#parameter` suffix on the URI), which might be meaningful or useful to clients but are not native to the underlying URL protocol and are traditionally omitted when sent over the wire for resolution. For example, some wallets segregate Ordinals from regular native-currency balance by receiving them in a dedicated address, to avoid an Ordinal being counted towards spendable balance, or being included unwittingly as an input to a regular (non-Ordinal) transaction. In this case, the matrix parameter `#ordinal` could be added to communicate to a counterparty that the preceding address has been specifically earmarked for receiving only Ordinal-marked Satoshis and not for general use. @@ -111,6 +111,7 @@ bip122:4966625a4b2851d9fdee139e56211a0d:tltc1qlustmw64lgd744h45n0t07wxnxw8pmv2sv [BIP350]: https://github.com/bitcoin/bips/blob/master/bip-0350.mediawiki [bitcoin whitepaper]: https://www.ussc.gov/sites/default/files/pdf/training/annual-national-training-seminar/2018/Emerging_Tech_Bitcoin_Crypto.pdf [CAIP-10]: https://github.com/ChainAgnostic/CAIPs/blob/master/CAIPs/caip-10.md +[RFC-1738]: https://www.rfc-editor.org/rfc/rfc1738 ## Rights From 58ee5b55904c1d8837f68b1c7f5043ec3c535a63 Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Tue, 16 Jul 2024 11:34:19 +0200 Subject: [PATCH 20/21] initial namespace outline - needs testcases and additional considerations --- wallet/README.md | 24 +++++++++++++++++++++ wallet/caip2.md | 54 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 78 insertions(+) create mode 100644 wallet/README.md create mode 100644 wallet/caip2.md diff --git a/wallet/README.md b/wallet/README.md new file mode 100644 index 00000000..5919e33a --- /dev/null +++ b/wallet/README.md @@ -0,0 +1,24 @@ +--- +namespace-identifier: wallet +title: Wallet Namespace +author: ["Vandan Parikh (@vandan)", "bumblefudge (@bumblefudge)"] +status: Draft +type: Informational +created: 2024-07-16 +--- + +## Rationale + +The handling of direct communications channels between cryptographic user-agents (i.e., wallets) and applications vary widely across cryptographic systems. +Rather than being a true namespace defined outside of CASA, this "meta-namespace" informationally groups together the wallet sub-namespaces of other namespaces specified at CASA. +This "meta-namespace" is intended to facilitate an explicit segregation of connection mechanics, methods, and notifications for these channels from the very different mechanics, methods, and notifications used for application <> node purposes in each namespace. + +## Governance + +This namespace is purely formal and governed in CASA, and as such should only be used as a kind of "alias" or "passthrough" to each other namespace's application<>wallet mechanisms, governed accordingly in each namespace's native governance. +Contributors are discouraged from making any claims or specifying any behaviors not already specified in the referenced namespaces; +furthermore, contributers are encouraged to provide normative references when adding to the profiles for a given CAIP. + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/wallet/caip2.md b/wallet/caip2.md new file mode 100644 index 00000000..9b5f95ee --- /dev/null +++ b/wallet/caip2.md @@ -0,0 +1,54 @@ +--- +namespace-identifier: wallet-caip2 +title: Wallet Namespace - RPC namespaces +author: ["Vandan Parikh (@vandan)", "bumblefudge (@bumblefudge)"] +discussions-to: +status: Draft +type: +created: +requires (*optional): <["CAIP-X", "CAIP-Y"]> +replaces (*optional): +--- + +*For context, see the [CAIP-2][] specification.* + +Each `chainId` reference in the `wallet:` namespace is defined as the namespace identifier for another namespace. + +This combination (i.e. `wallet:eip155`) refers not to an `eip155` network but specifically to an application<>wallet connection defined according to the wallet and RPC conventions of the `eip155` namespace. + +## Rationale + +Implementers of [CAIP-25][] and other multichain application<>wallet connections have long struggled with how to map offchain or direct-to-wallet methods, notifications, and metadata to one another across namespaces, and how to safely and ergonomically segregate them from node-dependent/network-dependent functions. +For this reason, an abstraction (in the form of a "meta-namespace" routing to the other namespaces) is here proposed. + +## Semantics + +`wallet:{namespace}` is functionally an alias for `{namespace}:wallet`, where `:wallet` refers to a special-case of a wallet connection, not a proper network (as required by the CAIP-2 profile for `eip155`). + +## Syntax + +The only valid values for a `chainId` reference in the `wallet` namespace are the namespace identifiers of other namespaces. +For a current list of these, see [namespaces][]. + +### Resolution Mechanics + +All resolution is defined in the namespace referred to, and ideally specified in its `/README.md` file here. +As resolution depends entirely on transport and connection mechanism, no uniform resolution mechanics should be assumed. + +## Test Cases + +< TODO > + +## Additional Considerations + +< TODO > + +## References + +[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 +[CAIP-25]: https://chainagnostic.org/CAIPs/caip-25 +[namespaces]: https://namespaces.chainagnostic.org/ + +## Copyright + +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/) From 30c25631de081bce4168113e502760a8fd8e56cf Mon Sep 17 00:00:00 2001 From: Bumblefudge Date: Tue, 16 Jul 2024 11:36:31 +0200 Subject: [PATCH 21/21] Revert "initial namespace outline - needs testcases and additional considerations" This reverts commit 58ee5b55904c1d8837f68b1c7f5043ec3c535a63. --- wallet/README.md | 24 --------------------- wallet/caip2.md | 54 ------------------------------------------------ 2 files changed, 78 deletions(-) delete mode 100644 wallet/README.md delete mode 100644 wallet/caip2.md diff --git a/wallet/README.md b/wallet/README.md deleted file mode 100644 index 5919e33a..00000000 --- a/wallet/README.md +++ /dev/null @@ -1,24 +0,0 @@ ---- -namespace-identifier: wallet -title: Wallet Namespace -author: ["Vandan Parikh (@vandan)", "bumblefudge (@bumblefudge)"] -status: Draft -type: Informational -created: 2024-07-16 ---- - -## Rationale - -The handling of direct communications channels between cryptographic user-agents (i.e., wallets) and applications vary widely across cryptographic systems. -Rather than being a true namespace defined outside of CASA, this "meta-namespace" informationally groups together the wallet sub-namespaces of other namespaces specified at CASA. -This "meta-namespace" is intended to facilitate an explicit segregation of connection mechanics, methods, and notifications for these channels from the very different mechanics, methods, and notifications used for application <> node purposes in each namespace. - -## Governance - -This namespace is purely formal and governed in CASA, and as such should only be used as a kind of "alias" or "passthrough" to each other namespace's application<>wallet mechanisms, governed accordingly in each namespace's native governance. -Contributors are discouraged from making any claims or specifying any behaviors not already specified in the referenced namespaces; -furthermore, contributers are encouraged to provide normative references when adding to the profiles for a given CAIP. - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). diff --git a/wallet/caip2.md b/wallet/caip2.md deleted file mode 100644 index 9b5f95ee..00000000 --- a/wallet/caip2.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -namespace-identifier: wallet-caip2 -title: Wallet Namespace - RPC namespaces -author: ["Vandan Parikh (@vandan)", "bumblefudge (@bumblefudge)"] -discussions-to: -status: Draft -type: -created: -requires (*optional): <["CAIP-X", "CAIP-Y"]> -replaces (*optional): ---- - -*For context, see the [CAIP-2][] specification.* - -Each `chainId` reference in the `wallet:` namespace is defined as the namespace identifier for another namespace. - -This combination (i.e. `wallet:eip155`) refers not to an `eip155` network but specifically to an application<>wallet connection defined according to the wallet and RPC conventions of the `eip155` namespace. - -## Rationale - -Implementers of [CAIP-25][] and other multichain application<>wallet connections have long struggled with how to map offchain or direct-to-wallet methods, notifications, and metadata to one another across namespaces, and how to safely and ergonomically segregate them from node-dependent/network-dependent functions. -For this reason, an abstraction (in the form of a "meta-namespace" routing to the other namespaces) is here proposed. - -## Semantics - -`wallet:{namespace}` is functionally an alias for `{namespace}:wallet`, where `:wallet` refers to a special-case of a wallet connection, not a proper network (as required by the CAIP-2 profile for `eip155`). - -## Syntax - -The only valid values for a `chainId` reference in the `wallet` namespace are the namespace identifiers of other namespaces. -For a current list of these, see [namespaces][]. - -### Resolution Mechanics - -All resolution is defined in the namespace referred to, and ideally specified in its `/README.md` file here. -As resolution depends entirely on transport and connection mechanism, no uniform resolution mechanics should be assumed. - -## Test Cases - -< TODO > - -## Additional Considerations - -< TODO > - -## References - -[CAIP-2]: https://chainagnostic.org/CAIPs/caip-2 -[CAIP-25]: https://chainagnostic.org/CAIPs/caip-25 -[namespaces]: https://namespaces.chainagnostic.org/ - -## Copyright - -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/)