Solana Program Library Token (SPL Token) es el estándar de Solana para los tokens: cómo crear tokens y cómo deben comportarse. Es el equivalente de Solana a los estándares de tokens de Ethereum como ERC-20 (tokens fungibles) y ERC-721 (NFTs).
A diferencia de Ethereum, que utiliza contratos inteligentes separados para cada estándar de token, todos los tokens SPL en Solana utilizan el mismo programa. Esto significa que todos los tokens en Solana comparten la misma lógica subyacente, con parámetros específicos del token establecidos durante la creación en lugar de mediante un código de programa diferente. El programa SPL Token contiene solo la lógica, mientras que todos los datos de los tokens se almacenan por separado. Esto es coherente con la forma en que Solana separa la lógica del estado en cuentas separadas.
Aquí hay una forma de pensar en los tokens SPL en contraste con Ethereum: en Ethereum, generalmente despliegas un nuevo contrato inteligente (como ERC-20) para cada token único. En Solana, en lugar de desplegar nuevo código, interactúas con este único programa SPL, que contiene todas las instrucciones necesarias para definir tokens, acuñar, transferir, aprobar y quemar.
En Ethereum, cada token es su propio contrato inteligente con código personalizado, lo que significa que USDC podría manejar las aprobaciones de manera diferente que DAI; esto tiene ventajas en términos de flexibilidad, pero también puede llevar a comportamientos inesperados. En Solana, cada SPL token utiliza la misma función de transferencia, el mismo sistema de aprobación y los mismos controles de seguridad.
Este artículo explica los conceptos de SPL token y cómo Solana separa la lógica del token de los datos del token. Cubre:
- Cómo la arquitectura de tokens de Solana difiere de la de Ethereum,
- Las tres cuentas clave que hacen que los tokens SPL funcionen,
- Por qué Solana usa un solo programa para todos los tokens, y
- Cómo Solana rastrea los saldos de tokens de los usuarios.
En el próximo artículo, Creating SPL Tokens with Anchor, mostraremos cómo crear y transferir tokens SPL.
Para entender cómo funciona todo esto en la práctica, comenzamos analizando el programa SPL Token en sí. A veces nos referiremos a él simplemente como el programa de tokens (Token Program), pero ambos significan lo mismo.
Token Program
El Token Program de SPL es el programa on-chain central responsable de gestionar la funcionalidad de los tokens SPL. Contiene la lógica para crear tokens SPL y define cómo se comportan. El programa SPL Token reside en una dirección fija: TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA.
El Token Program es propietario de todas las cuentas que almacenan el estado de los tokens SPL (introduciremos estas cuentas a medida que avancemos). Esta propiedad significa que el Token Program es el único programa que puede modificar los datos en estas cuentas.
Para los lectores que necesiten un repaso sobre el modelo de propiedad de cuentas de Solana, consulten Understanding Account Ownership in Solana.
A continuación, discutiremos las diferentes cuentas asociadas con los tokens SPL, que son la Mint account, la Token account y la Associated Token Account (ATA). Cada cuenta juega un papel específico en la contabilidad y transferencia de tokens.
Mint account
Cada token SPL individual tiene una única Mint account que almacena la información global sobre ese token. Contiene datos como el suministro total del token, el número de decimales y qué direcciones (si las hay) tienen la autoridad para acuñar tokens y congelar cuentas (es decir, poner en listas negras). Como se mencionó anteriormente, la lógica central del token permanece en el SPL Token Program.
Cada Mint account es única y se crea a través del SPL Token Program al inicializar un nuevo token SPL. Cuando nos referimos a una dirección de token en Solana, también nos referimos a la dirección de su Mint account, porque son la misma. Por ejemplo, aquí están las direcciones de los tokens (Mint accounts) para USDC y USDT respectivamente: EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v y Es9vMFrzaCERmJfrF4H2FYD4KCoNkY11McCe8BenwNYB.
El siguiente diagrama muestra la relación entre el Token Program y las Mint accounts.
Detalles de la Mint account
Al igual que todas las cuentas de Solana, la Mint account tiene campos de metadatos estándar, que son:
- Lamports (para la renta)
- Owner (que es la dirección del Token Program en este caso)
- Estado ejecutable (un valor de
falseya que es para almacenamiento de datos)
Para más información sobre las cuentas de Solana, consulta Initializing Accounts in Solana and Anchor.
Además de estos campos estándar, la Mint account contiene campos de datos específicos que definen el token en sí:
mint_authority: Dirección permitida para crear nuevos tokens.freeze_authority: Dirección permitida para congelar cuentas de tokens que posean este token.decimals: Número de posiciones decimales (0-9) que utiliza el token.supply: Número total de tokens creados.is_initialized: Bandera booleana (flag) que evita la reinicialización.
Aunque la Mint account almacena información del token, no rastrea los saldos individuales de los usuarios, eso lo manejan cuentas separadas que discutiremos más adelante.
El siguiente diagrama muestra las propiedades de la Mint account.
Las autoridades de acuñación (mint) y congelación (freeze) de una Mint account (como se muestra arriba) se asignan durante su creación y generalmente se establecen en la dirección del firmante de la transacción. Veremos la instrucción para esto en la sección “Instrucciones del Token Program”.
Un aspecto importante de las Mint accounts es cómo controlan el suministro de un token. Esto se maneja a través del campo mint_authority. Lo explicamos a continuación.
Cómo establecer un suministro máximo de tokens
Los tokens SPL implementan el suministro máximo a través de la eliminación de permisos en lugar de límites explícitos. Esta elección de diseño proviene de diferencias fundamentales en cómo Solana y Ethereum manejan el estado.
Los datos de una Mint account no tienen un campo explícito de “suministro máximo” (max supply). Por lo tanto, para crear un suministro fijo, se desactiva la autoridad de acuñación estableciéndola en None (valor nulo). Esto desactiva permanentemente la autoridad de acuñación, ya que no se la asigna a nadie. Dado que ninguna cuenta tiene la autoridad para acuñar más tokens, el suministro total actual se convierte en el máximo fijo.
En Ethereum, la forma tradicional de limitar el suministro total de un token es almacenar explícitamente el número en algún lugar y bloquear la acuñación que exceda este número. Los tokens SPL no tienen una noción de “límite de suministro total” y, por lo tanto, no almacenan dicho número en ninguna parte.
Con SPL, si queremos un suministro total de 1 millón de tokens, acuñamos el millón completo a los poseedores y luego desactivamos la autoridad de acuñación. Alternativamente, como veremos en un tutorial posterior, también podríamos hacer que un programa separado sea el mint_authority y hacer que ese programa deje de acuñar tokens una vez que se alcance el límite de suministro.
Token Accounts y Associated Token Accounts (ATAs)
Como se mencionó antes, la Mint account solo almacena información sobre el token en sí. Para rastrear los saldos individuales de los usuarios, Solana utiliza cuentas separadas llamadas Token Accounts.
Token Accounts
Las Token Accounts son cuentas de Solana que almacenan el saldo de tokens de un usuario, la dirección mint a la que está asociada la cuenta y el owner que puede autorizar transferencias, junto con otros campos que cubriremos en detalle más adelante.
Por diseño, un usuario puede tener múltiples Token Accounts para el mismo token, creadas en diferentes direcciones. Esto crea un desafío, como lo indica la documentación de Solana Program Library:
“Un usuario puede poseer arbitrariamente muchas cuentas de tokens que pertenezcan a la misma mint, lo que dificulta que otros usuarios sepan a qué cuenta deben enviar tokens.”
Esto significa que el saldo de un usuario para un token puede dividirse en varias cuentas en lugar de estar en un solo lugar.
Por ejemplo:
- Alice tiene 5 tokens en una token account y 15 en otra token account. Ambas token accounts pertenecen a la misma mint, por lo que juntas posee 20 tokens de esa mint.
- Sin embargo, si Bob quiere enviarle más tokens a Alice, no tiene una forma fácil de saber en qué cuenta prefiere ella recibirlos.
Esto es lo que la documentación de SPL significa por el desafío de “arbitrariamente muchas cuentas de tokens”. Los saldos no son copias redundantes, sino más bien partes del saldo total distribuidas en múltiples cuentas.
Para resolver este problema, Solana introdujo las Associated Token Accounts (ATAs).
Associated Token Accounts (ATAs)
A diferencia de las Token Accounts regulares, donde los usuarios pueden tener múltiples cuentas por mint, las ATAs son Token Accounts especiales (con una regla determinista para encontrar la dirección) que imponen una relación uno a uno entre la dirección de la billetera de un usuario y una mint. Esto asegura que:
- Cada usuario tenga exactamente una ATA predecible por tipo de token
- Cualquier aplicación pueda encontrar fácilmente el saldo de tokens de un usuario sin conocimiento previo porque la dirección es determinista. Explicamos cómo a continuación.
Este artículo se centra principalmente en las ATAs, ya que se han convertido en el enfoque estándar para gestionar tokens en Solana debido a los desafíos con las direcciones de Token regulares discutidos anteriormente.
¿Cómo se derivan las direcciones ATA?
Una dirección ATA es un Program Derived Address (PDA), derivado de forma determinista a partir de dos entradas:
- La dirección de la billetera del usuario/firmante (la autoridad prevista).
- La dirección de la Mint account del token.
Podemos comparar la Associated Token Account con el mapping(address => uint256) public balanceOf de ERC20 en Ethereum, ya que ambos sirven como una forma de rastrear cuántos tokens posee un usuario.
Debido a que un usuario puede tener múltiples tokens SPL, usar solo la dirección del usuario como clave sería insuficiente para distinguir entre los saldos de diferentes tokens. Es por eso que la dirección mint también se incluye en la derivación. Al combinar tanto la dirección de la billetera del usuario como la dirección mint del token, Solana asegura que cada par (usuario, token) obtenga una dirección ATA única.
Este diseño evita colisiones y aplica una estructura consistente:
user_wallet_address + token_mint_address => associated_token_account_address
Para que esto quede más claro, la siguiente tabla compara cómo Ethereum y Solana gestionan los saldos de tokens.
| Aspecto | Ethereum (ERC-20) | Solana (ATAs) |
|---|---|---|
| Modelo de almacenamiento | Un contrato central almacena los saldos en un mapping | Cada usuario tiene una cuenta separada (ATA) para cada token |
| Ubicación del saldo | Almacenado dentro del contrato del token | Almacenado dentro de la ATA del usuario |
| Quién paga por el almacenamiento | El propietario del contrato (costo de despliegue) | El usuario paga por su cuenta |
| Búsqueda | Llamar a balanceOf(user) |
Derivar la dirección ATA → leer saldo |
| Acceso paralelo | Limitado por el contrato | Totalmente paralelo |
Ambos logran el mismo objetivo —rastrear la propiedad de los tokens— pero el enfoque de Solana permite el procesamiento paralelo, ya que cada saldo está en una cuenta separada.
El diagrama a continuación muestra los campos de una Associated Token Account.
La ATA contiene los detalles del saldo de un usuario para un token/mint específico. Sus campos clave son:
mint: Dirección del token (Mint Account) que posee esta cuenta. Por ejemplo, si esto representa un saldo de USDC, esta sería la dirección de la Mint account de USDC.owner: Aunque está etiquetado como ‘owner’, es la autoridad de la ATA. El verdadero propietario de cada ATA es siempre el Token Program, ya que hace cumplir todas las reglas. El campoowneraquí le dice al Token Program qué autoridad debe firmar para que las actualizaciones o transferencias se realicen. Recuerda del artículo Owner vs Authority, el owner de la cuenta impone sus reglas, mientras que la autoridad es el único firmante válido que puede enviar instrucciones para modificar la cuenta, a menos que esta autoridad haya delegado derechos de firma a través del Token Program.amount: La cantidad de tokens retenidos en este saldo.delegate: Dirección de una cuenta delegada que ha sido aprobada para transferir tokens. Solo puede existir un delegado a la vez para una token account, ya que solo hay un campodelegate. Esto difiere de ERC-20, donde un owner puede aprobar a múltiples spenders.state: El estado de la token account, por ejemplo, este es un enum y puede serUninitialized,InitializedoFrozen.close_authority: Dirección permitida para cerrar la cuenta, por defecto la misma clave pública que elowner, pero elownerpuede designar otraclose_authority. Cuando el saldo de una token account llega a cero, el propietario puede cerrarla para recuperar el SOL utilizado para la renta. Varias herramientas web como la billetera Solflare wallet y Sol-Incinerator ofrecen formas convenientes de cerrar token accounts vacías.
El siguiente diagrama muestra la relación entre el Token Program, la Mint account y la Token account.
(A partir de este momento, cuando decimos “token account”, también incluye las ATAs, ya que las ATAs son simplemente un tipo especial de token account.)
Associated Token Account Program
El Associated Token Account Program tiene la dirección fija ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL. Es un programa onchain que encuentra o crea la ATA correcta para un par usuario-token dado. Maneja la derivación determinista de la dirección y, cuando es necesario, utiliza Cross Program Invocation (CPI) para crear nuevas ATAs a través del Token Program.
Específicamente, el flujo de creación orquestado por el ATA Program es:
A diferencia de Ethereum, donde los saldos existen implícitamente en el almacenamiento del contrato, Solana requiere la creación explícita de cuentas. Esto crea un desafío fundamental de UX: no se pueden enviar tokens a usuarios que no hayan creado explícitamente sus Associated Token Accounts receptoras, ya que el saldo del token se almacena literalmente en la Associated Token Account.
Por lo tanto, antes de enviar cualquier token, debemos crear la ATA para el par usuario-token. La dirección ATA se deriva determinísticamente off-chain utilizando la dirección de la billetera y la dirección mint. Una vez derivada, utilizamos el Associated Token Account Program para crear la ATA on-chain si aún no existe. Esto plantea una importante pregunta de seguridad: si cualquiera puede crear una ATA para otra persona, ¿podrían también asignarse a sí mismos como owner y close_authority de la ATA? Afortunadamente, no. Al crear una ATA para otra billetera, el ATA Program impone que los campos owner y close_authority siempre se establezcan en la dirección de la billetera para la cual se está creando la ATA, no en la del firmante de la transacción. Esta garantía de seguridad está integrada en el código del ATA Program, asegurando que solo el legítimo propietario de la billetera mantenga el control sobre sus tokens y la capacidad de cerrar su cuenta.
Para ilustrar: cuando Alice quiere enviar tokens a Bob, ella deriva la dirección ATA de Bob, la crea on-chain si no existe, y luego llama a la instrucción Transfer del Token Program con la ATA de Bob como destino. (En la práctica, bibliotecas cliente como @solana/spl-token proporcionan funciones auxiliares que combinan los pasos de derivación y creación de la ATA).Para ilustrar: cuando Alice quiere enviar tokens a Bob, ella deriva la dirección ATA de Bob, la crea on-chain si no existe, y luego llama a la instrucción Transfer del Token Program con la ATA de Bob como destino. (En la práctica, bibliotecas cliente como @solana/spl-token proporcionan funciones auxiliares que combinan los pasos de derivación y creación de la ATA).
El diagrama muestra el contenido del ATA program.
Hemos discutido las cuentas involucradas en la creación y gestión de los tokens SPL. A continuación, cubriremos las instrucciones del Token Program y del ATA program. Estas instrucciones te permiten hacer cosas como crear y acuñar nuevos tokens, enviar tokens entre ATAs, establecer aprobaciones para que otros gasten tus tokens, quemar tokens para reducir el suministro y cerrar cuentas vacías para reclamar la renta.
Instrucciones del Token Program
Exploremos las funciones públicas proporcionadas por el Token Program que te permiten interactuar con los tokens SPL.
Ten en cuenta que en los parámetros de las instrucciones a continuación, cuando nos referimos a token accounts, estas pueden ser token accounts regulares o Associated Token Accounts (ATAs), como se discutió anteriormente en la sección de Token Accounts y Associated Token Accounts. Cuando una distinción sea importante, especificaremos explícitamente si nos referimos a token accounts regulares o a ATAs.
El Token Program tiene las siguientes funciones públicas:
InitializeMint: Esta instrucción crea una nueva Mint account, que representa un nuevo token SPL on-chain.
pub fn initialize_mint(
mint_pubkey: &Pubkey, // The mint account to initialize
decimals: u8, // The number of decimal places for the token
mint_authority: &Pubkey, // The account with permission to create new tokens
freeze_authority: Option<&Pubkey> // Optional: The account that can freeze token accounts
) -> Instruction
El mint_pubkey puede ser la dirección de una cuenta keypair no utilizada o un PDA que se pretende inicializar como una Mint account. Veremos este proceso en la práctica en el próximo tutorial.
InitializeAccount: Esta instrucción inicializa una nueva token account regular (no ATA) para guardar el saldo de un usuario para una mint específica de un token SPL.
pub fn initialize_account(
account_pubkey: &Pubkey, // The token account to initialize
mint_pubkey: &Pubkey, // The mint for the new token account
owner_pubkey: &Pubkey // The owner of the new token account
) -> Instruction
Las ATAs son inicializadas por el ATA Program, que realiza una CPI a esta instrucción InitializeAccount tras bambalinas. Veremos cómo más adelante.
Transfer: Esto se usa para transferir unidades de tokens SPL desde la token account de un usuario (origen) a otra (destino). Un “saldo” es simplemente un número almacenado en la associated token account que solo el programa SPL puede modificar. Ten en cuenta que la Mint account y la token account deben existir o, de lo contrario, crearse justo antes de que se llame a la instrucción MintTo (también se aplica para la instrucción MintTo a continuación). Demostraremos esto en el próximo tutorial usando Anchor.
pub fn transfer(
source_pubkey: &Pubkey, // The token account sending tokens (typically the sender's ATA; not the mint account)
destination_pubkey: &Pubkey, // The destination token account (to which tokens are received)
authority_pubkey: &Pubkey, // The owner or delegate authorized to spend from the sending token account
amount: u64 // The number of tokens to transfer
) -> Instruction
MintTo: Esta instrucción crea nuevas unidades de tokens y las agrega a una token account especificada.
pub fn mint_to(
mint_pubkey: &Pubkey, // The token mint address
account_pubkey: &Pubkey, // The token account to mint to
authority_pubkey: &Pubkey, // The mint's minting authority
amount: u64 // The amount to mint
) -> Instruction
Burn: Esta instrucción destruye una cantidad específica de unidades de tokens SPL de una token account, reduciendo el suministro total del token. Esto funciona de manera similar a la función burn de ERC20.
pub fn burn(
account_pubkey: &Pubkey, // The token account to burn from
mint_pubkey: &Pubkey, // The token mint
authority_pubkey: &Pubkey, // The token account's owner/delegate
amount: u64 // The amount to burn
) -> Instruction
Approve: Esta instrucción delega poder de gasto del owner de una token account a un delegate especificado por una cantidad máxima. Establece el delegate de la token account y una cantidad aprobada en esa cuenta; solo puede existir un delegado a la vez. Dentro de ese límite, el delegado puede transferir tokens en nombre del propietario.
A diferencia de ERC‑20, que almacena las asignaciones (allowances) en un mapping de un contrato, SPL registra la aprobación directamente en la token account del owner (generalmente en la ATA). Este diseño permite que una aprobación y una transferencia se completen en una sola transacción, ya que solo se modifica el estado de la token account.
pub fn approve(
source_pubkey: &Pubkey, // The token account granting approval
delegate_pubkey: &Pubkey, // The delegate account
owner_pubkey: &Pubkey, // The owner of the token account granting approval
amount: u64 // The maximum number of tokens the delegate can transfer
) -> Instruction
Revoke: Esta instrucción cancela cualquier aprobación de delegado concedida previamente (hecha con la instrucción Approve). Elimina al delegado por completo estableciendo el campo delegate de la token account en None (sin delegado).
Dado que las aprobaciones no pueden reducirse parcialmente, se debe establecer una nueva aprobación con una cantidad menor si deseas disminuir la asignación, de manera similar a cómo ERC20 disminuye las asignaciones.
pub fn revoke(
source_pubkey: &Pubkey, // The token account revoking approval (same account that previously granted approval)
owner_pubkey: &Pubkey // The owner of the token account revoking approval
) -> Instruction
FreezeAccount: Esta instrucción se utiliza para congelar una token account, previniendo temporalmente cualquier transferencia o transacción que involucre los tokens mantenidos en la cuenta hasta que sea descongelada. En otras palabras, SPL soporta agregar a listas negras (blacklisting) la dirección de la token account de un usuario.
pub fn freeze_account(
account_pubkey: &Pubkey, // The token account to freeze
mint_pubkey: &Pubkey, // The token mint
authority_pubkey: &Pubkey // The mint's freeze authority
) -> Instruction
ThawAccount: Esta instrucción descongela una token account que estaba previamente congelada, permitiendo que se reanuden las transferencias de tokens y las transacciones.
pub fn thaw_account(
account_pubkey: &Pubkey, // The token account to unfreeze
mint_pubkey: &Pubkey, // The token mint
authority_pubkey: &Pubkey // The mint's freeze authority
) -> Instruction
SetAuthority: Esta instrucción cambia quién posee ciertos roles de autoridad en las cuentas mint y token.
Recuerda que una Mint account tiene dos campos que tienen “autoridad”:
mint_authorityfreeze_authority
La (associated) token account tiene dos campos que tienen “autoridad”:
ownerel propietario de los tokens, NO el “propietario en el entorno de ejecución (runtime owner) de Solana” del PDA (este nombramiento es confuso).delegateuna clave pública que puede gastar tokens en nombre del propietario
El account_pubkey en set_authority a continuación puede referirse ya sea a una Mint account o a una token account.
El authority_type especificado debe coincidir con el tipo de autoridad que esa cuenta posee.
El código fuente de Solana para SPL da un nombre de enum para cada uno de los cuatro tipos de autoridad:
MintTokensFreezeAccountAccountOwnerCloseAccount
Ten en cuenta que el programa SPL no se refiere a los roles de autoridad de una manera consistente en la token account y confusamente se refiere al propietario del token como “owner” — esto no debe confundirse con el owner del PDA.
pub fn set_authority(
account_pubkey: &Pubkey, // The mint or token account
current_authority_pubkey: &Pubkey, // The current authority
authority_type: AuthorityType, // The type of authority to change (e.g., MintTokens, FreezeAccount)
new_authority_pubkey: Option<&Pubkey> // The new authority, or None to disable
) -> Instruction
Revoke tiene un efecto idéntico a SetAuthority en que ambos cambian quién posee una autoridad. Revoke borra la delegación de la token account (establece delegate en None), mientras que SetAuthority cambia las autoridades mint/account (MintTokens, FreezeAccount, AccountOwner, CloseAccount).
CloseAccount: Esta instrucción cierra permanentemente una associated token account y reclama su saldo de lamports de SOL que se usó para hacer que la cuenta estuviera exenta de renta. Sin embargo, la ATA debe tener un saldo exactamente de cero del token mint subyacente, de lo contrario se devuelve un error.
pub fn close_account(
account_pubkey: &Pubkey, // The account to close
destination_pubkey: &Pubkey, // The account to receive the reclaimed SOL
owner_pubkey: &Pubkey // The closing account's owner
) -> Instruction
Ahora vamos a discutir las instrucciones clave para el ATA program.
Instrucciones del Associated Token Account (ATA) Program
El ATA program funciona con el Token Program y tiene estas instrucciones principales:
Create: Esta instrucción crea una ATA en una dirección PDA determinista derivada de la combinación de la dirección de una billetera y la dirección mint del token. La instrucción falla si ya existe una cuenta en la dirección derivada.
pub fn create_associated_token_account(
payer: &Pubkey, // The account funding the creation
wallet_address: &Pubkey, // The wallet address for the ATA
token_mint: &Pubkey // The token mint
) -> Instruction
CreateIdempotent: Asegura que la ATA correcta exista en la dirección PDA derivada. Crea la cuenta si es necesario. Pero a diferencia de la instrucción Create, esta tiene éxito sin error incluso si la cuenta correcta ya existe.
pub fn create_associated_token_account_idempotent(
payer: &Pubkey, // The account funding the creation
wallet_address: &Pubkey, // The wallet address for the ATA
token_mint: &Pubkey // The token mint
) -> Instruction
Tanto Create como CreateIdempotent derivan la dirección ATA y luego realizan un CPI a la instrucción InitializeAccount del Token Program (que vimos antes) para configurar la associated token account.
Resumen
Para resumir todo, la arquitectura de tokens SPL de Solana se basa en una separación fundamental de la lógica del programa respecto a los datos de los tokens. En lugar de desplegar un nuevo contrato para cada token como en Ethereum, todos los tokens en Solana son gestionados por el mismo Token Program central.
Aquí están los puntos más importantes a recordar:
- Lógica vs. Estado: El único Token Program contiene todas las reglas (transfer, mint, burn), pero no posee datos de tokens (saldos, decimales, suministro) en sí. Actúa como el motor de lógica universal para todos los tokens SPL.
- La Mint Account es el Token: Una Mint Account define un token único. Almacena la información global del token, como su suministro total, decimales y quién tiene la autoridad para crear más. La dirección de la Mint account es la dirección del token (por ejemplo, la dirección mint de USDC).
- Los Saldos Viven en las Token Accounts/ATAs: Los saldos de los usuarios se mantienen en Token Accounts separadas o Associated Token Accounts (ATAs). En lugar de un gran contrato que asocia direcciones a saldos, cada usuario obtiene una cuenta distinta para cada tipo de token que posee. La dirección para una ATA se deriva de forma predecible de la billetera del usuario y la dirección mint del token, y es la solución recomendada.
Algunas ventajas de la arquitectura SPL
- Procesamiento Paralelo: Debido a que el saldo de cada usuario está en una cuenta separada, la red puede procesar miles de transferencias al mismo tiempo sin que interfieran entre sí.
- Estandarización: Cada token SPL, ya sea una stablecoin o una meme coin, sigue exactamente la misma lógica segura desde el Token Program central. Esto reduce el riesgo de errores que pueden ocurrir con contratos de tokens personalizados.
Este artículo es parte de una serie de tutoriales sobre Solana.