diff --git a/CIP-0019/CIP-0019-cardano-addresses.abnf b/CIP-0019/CIP-0019-cardano-addresses.abnf index 9cd6aebd24..7683e026ba 100644 --- a/CIP-0019/CIP-0019-cardano-addresses.abnf +++ b/CIP-0019/CIP-0019-cardano-addresses.abnf @@ -1,11 +1,11 @@ -ADDRESS = %b0000 | NETWORK-TAG | KEY-HASH | KEY-HASH ; type 00, Base Shelley address - \ %b0001 | NETWORK-TAG | SCRIPT-HASH | KEY-HASH ; type 01, Base Shelley address - \ %b0010 | NETWORK-TAG | KEY-HASH | SCRIPT-HASH ; type 02, Base Shelley address - \ %b0011 | NETWORK-TAG | SCRIPT-HASH | SCRIPT-HASH ; type 03, Base Shelley address +ADDRESS = %b0000 | PAYMENT-ADDRESS-TAG | KEY-HASH | KEY-HASH ; type 00, Base Shelley address + \ %b0001 | PAYMENT-ADDRESS-TAG | SCRIPT-HASH | KEY-HASH ; type 01, Base Shelley address + \ %b0010 | PAYMENT-ADDRESS-TAG | KEY-HASH | SCRIPT-HASH ; type 02, Base Shelley address + \ %b0011 | PAYMENT-ADDRESS-TAG | SCRIPT-HASH | SCRIPT-HASH ; type 03, Base Shelley address \ %b0100 | NETWORK-TAG | KEY-HASH | POINTER ; type 04, Pointer Shelley address deprecated in Conway \ %b0101 | NETWORK-TAG | SCRIPT-HASH | POINTER ; type 05, Pointer Shelley address deprecated in Conway - \ %b0110 | NETWORK-TAG | KEY-HASH ; type 06, Payment Shelley address - \ %b0111 | NETWORK-TAG | SCRIPT-HASH ; type 07, Payment Shelley address + \ %b0110 | PAYMENT-ADDRESS-TAG | KEY-HASH ; type 06, Payment Shelley address + \ %b0111 | PAYMENT-ADDRESS-TAG | SCRIPT-HASH ; type 07, Payment Shelley address \ %b1000 | BYRON-PAYLOAD ; type 08, Byron / Bootstrap address \ %b1110 | NETWORK-TAG | KEY-HASH ; type 14, Stake Shelley address \ %b1111 | NETWORK-TAG | SCRIPT-HASH ; type 15, Stake Shelley address @@ -13,6 +13,15 @@ ADDRESS = %b0000 | NETWORK-TAG | KEY-HASH | KEY-HASH ; type 00, Base Sh NETWORK-TAG = %b0000 ; Testnet \ %b0001 ; Mainnet +; Proposed CIP-160 extension: PROTECTED-NETWORK-TAG is valid only after +; the agreed activation. It applies to base/enterprise payment families above; +; pointer, reward/account and Byron addresses do not gain a protection flag. +PAYMENT-ADDRESS-TAG = NETWORK-TAG + \ PROTECTED-NETWORK-TAG + +PROTECTED-NETWORK-TAG = %b1000 ; Protected testnet (network bit 0) + \ %b1001 ; Protected mainnet (network bit 1) + POINTER = VARIABLE-LENGTH-UINT ; slot number | VARIABLE-LENGTH-UINT ; transaction index | VARIABLE-LENGTH-UINT ; certificate index diff --git a/CIP-0019/README.md b/CIP-0019/README.md index cc39ad4883..cfc699fcf7 100644 --- a/CIP-0019/README.md +++ b/CIP-0019/README.md @@ -50,7 +50,7 @@ Examples of different addresses encoded in different eras: In Cardano, the sequence of bytes (after decoding with Bech32 or Base58) that represents an address comprises two parts, a one-byte **header** and a **payload** of several bytes. Depending on the header, the interpretation and length of the payload varies. -In the header-byte, bits [7;4] indicate the type of addresses being used; we'll call these four bits the **header type**. The remaining four bits [3;0] are either unused or refer to what we'll call the **network tag**. There are currently 11 types of addresses in Cardano which we'll divide into three categories: [Shelley addresses], [stake addresses], and [Byron addresses]. +In the header-byte, bits [7;4] indicate the type of addresses being used; we'll call these four bits the **header type**. In the currently activated format, the remaining four bits [3;0] are either unused or refer to what we'll call the **network tag**. The proposed CIP-160 payment-address extension below reserves bit 3 for protection in specified families; it does not change the activated network definitions. There are currently 11 types of addresses in Cardano which we'll divide into three categories: [Shelley addresses], [stake addresses], and [Byron addresses]. ``` 1 byte variable length @@ -77,6 +77,46 @@ Network Tag (`. . . . n n n n`) | Semantic `....0001` | Mainnet +#### Proposed protected payment-address extension + +[CIP-160](../CIP-0160/README.md) proposes opt-in creation authorization for +Shelley payment addresses. This section specifies the candidate byte format; +it is not an assertion of mainnet activation or Ledger/Plutus acceptance. +Acceptance and activation of this extension remain subject to CIP-160's +criteria and an agreed future-era protocol version. + +For base types 0–3 and enterprise types 6–7, bit 3 (`0x08`) of the header is +the proposed protection flag. Bits 1–2 remain reserved and zero; bit 0 retains +the network meaning below. Existing high-nibble types, credential payloads and +lengths are unchanged. + +| Payment low nibble (`p 0 0 n`) | Protection | Network | +| --- | --- | --- | +| `0000` | Unprotected | Testnet(s) | +| `0001` | Unprotected | Mainnet | +| `1000` | Protected | Testnet(s) | +| `1001` | Protected | Mainnet | + +`1000` and `1001` in these families do not introduce network types 8 and 9. +Network-aware code interprets protection separately from network identity. +Other low-nibble values remain reserved. Header examples are protected base +key/key `0x08`/`0x09` and protected enterprise script `0x78`/`0x79` on +testnet/mainnet, respectively. + +Pointer types 4–5, Byron type 8, stake types 14–15, account addresses and other +families do not support protection. Their formats/network interpretation are +unchanged; setting `0x08` does not make them protected payment addresses. +Protected pointers and malformed protected payloads are invalid. A protected +address uses the existing `addr` or `addr_test` prefix and is distinct from an +unprotected address carrying the same credentials. Unprotected examples below +remain unchanged. The [proposed vectors](../CIP-0160/test-vectors/protected-addresses.json) +derive protected bytes from those same examples. + +The annex's `PAYMENT-ADDRESS-TAG` extension applies only after this feature's +activation. Historical-era parsers and transactions retain their existing +acceptance domain; recognizing the candidate raw format does not establish +transaction eligibility. + #### Shelley Addresses There are currently 8 types of Shelley addresses summarized in the table below: diff --git a/CIP-0160/README.md b/CIP-0160/README.md index a55111abd4..c31cbd4ebd 100644 --- a/CIP-0160/README.md +++ b/CIP-0160/README.md @@ -14,7 +14,7 @@ License: CC-BY-4.0 ## Abstract -This CIP proposes the introduction of a new Address type, `ProtectedAddress`, and a corresponding `Receiving` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem. +This CIP proposes a protected form of payment address and a corresponding `Receiving` script purpose. This enhancement allows a smart contract to validate not only UTxO spends from its address, but also UTxO creations to its address. The lack of such a mechanism today forces developers to implement complex workarounds involving authentication tokens, threaded NFTs, and registry UTxOs to guard against unauthorized or malformed deposits. This CIP aims to provide a native mechanism to guard script addresses against incoming UTxOs, thereby improving protocol safety, reducing engineering overhead, and eliminating a wide class of vulnerabilities in the Cardano smart contract ecosystem. ## Motivation: Why is this CIP necessary? @@ -28,67 +28,206 @@ In Cardano’s current eUTxO model, smart contracts can enforce logic only when These workarounds add significant complexity, on-chain cost, and surface area for bugs. A native mechanism to guard UTxO creations at a script address would eliminate the need for most of these patterns. ## Specification -We propose: -1. **A new address type**: - - ```haskell - data Address = - Address - { addressCredential :: Credential - -- ^ the payment credential - , addressStakingCredential :: Maybe StakingCredential - -- ^ the staking credential - } - ProtectedAddress -- new - { address :: Credential - , addressStakingCredential :: Maybe StakingCredential - } - ``` - -2. **A new `ScriptPurpose`:** - - ```haskell - data ScriptPurpose = - Spending TxOutRef - | Minting CurrencySymbol - | Certifying DCert - | Rewarding StakingCredential - | Voting Vote - | Proposing Proposal - | Receiving ScriptHash -- NEW: only output(s) to script - ``` - -Normal addresses and protected addresses are differentiated by the introduction of an `isProtected` bit in the address header bytes, if the bit is set then the address is a protected address, otherwise it is unprotected. - -### Receiving validation rule - -Any output to a protected address requires the witness for the payment credential of that address to be provided in the transaction. For outputs to protected addresses with public key payment credentials this means the transaction must be signed -by the owner of that public key. For outputs to protected addresses with plutus script payment credentials this means the associated plutus script must be executed in phase-2 validation. - -During phase-2 script validation, for each transaction output to a `ProtectedAddress`, with a script payment credential the associated script must be executed using the script purpose: - -- `Receiving` is used when the transaction includes an output to a `ProtectedAddress` where the payment credential is a script. +The following is the proposed protocol contract. Initial Dijkstra with a +receiving-aware Plutus V4 is the preferred target, subject to Ledger, Plutus and +release coordination. Publication of this amendment does not establish feature +admission, an activation protocol version, or that the V4 format remains open. +If either format is frozen, use an agreed successor era/language rather than +change an already deployed language schema. + +### Protected payment addresses + +Protection is an opt-in property of a Shelley payment address. Payment and +staking credential types do not change. The protected and unprotected forms +with identical credentials are different addresses. + +Set header bit 3 (`0x08`) for a protected address. Only base address types +0–3 and enterprise types 6–7 support protection. The high-nibble type, credential +payloads and lengths are unchanged. In these payment addresses, bit 0 still +identifies testnet (`0`) or mainnet (`1`); bits 1–2 remain reserved and zero. +Thus protected testnet/mainnet low nibbles are `1000`/`1001`, respectively. +They do not identify new networks 8 or 9. See the proposed +[CIP-19 amendment](../CIP-0019/README.md#proposed-protected-payment-address-extension). + +Protected pointer addresses (types 4–5), Byron addresses, reward/account +addresses, other families, reserved bits, malformed payloads and incorrect +lengths are invalid. Protection retains the `addr`/`addr_test` Bech32 prefixes. +Unprotected address bytes and historical decoding rules remain unchanged. +Before activation, transaction decoding/validation rejects protected outputs. +State restoration preserves previously validated protected addresses without +repeating creation authorization; production initial-fund injection must not +create protected outputs without that authorization and is rejected. + +The proposed receiving-aware V4 address shape uses that language's existing +account-based staking representation: + +```haskell +data Address + = Address Credential (Maybe AccountId) + | AddressProtected Credential (Maybe AccountId) +``` -If any `Receiving` script **fails** during evaluation, the **entire transaction is invalid** and is rejected during phase-2 validation. +This replaces the candidate V4 Address's list Data schema with an indexed sum, +proposing ordinary constructor index `0` and protected index `1`. It is a +language-format change requiring explicit Plutus agreement before activation. +It must not be applied to a frozen or deployed V4 schema. Existing V1–V3 +address schemas are unchanged. + +### Receiving domain and redeemer indexes + +The per-output model below is this amendment's proposed implementation +reconciliation of the [existing per-output validation rule](https://github.com/cardano-foundation/CIPs/blob/b4a593c960f2751fef2ddc8df28bec7b22c68eb5/CIP-0160/README.md#receiving-validation-rule) +and [the Ledger WG suggestion to resolve a TxOut into the purpose](https://github.com/cardano-foundation/CIPs/pull/1063#issuecomment-3222306948). +Those sources support individual output execution and visibility. The precise +raw-index mapping and Data fields proposed here still require upstream review; +the cited discussion does not establish approval of those formats or activation. + +For each transaction body, including each nested body, enumerate all ordinary +outputs in authored order before selecting protected script outputs: + +```text +receivingScriptTargets(body) = + [(originalIndex, paymentScriptHash(output.address)) + | (originalIndex, output) <- enumerate body.ordinaryOutputs, + output.address.isProtected, + output.address.paymentCredential is a script] +receivingKeyHashes(body) = unique + [paymentKeyHash(output.address) + | output <- body.ordinaryOutputs, output.address.isProtected] +``` -### CDDL Extension +The index is the raw original zero-based position in that body's ordinary output +sequence. It is not a filtered-target rank or a sorted-script-hash rank. Ordinary, +key and native outputs retain their sequence positions; filtering does not +compress indexes. Script witness contents or language cannot renumber outputs. +An unprotected output creates no Receiving obligation, even when its payment +hash matches a protected output. No target list is added to transaction bytes. + +Every protected Plutus output requires a separate Receiving execution, redeemer +and execution budget, including outputs sharing the same script hash, different +staking credentials, or byte-identical contents. Success for one output does not +authorize another output. Native scripts use existing phase-1 authorization and +require no Plutus Receiving redeemer. Script/key witness availability may +normally deduplicate hashes; execution identity is the individual output. + +Ledger purpose item and redeemer-pointer views carry the original `Word32` +output index. Forward/inverse lookup verifies that index resolves to a protected +script output in the same body; the resolved item/pointer pair retains that +index in both fields. Never infer an index from the first equal TxOut: identical +duplicates remain distinct occurrences. Out-of-range, ordinary/key-output and +native-only redeemers are invalid under existing witness/exact-redeemer checks. + +The same script hash and index in a parent and child body have independent +purposes, redeemers and budgets. Each Receiving context exposes the specific +output resolved at its index. `txInfoOutputs` retains authored order. + +### Creation witnesses + +Every ordinary protected output requires its payment credential's authorization +for its own transaction body: + +- A payment key requires its existing signature over that body's hash. An + existing matching signature can satisfy it. A signature for a different + staking credential does not authorize the payment key; the same underlying + key may satisfy existing payment and staking witness requirements. +- A native script requires its script and successful existing phase-1 checks, + using that body's native-script environment. It has no Receiving redeemer. +- A Plutus script requires its script, a Receiving redeemer and successful + phase-2 evaluation in the receiving-aware language. + +Script witnesses and existing selected-input/reference-input reference scripts +are resolved under the era's ordinary sharing rules, including batch sharing +where provided. A script carried only by a newly created output cannot witness +that output's creation. A shared script may serve several purposes; each Plutus +purpose retains its own redeemer and execution budget. + +Receiving adds no implicit datum argument and no blanket phase-1 requirement +for a new output datum-hash preimage. Validators can inspect inline datums or +preimages supplied through existing permitted datum witnesses. Existing datum, +missing/extraneous script and exact-redeemer checks continue to apply. + +Protection governs output creation. Spending a protected UTxO still requires +the usual key/native/Plutus spending authorization; reference inputs do not +trigger Receiving. Network and stake accounting use the original credentials. +Deposits/withdrawals affecting reward accounts are outside this payment-output +domain. Receiving key witnesses do not implicitly add explicit guards. + +### Receiving-aware script contexts + +Extend the receiving-aware language's ScriptPurpose with +`Receiving ScriptHash Integer`, retaining the executing hash first and the raw +original body-local output index second. For proposed V4, extend ScriptInfo with +`ReceivingScript Integer TxOut`, exposing the original index and the exact +resolved output. Retain the executing hash in `scriptContextScriptHash`. +Existing V4 purposes, including +Guarding, remain available. `txInfoRedeemers` includes Receiving entries. + +Preserve protection in all visible translated outputs, consumed inputs, +reference inputs and nested views, including those exposed to Guarding. The +Receiving validator checks its resolved output's datum, assets and staking +credentials as required by its contract. It may inspect other visible outputs +for wider invariants, but that does not replace their separate executions. + +### Ledger redeemer tags and Plutus Data + +Propose the following ledger CBOR redeemer tags, retaining Guarding at `6`: ```cddl -; Extend ScriptPurpose with Receiving redeemer_tag = - 0 ; spend - / 1 ; mint - / 2 ; cert - / 3 ; reward - / 4 ; voting + 0 ; spend + / 1 ; mint + / 2 ; cert + / 3 ; reward + / 4 ; voting / 5 ; proposing - / 6 ; receiving ; NEW: script validates output creation to a ProtectedAddress + / 6 ; guarding + / 7 ; receiving ``` +Ledger CBOR tags and Plutus Data constructor indexes are separate formats. +For the proposed receiving-aware V4, retain the existing ScriptPurpose Data +indexes (Minting 0, Spending 1, Withdrawing 2, Certifying 3, Voting 4, +Proposing 5, Guarding 6) and append Receiving at `7`. Retain the corresponding +ScriptInfo indexes and append ReceivingScript at `7`. Receiving encodes as +`Constr 7 [scriptHash, originalOutputIndex]`; ReceivingScript encodes as +`Constr 7 [originalOutputIndex, resolvedOutput]`. The matching numeric +Receiving indexes do not make the two complete numbering schemes identical. +Publish independent vectors for each format. + +### Batch budgets, collateral and failure + +Targets, signatures, redeemers, language views and integrity hashes are +body-local. Existing batch script availability, phase-2 collection/evaluation, +execution-unit limits, fees and block accounting include every Receiving +invocation across the batch. + +A child-only Plutus invocation requires the top-level transaction's collateral +under the existing batch rule. Subtransactions gain no collateral-return field. +Key/native-only Receiving adds no Plutus collateral requirement. + +A protected top-level collateral-return output is always invalid in phase 1, +even if scripts would succeed, and never enters the Receiving target domain. +A protected key UTxO used as collateral input follows existing eligibility and +key-witness rules. + +If any Receiving evaluation fails or exceeds its budget, no ordinary output in +the batch is created. A matching phase-2-invalid transaction may follow the +existing collateral-only ledger transition, consuming collateral and creating +only an eligible unprotected collateral return. A claimed-valid transaction +whose scripts fail is rejected for the validity mismatch. Receiving adds no +separate rollback or evaluation pipeline. + +### Vectors + +[Protected address vectors](test-vectors/protected-addresses.json) reuse the +unchanged credential payloads from CIP-19's published address examples and set +only `0x08` for the six supported families on testnet and mainnet. They are +proposed format vectors, not evidence of network activation. + ## Rationale: How does this CIP achieve its goals? -The proposed `ProtectedAddress` and `Receiving` script purpose solve the long-standing problem of uncontrolled UTxO injection at script addresses. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can: +Protected payment addresses and the `Receiving` script purpose let contracts prevent unauthorized UTxO creation at their protected destinations. By giving smart contracts the ability to validate outputs being sent to them during phase-2 validation, developers can: - Ensure only valid state transitions or authenticated deposits are accepted - Enforce access control and structural correctness of datums before a UTxO is created @@ -97,7 +236,13 @@ The proposed `ProtectedAddress` and `Receiving` script purpose solve the long-st - Threading/state tokens - The issues from cyclic depenencies that are inherent in both of the above. -This CIP is also forward-compatible and additive. Existing contracts using unprotected `Address` remain unaffected. Contracts that require guarded output validation may opt-in by using `GuardScriptCredential`. +Contracts opt in through address protection, without a new credential type. +Anyone may still send to an unprotected address with the same payment hash. +Contracts that rely on authenticated creation must verify protection during +spending as well as validate each specific protected output during Receiving. +Protection +does not automatically validate assets, datums or staking credentials, nor +replace every protocol's state-token invariants. ### Alternatives considered @@ -109,13 +254,22 @@ This CIP is also forward-compatible and additive. Existing contracts using unpro ### Backward Compatibility -This proposal can be **fully backward-compatible** with previous Plutus versions. There are no obvious issues with this. However, for extra-safety and to avoid any -unintended consequences, it is also possible to strictly disallow Receiving scripts to be present in transactions that also execute scripts from Plutus versions before they -are introduced. +Historical unprotected addresses and supported ordinary transactions retain +their encodings and behavior. A preactivation transaction cannot introduce a +protected address or Receiving redeemer. + +When an older language's actual context would contain an unrepresentable +protected address or Receiving purpose, collection fails in phase 1 with a +specific context-translation error. This includes protected key/native outputs +visible to an older Plutus script, even when no Receiving Plutus script runs. +Protection must not silently be projected away. Apply this policy to the +context required by the language/purpose; it is not a blanket ban on every +mixed-language batch. Existing subtransaction restrictions on V1–V3 remain. Wallets, nodes, and off-chain tooling must be updated to: -- Recognize and encode/decode `ProtectedAddress` addresses -- Include `Receiving` redeemers in transactions with outputs to `ProtectedAddress`s +- Recognize and encode/decode protected payment addresses +- Include distinct output-indexed `Receiving` redeemers and budgets for every + protected Plutus output, including identical duplicates - Extend phase-2 validation to evaluate `Receiving` scripts Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano-api`, `cardano-ledger`, `plutus-ledger-api`) would require coordinated upgrades. @@ -126,15 +280,21 @@ Node software, CLI, Plutus libraries, and serialization tooling (e.g., `cardano- - Agreement from Cardano Ledger and Plutus teams - Implementation of: - - `ProtectedAddress` in address serialization + - Protected payment addresses in address serialization - `Receiving` in ledger script validation rules - `Receiving` in Plutus - Phase-2 validation for transactions with outputs to protected addresses -- Inclusion in a future era upgrade (e.g., Voltaire or beyond) +- An agreed activation era/protocol version and receiving-aware language; + Dijkstra/V4 is proposed, with successor-era/language fallback if frozen +- CIP-19, ledger CBOR/Huddle/CDDL, Plutus Data and formal-spec agreement +- Non-skipped executable-spec conformance, historical replay, performance and + complete node/consensus construction/validation integration +- Named release-critical tooling/serialization/wallet readiness and an actual + upgrade rehearsal; integration testing alone does not establish activation ### Implementation Plan -1. Extend ledger types to introduce the `ProtectedAddress` type. +1. Extend ledger address types to represent protected payment addresses. 2. Modify transaction validation logic to detect outputs to protected addresses and invoke appropriate scripts. 3. Introduce CDDL changes for redeemer tags and the new address variant. 4. Update transaction witnesses, CLI tooling, and Plutus interpreter to support `Receiving`. diff --git a/CIP-0160/test-vectors/protected-addresses.json b/CIP-0160/test-vectors/protected-addresses.json new file mode 100644 index 0000000000..df74edc49e --- /dev/null +++ b/CIP-0160/test-vectors/protected-addresses.json @@ -0,0 +1,104 @@ +{ + "status": "proposed; activation not established", + "source_commit": "b4a593c960f2751fef2ddc8df28bec7b22c68eb5", + "source": "CIP-0019/README.md existing test vectors", + "protection_mask": "0x08", + "vectors": [ + { + "network": "mainnet", + "family": 0, + "unprotected_bech32": "addr1qx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgse35a3x", + "protected_bech32": "addr1px2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs2zvy7v", + "unprotected_hex": "019493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251", + "protected_hex": "099493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251" + }, + { + "network": "mainnet", + "family": 1, + "unprotected_bech32": "addr1z8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs9yc0hh", + "protected_bech32": "addr1r8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgskhqkca", + "unprotected_hex": "11c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251", + "protected_hex": "19c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251" + }, + { + "network": "mainnet", + "family": 2, + "unprotected_bech32": "addr1yx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs2z78ve", + "protected_bech32": "addr19x2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shse3x7rn", + "unprotected_hex": "219493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8ec37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "299493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8ec37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + }, + { + "network": "mainnet", + "family": 3, + "unprotected_bech32": "addr1x8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shskhj42g", + "protected_bech32": "addr188phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs9y2v9z", + "unprotected_hex": "31c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542fc37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "39c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542fc37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + }, + { + "network": "mainnet", + "family": 6, + "unprotected_bech32": "addr1vx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzers66hrl8", + "protected_bech32": "addr1dx2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzers27erq8", + "unprotected_hex": "619493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e", + "protected_hex": "699493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e" + }, + { + "network": "mainnet", + "family": 7, + "unprotected_bech32": "addr1w8phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcyjy7wx", + "protected_bech32": "addr108phkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtc5k273x", + "unprotected_hex": "71c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "79c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + }, + { + "network": "testnet", + "family": 0, + "unprotected_bech32": "addr_test1qz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs68faae", + "protected_bech32": "addr_test1pz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzer3n0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgsf53yjn", + "unprotected_hex": "009493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251", + "protected_hex": "089493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251" + }, + { + "network": "testnet", + "family": 1, + "unprotected_bech32": "addr_test1zrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgsxj90mg", + "protected_bech32": "addr_test1rrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gten0d3vllmyqwsx5wktcd8cc3sq835lu7drv2xwl2wywfgs4pak5z", + "unprotected_hex": "10c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251", + "protected_hex": "18c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f337b62cfff6403a06a3acbc34f8c46003c69fe79a3628cefa9c47251" + }, + { + "network": "testnet", + "family": 2, + "unprotected_bech32": "addr_test1yz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shsf5r8qx", + "protected_bech32": "addr_test19z2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerkr0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs68m70v", + "unprotected_hex": "209493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8ec37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "289493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8ec37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + }, + { + "network": "testnet", + "family": 3, + "unprotected_bech32": "addr_test1xrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shs4p04xh", + "protected_bech32": "addr_test18rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gt7r0vd4msrxnuwnccdxlhdjar77j6lg0wypcc9uar5d2shsxjhvfa", + "unprotected_hex": "30c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542fc37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "38c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542fc37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + }, + { + "network": "testnet", + "family": 6, + "unprotected_bech32": "addr_test1vz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzerspjrlsz", + "protected_bech32": "addr_test1dz2fxv2umyhttkxyxp8x0dlpdt3k6cwng5pxj3jhsydzers3kdl0z", + "unprotected_hex": "609493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e", + "protected_hex": "689493315cd92eb5d8c4304e67b7e16ae36d61d34502694657811a2c8e" + }, + { + "network": "testnet", + "family": 7, + "unprotected_bech32": "addr_test1wrphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtcl6szpr", + "protected_bech32": "addr_test10rphkx6acpnf78fuvxn0mkew3l0fd058hzquvz7w36x4gtc077z7r", + "unprotected_hex": "70c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f", + "protected_hex": "78c37b1b5dc0669f1d3c61a6fddb2e8fde96be87b881c60bce8e8d542f" + } + ] +}