What problem it solves
Smart programs on Solana often need to own accounts: a vault that holds deposited tokens, or a record that stores a user's position. If such an account were controlled by an ordinary key, whoever held the key could take the funds. A PDA lets the program itself control the account in a way no person can override.
How it is made
The Solana documentation describes a PDA as a 32-byte address deterministically derived from a program ID and a set of seeds, such as a user's address or a label. Given the same inputs, the derivation always gives the same address, so a program, a client and an explorer can all compute it independently. The result is checked to confirm it is not a valid Ed25519 public key.
Why it has no private key
Because the address is off the curve, the documentation notes, no one can produce a cryptographic signature for it. There is no private key to steal. When a program needs the PDA to authorise an action, it does so through the runtime's invoke_signed mechanism during a cross-program invocation, which the network verifies, instead of with a key.
Where you meet them
PDAs appear everywhere in Solana apps: vaults for exchanges and lending protocols, escrow accounts and the addresses of user data. When you look at a token vault on a block explorer, its owner is often a PDA. A PDA holding funds is controlled by the program's code, so the safety of those funds depends on that program being correct, not on any person.
What it means for security
If a program has a bug, a PDA's funds can be at risk, and upgrade authority over the program matters too. When using a new application, consider how long its code has operated and whether it has been audited.