17 - Dash Platform Payment Addresses and HD Derivation#

  DIP: 0017
  Title: Dash Platform Payment Addresses and HD Derivation
  Author(s): Samuel Westrich
  Special-Thanks: Dash Platform Team
  Comments-Summary: No comments yet.
  Status: Proposed
  Type: Standard
  Created: 2025-11-28
  License: MIT License
  Replaces: -
  Superseded-By: -

Table of Contents#

  1. Abstract

  2. Motivation

  3. Prior Work

  4. Specification

    1. Overview

    2. Derivation Path Definition

    3. Wallet and Hardware Wallet Behavior

  5. Rationale

  6. Backwards Compatibility

  7. Reference Implementation

  8. Security Considerations

  9. Privacy Considerations

  10. Test Vectors

  11. DIP-9 Registry Update

  12. Copyright

Abstract#

This DIP defines Dash Platform payment addresses and their hierarchical deterministic (HD) derivation under DIP-9. It uses Dash coin type 5’ on mainnet and coin type 1’ on test networks, and introduces a new DIP-9 feature index for Platform payments. The specification standardizes derivation paths (including account separation) and wallet/hardware wallet guidance for Platform payment keys. Address encoding (version bytes and formats) and script-hash address formats are defined in DIP-18.

Motivation#

While Dash Platform identities can hold balances, identity-to-identity payments alone cannot satisfy the requirements for value transfer on Platform. Identities are designed to be persistent, publicly linkable entities with DPNS names and associated documents. Transferring value directly between identities permanently links those identities on-chain, which is undesirable for common payment scenarios and prevents future improvements to privacy and fungibility.

Identity-based transfers also make onboarding unnecessarily complex. Creating a new identity requires funding an asset-lock transaction on the Core chain before the identity can be registered. With a Platform-level payment mechanism, an existing user can send value directly to an address controlled by a new user, allowing that user to create or top up an identity entirely within Platform.

Additionally, many use cases require value that is not tied to a persistent identity—such as one-time payment targets, merchant invoices, or exchange integrations. Platform payment addresses provide this flexibility in a manner analogous to Core-chain addresses.

For these reasons, DIP-17 introduces an address subsystem that complements identity balances and enables direct value transfer, simplified onboarding, improved privacy, and broader application support within Dash Platform. Wallets require an unambiguous address type, network-specific encodings, and deterministic derivation paths that coexist with BIP-44 Core chain funds and existing DIP-9 features (masternodes, identities, DashPay). This DIP defines a single standard so wallets, hardware wallets, and services can implement Platform payments.

Prior Work#

Specification#

Overview#

Platform payment keys identify recipients of value on Dash Platform. This value includes Dash Credits, which represent DASH held on Platform, as well as other Platform-based payments. These keys are independent of Dash Platform identities and do not belong to an identity’s key set. Instead, they function as standalone payment keys that hold value outside of any identity. They use a single secp256k1 key pair and are not script-based. They are not valid Dash Core chain addresses and MUST NOT be used for Core chain transactions. Their encoding format is specified in DIP-18.

Derivation Path Definition#

The Platform payment feature is assigned DIP-9 feature index 17'. The canonical derivation path is:

m / 9' / coin_type' / 17' / account' / key_class' / index

Normative requirements:

  • purpose' MUST be 9'.

  • coin_type' MUST be 5' on mainnet (Dash SLIP-44 coin type) and MUST be 1' on testnet/devnet/regtest (SLIP-44 test coin type), consistent with BIP-44 conventions.

  • feature' MUST be 17' (Platform payment feature).

  • account' MUST be hardened. 0' is the default account. Additional accounts MAY be used following BIP-44-style multi-account semantics.

  • key_class' MUST be hardened. The default class for Platform payment receive keys is 0'. Additional hardened classes MAY be defined by future DIPs; 1' is reserved for wallet-internal or change-like segregation if a wallet chooses to implement it. Wallets MUST ignore unknown key_class values rather than rejecting the entire account.

  • index MUST be non-hardened (0 ≤ index ≤ 2³¹−1).

  • No BIP-44 change level is used; privacy is obtained by incrementing index and optionally segregating with key_class'.

Default account paths:

Network(s)

Default account path

Mainnet

m/9'/5'/17'/0'/0'/index

Testnet / Devnet / Regtest

m/9'/1'/17'/0'/0'/index (coin type 1' for test networks)

Wallets MAY derive and expose an extended public key at m/9'/5'/17'/account'/key_class' (mainnet) or m/9'/1'/17'/account'/key_class' (test networks) for watch-only or monitoring. They MUST NOT expose hardened parent levels.

Accounts follow BIP-44 semantics: account' partitions user-controlled sets of Platform payment keys, enabling multiple profiles or organizational separations while preserving hardened isolation between accounts.

Wallet and Hardware Wallet Behavior#

  • Wallets MUST derive Platform payment keys only from m/9'/5'/17'/account'/key_class'/index (mainnet) or m/9'/1'/17'/account'/key_class'/index (test networks). Address encoding of the resulting public keys is specified in DIP-18.

  • Wallets SHOULD clearly separate Platform chain balances from Core chain balances in UI and storage.

  • Wallets SHOULD rotate addresses by incrementing index to avoid reuse; a default gap limit of 20 is RECOMMENDED for discovery.

  • Wallets MAY support watch-only by exporting the xpub at m/9'/5'/17'/account'/key_class' (mainnet) or m/9'/1'/17'/account'/key_class' (test networks).

  • Wallets MAY present multiple accounts following BIP-44 semantics (distinct account' values), and SHOULD clearly label the active account in UI.

  • Hardware wallets MUST whitelist the above derivation path and display a label such as “Dash Platform address” when showing or signing.

  • Hardware wallets MUST apply the address encodings defined in DIP-18 and MUST NOT reinterpret these as Core chain P2PKH/P2SH.

  • If a wallet does not implement Platform, it simply never derives the 17' feature path.

Rationale#

  • Coin type 5’ on mainnet, 1’ on test networks: Mainnet keeps Dash SLIP-44 coin type 5’, while testnet/devnet/regtest follow SLIP-44 convention with coin type 1’. This avoids new registry allocations and keeps all Dash features under the established namespaces.

  • DIP-9 vs BIP-44: DIP-9’s feature level cleanly separates Platform addresses from Core chain funds and from identities/masternodes without overloading BIP-44’s change level or accounts.

  • Feature index 17’: The next available DIP-9 feature after 16’ (DashPay Auto Accept Proof)) is reserved for Platform payments, avoiding collisions with existing features.

  • Hardened upper levels: 9'/coin_type'/17'/account'/key_class' isolate Platform keys from other features and from each other. An xpub leak below key_class' cannot compromise hardened parents.

  • Non-hardened leaf index: Enables watch-only, auditing, and future multisig/shared-custody schemes that rely on unhardened derivation of child public keys. Fully hardened leaves were rejected to preserve these capabilities.

  • Accounts retained: A hardened account' level maintains BIP-44-style multi-account semantics while still isolating Platform keys under the DIP-9 feature branch.

  • No BIP-44 change level: Platform addresses are not UTXO change outputs; a linear index (optionally partitioned by key_class') keeps the model simple for hardware wallets and avoids misuse of the 0/1 change bit.

Backwards Compatibility#

  • Classic Dash addresses (X..., 7..., y..., 8...) are unaffected. Nodes do not accept Platform addresses in Core chain scripts.

  • DIP-3/8 masternode derivations and DIP-13 identity derivations remain unchanged.

  • Existing seeds stay valid; wallets can add Platform support without migration.

  • Wallets unaware of Platform will not derive m/9'/5'/17'/... and therefore will not interfere with Platform balances.

Reference Implementation#

The following pseudo-code is normative for deriving a Platform payment address:

function platform_payment_key(seed, account, key_class, index, network):
    # seed: BIP-39/BIP-32 seed bytes
    # account: hardened int (default 0)
    # key_class: hardened int (default 0)
    # index: non-hardened child number
    # network: "mainnet" or "testnet"

    coin_type = 5' if network == "mainnet" else 1'
    path = [9' , coin_type , 17' , account' , key_class' , index]

    master_priv, master_chain = bip32_master(seed)  # HMAC-SHA512("Bitcoin seed", seed)
    child_priv, child_chain = bip32_derive(master_priv, master_chain, path)

    pubkey = secp256k1_compress(secp256k1_point(child_priv))
    payload = RIPEMD160(SHA256(pubkey))

    return {
        "private_key": child_priv,
        "public_key": pubkey,
        "hash160": payload
    }

Encoding and decoding of these payloads into addresses is specified in DIP-18.

Security Considerations#

  • Derivation uses hardened separation at feature' and key_class'; compromise of a Platform xpub does not expose other features or other key classes.

  • Leakage of the xpub at m/9'/coin_type'/17'/account'/key_class' allows derivation of all Platform public keys for that key class but does not leak private keys or other features.

  • Wallets MUST reject attempts to use Platform addresses in Core chain transactions to prevent misdirected funds.

  • Hardware wallets MUST show the full derivation path and “Dash Platform address” to reduce key-path confusion attacks.

  • The checksum and distinct prefixes mitigate accidental prefix confusion with X/7/y/8 addresses.

Privacy Considerations#

  • Wallets SHOULD avoid address reuse by incrementing index and MAY use separate key_class' values to segregate user profiles or accounts.

  • Wallets SHOULD avoid correlating Platform index progression with Core chain BIP-44 indices to reduce cross-layer linkability.

  • Sharing xpubs at m/9'/coin_type'/17'/account'/key_class' enables watch-only but also enables address graph reconstruction for that class; applications should only share when necessary.

Test Vectors#

Mnemonic (test-only): abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about
Passphrase: "" (empty)

All hex strings are lowercase, big-endian. Address encodings for the HASH160 values are specified in DIP-18.

Vector

Path (mainnet / testnet)

account’

key_class’

index

Private Key (hex)

Compressed Pubkey (hex)

HASH160(pubkey)

1

m/9’/5’/17’/0’/0’/0 (mainnet) / m/9’/1’/17’/0’/0’/0 (test)

0’

0’

0

6bca392f43453b7bc33a9532b69221ce74906a8815281637e0c9d0bee35361fe

03de102ed1fc43cbdb16af02e294945ffaed8e0595d3072f4c592ae80816e6859e

f7da0a2b5cbd4ff6bb2c4d89b67d2f3ffeec0525

2

m/9’/5’/17’/0’/0’/1 (mainnet) / m/9’/1’/17’/0’/0’/1 (test)

0’

0’

1

eef58ce73383f63d5062f281ed0c1e192693c170fbc0049662a73e48a1981523

02269ff766fcd04184bc314f5385a04498df215ce1e7193cec9a607f69bc8954da

a5ff0046217fd1c7d238e3e146cc5bfd90832a7e

3 (non-default class)

m/9’/5’/17’/0’/1’/0 (mainnet) / m/9’/1’/17’/0’/1’/0 (test)

0’

1’

0

cc05b4389712a2e724566914c256217685d781503d7cc05af6642e60260830db

0317a3ed70c141cffafe00fa8bf458cec119f6fc039a7ba9a6b7303dc65b27bed3

6d92674fd64472a3dfcfc3ebcfed7382bf699d7b

DIP-9 Registry Update#

Reserve DIP-9 feature index 17' for “Platform Payment Addresses”:

Feature Index

Feature

DIP

Note

17'

Platform Payment Addresses

DIP-17

Sub-path: 17'/account'/key_class'/index (default account’ = 0', key_class’ = 0')