¿Qué es una dirección derivada de programa (PDA)?
Escrito por Petar Todorov
Las Direcciones Derivadas de Programa (PDAs, por sus siglas en inglés) son cuentas en la blockchain de Solana que tienen propiedades especiales. Usar PDAs correctamente puede hacer que el desarrollo de dApps en Solana sea rápido y eficiente, ya que ayudan en la comunicación entre programas.
Este artículo explicará qué son las PDAs, qué problemas resuelven, cómo funcionan y en qué se diferencian de otras cuentas dentro del modelo de cuentas de Solana.
¿Qué es una dirección derivada de programa (pda)?
Una Dirección Derivada de Programa es una cuenta en la blockchain de Solana que no tiene clave privada. Dado que una PDA no es una clave pública, la dirección de la cuenta se encuentra usando el ID del programa, una función de hashing SHA-512, un arreglo de seeds y una seed especial llamada bump.
¿Qué es una cuenta estándar en Solana?
Una cuenta estándar de Solana tiene tanto una clave privada como una clave pública (32 bytes cada una), y juntas forman un par de claves (keypair), que tiene 64 bytes de longitud y se ubica sobre una curva elíptica (ED25519). Para que el keypair sea válido, debe estar sobre esta curva.
Aquí hay una representación de una Curva Elíptica ED25519:

¿Cómo se derivan las direcciones de programa?
Las PDAs requieren tres componentes principales:
- ID del Programa Padre - el ID del programa padre que crea la PDA
- Seeds - un arreglo de strings
- Bump Seed - asegura que la PDA no tenga clave privada
Crear una Dirección Derivada de Programa válida requiere tomar el ID de su programa padre y el arreglo de seeds, y pasarlos por una función de hashing SHA-512.
En aproximadamente el 50% de los casos, sin embargo, el resultado de este hash es un keypair que se ubica sobre la Curva Elíptica ED25519. Debido a que las PDAs no tienen clave privada, las Direcciones Derivadas de Programa no deben estar sobre la curva elíptica. Para evitar que las PDAs tengan claves privadas, se usa una seed especial llamada bump para "sacar" el resultado del hash de la curva.
El bump seed no es más que un número, que comienza en 255. En el caso de que, incluso con el bump seed, el resultado del hash siga estando sobre la curva, la función de hashing se ejecuta nuevamente, con un bump equivalente a 254, luego 253, etc., hasta que el resultado generado no esté sobre la curva.
Nota: Las seeds pueden ser cualquier string arbitrario, pero los desarrolladores las usan en un contexto específico a las variables de estado del programa padre para crear estructuras similares a hashmaps.
¿Qué problemas resuelven las PDAs?
Las direcciones derivadas de programa optimizan la confirmación de transacciones al generar firmas de transacción de forma programática, ayudando así a que servicios trustless como las cuentas de DeFi funcionen sin problemas.
Aquí hay un caso de uso hipotético para las PDAs.
Consideremos un programa de Solana que permite al usuario establecer un NFT como su foto de perfil (PFP) predeterminada. El programa constará de dos programas:
- El programa PFP - crea cuentas para almacenar la foto de perfil seleccionada por un usuario
- El programa Core - actúa como proxy entre las entradas del usuario y el programa PFP
Para que el programa PFP actualice la foto de perfil seleccionada de un usuario, necesitaría usar su clave privada para firmar una transacción que cambie la foto de perfil del usuario. Sin embargo, esto también significaría que el programa necesitaría almacenar su clave privada on-chain.
Un programa de Solana no puede usar su clave privada para firmar una transacción en su propio nombre, porque la clave misma quedaría almacenada on-chain, haciéndola visible para todos. Si esto ocurriera, la clave privada podría usarse para firmar transacciones en nombre del programa y cambiar la foto de perfil de cualquier usuario.
Imaginemos que el programa PFP fuera responsable de manejar millones de tokens SOL. Un exploit así se convertiría en un hackeo mayor. Las Direcciones Derivadas de Programa resuelven esto.
¿Por qué son importantes las PDAs?
Las Direcciones Derivadas de Programa cumplen un papel fundamental en la programación de Solana porque ayudan a la comunicación entre distintos programas (Invocaciones Cross Program) y pueden actuar como un hashmap para almacenar datos específicos que su programa padre puede actualizar y modificar fácilmente.
1. Almacenar las variables de estado de un programa
Las PDAs permiten a los desarrolladores de Solana almacenar y rastrear una variable o un conjunto de variables relacionadas con un usuario específico. El mejor caso de uso de una PDA es almacenar variables de estado o datos para su programa padre, ya que por defecto ha autorizado al programa padre a hacer cambios en su nombre.
2. Usar PDAs como hashmaps
Un mapping representa un conjunto de pares clave-valor, y se usa para encontrar fácilmente información asociada a una clave. En el desarrollo en Solana, las seeds de una PDA y los strings correctos pueden usarse para lograr el mismo resultado.
Volvamos a nuestro ejemplo anterior de la foto de perfil del wallet.
Una vez que un usuario selecciona el PFP de su wallet, el programa PFP toma la imagen seleccionada, la dirección del usuario, y las usa como 'seeds' para crear una PDA que almacenaría la elección del usuario.
Una vez que la Dirección Derivada de Programa es encontrada exitosamente por el algoritmo de hashing, su clave pública queda 'mapeada' a la dirección del usuario y al avatar NFT elegido.
La función de hashmap podría aprovecharse aún mejor proporcionando otra PDA como tercera seed. Podemos tomar todas las fotos de perfil disponibles y almacenarlas en una PDA separada, pasando cada foto de perfil como su seed, y terminamos con una PDA que almacena todas las fotos de perfil.
Ahora, cuando un usuario llega y elige su foto de perfil, la PDA se verá como un hashmap porque las seeds se pasan de tal forma que, si las observas, sabrás que de una selección de fotos de perfil (la PDA de grupo PFP), una dirección de usuario que pasamos como primera seed ha elegido la foto de perfil que pasamos como segunda seed.
Este ejemplo podría ampliarse para crear estructuras de hashmap aún más profundas.

3. Invocaciones cross program
Las Invocaciones Cross Program (CPI) son el proceso mediante el cual un programa llama a una función en otro programa. Las CPIs son útiles porque permiten una mejor composabilidad de código.
Volviendo a nuestro ejemplo, digamos que un usuario quiere cambiar su foto de perfil de un Degen Ape a un avatar de Solana Monkey Business.
Esto es lo que sucede internamente:
Al iniciar sesión en su wallet, el contrato core tomará la dirección del usuario (clave pública) y buscará una PDA ya creada, cuyas seeds incluyan la clave pública del usuario.
Después de encontrarla, el programa core invocará una función en el programa PFP llamada 'changePFP()' (esto es una Invocación Cross-Program), que aceptaría como argumento la PDA que ya ha sido 'seleccionada' por el programa Core.
Una vez que se llama a la función, la PDA seleccionada verificará si la cuenta que está 'solicitando' que se realice el cambio es su padre. Si la PDA no coincide, la transacción será rechazada, porque solo un programa padre puede modificar los datos de una PDA.
Dado que el programa PFP es el padre de la PDA seleccionada, se le permitirá cambiar la foto de perfil seleccionada del usuario de un Degen Ape a un avatar SMB.

Las Direcciones Derivadas de Programa permiten que sus programas padre firmen en su nombre y pueden usarse para almacenar el estado de un programa, hashmaps e invocaciones cross-program. Las PDAs son un tema fundamental en el ámbito de la programación en Solana que permiten un desarrollo de dApps rápido y eficiente.
Preguntas frecuentes sobre direcciones derivadas de programa
Al trabajar con Direcciones Derivadas de Programa, puede ser útil entender cómo Solana maneja las transacciones y los datos. Los dos tipos principales de cuentas son las ejecutables y las no ejecutables.
¿Qué es una cuenta ejecutable?
Las cuentas ejecutables, también conocidas como programas, son similares a un smart contract de Ethereum: un fragmento de código que cambia su estado cuando una cuenta interactúa con él.
¿Qué es una cuenta no ejecutable?
Las cuentas de datos no ejecutables se usan simplemente para almacenar datos (por ejemplo, la cantidad de SOL que posee la cuenta, NFTs, balances de tokens, etc.), es decir, las variables de estado de un programa.
¿En qué se diferencia el almacenamiento de datos de un programa de Solana de los smart contracts de Ethereum?
Una diferencia fundamental entre Ethereum y Solana es cómo se organiza el almacenamiento del código ejecutable. Los smart contracts en Ethereum vienen 'preconstruidos' con almacenamiento donde el smart contract almacena todas sus variables de estado. En comparación, los programas en Solana no tienen almacenamiento preconstruido, pero sí cuentan con cuentas de datos separadas que contienen las distintas variables de estado que desean almacenar y referenciar.
Resúmenes relacionados
Solana27 de julio de 2026
Nodos de Solana: validadores, nodos RPC y self-hosting
Qué son los nodos de Solana, en qué se diferencian los validadores, los nodos RPC y los sistemas de datos secundarios, y cuándo conviene hacer self-hosting en lugar de usar un proveedor.
Solana22 de julio de 2026
Datos de archivo de Solana: cómo consultar el historial completo de bloques y transacciones
Datos de archivo de Solana explicados: por qué los nodos podan el historial, qué métodos de RPC necesitan acceso a archivo, y cómo consultar el historial completo de bloques y transacciones a escala.
Solana28 de mayo de 2026
Solana Agent Kit versus GOAT versus ElizaOS: ¿qué framework deberías usar?
Comparación entre Solana Agent Kit, GOAT y ElizaOS: profundidad nativa en Solana, alcance multichain o runtime de agentes completo. Incluye ejemplos de código y un marco de decisión.

Construye magia blockchain
Alchemy combina los productos y herramientas de desarrollo Web3 más potentes con recursos, comunidad y un soporte legendario.