Derived Account

Overview

Derived accounts allow software to compute account locations deterministically. Hierarchical wallets derive many keys from a master secret and path, while smart-contract platforms can calculate addresses from deployment parameters or program seeds. Solana program-derived addresses are calculated from a program ID and seeds and intentionally have no corresponding Ed25519 private key, allowing the program to authorize actions through runtime rules.

The security model depends on what is derived. A child key derived from a wallet seed may have its own private key and normal signing ability. A program-derived address may be controlled only by the designated program. A contract address derived from a deployer, nonce, salt, or code hash is governed by deployed code. Therefore, Account Key and derived account should not be assumed to have a one-to-one relationship.

Derivation inputs must be canonical and domain-separated. Ambiguous seed encoding, inconsistent path notation, or reused inputs across environments can produce unexpected addresses or collisions at the application layer. Teams should store the derivation method, network, program or parent identifier, seed encoding, and version. Sensitive seeds used for key derivation must remain secret, while public address seeds may still reveal relationships among accounts.

A derived address can be calculated before any on-chain state exists. Applications must verify that the account has been created, initialized by the expected program, and funded as required. For payment routing, deterministic accounts can simplify customer mapping, but reconciliation should confirm actual ownership and state on the Canonical Chain. Sending funds to a predictable but uninitialized or incorrectly controlled address can still create loss or recovery complexity.