Skip to main content
Esta página fue traducida automáticamente por IA. La versión en inglés es la fuente autorizada.Ver versión en inglés →
Todo activo tradeable en Solana — incluyendo los activos base y quote de cada pool de Raydium — es un token emitido por uno de dos programas: el programa SPL Token heredado o su sucesor, Token-2022. Son programas separados en direcciones distintas, con esquemas de cuenta e semántica de extensiones diferentes. Raydium soporta ambos, pero no en todas partes: CPMM, CLMM y Farm v6 aceptan mints de Token-2022; AMM v4 no. Entender esta división es esencial antes de integrar con cualquier pool.

Los dos programas

Ambos son mantenidos por el equipo de Solana Labs (ahora Anza) y se encuentran bajo el repositorio solana-program-library.

¿Por qué dos programas?

SPL Token fue congelado para compatibilidad hacia adelante — su bytecode es efectivamente inmutable, proporcionando una línea base limpia para todo el ecosistema. Conforme los casos de uso crecieron (stablecoins queriendo comisiones de transferencia, mints institucionales necesitando autoridades de congelación con más control, NFTs necesitando punteros de metadatos), el equipo de Solana introdujo Token-2022 como un programa separado y extensible en lugar de actualizar SPL Token. Esto preserva las integraciones existentes y permite que cada mint se adhiera exactamente a las extensiones que necesita. Token-2022 es un superconjunto estricto en funcionalidad, no en espacio de direcciones: los dos programas coexisten, y un mint en una dirección dada pertenece exactamente a uno de ellos.

Estructura de cuenta

Cuenta de mint

Define la identidad de un token. Mint de SPL Token (82 bytes):
Mint de Token-2022: mismo esquema base, más cero o más registros extensión TLV (type-length-value) agregados después de la base.

Cuenta de token

Contiene un saldo de un mint específico para un propietario específico. Cuenta de SPL Token (165 bytes):
Cuenta de Token-2022: misma base, más registros de extensión TLV si hay extensiones activas.

Extensiones de Token-2022

Las extensiones son características modulares que pueden adjuntarse a mints o cuentas. Cada extensión es un registro TLV separado. Las principales para Raydium:

Comisión de transferencia

El mint puede cobrar una comisión de porcentaje en cada transferencia. La comisión va a una autoridad de retiro configurada. Soportada por Raydium CPMM y CLMM vía SwapV2 — el programa contabiliza la comisión al calcular los tipos de cambio, así que la matemática del pool se mantiene coherente.

Hook de transferencia

El mint apunta a un programa que el runtime invoca en cada transferencia. El programa hook puede rechazar la transferencia o ejecutar efectos secundarios (actualizar un estado de cumplimiento, registrar, etc.). Raydium CPMM/CLMM invoca el hook vía SwapV2 — la transacción incluye el programa hook y cualquier cuenta extra que necesite.

Con interés

El saldo on-chain acumula interés a una tasa configurada. Solo para visualización (los saldos aparecen más altos con el tiempo) en lugar de un mint real; el suministro subyacente no cambia.

Autoridad de cierre de mint

Permite que el mint se cierre una vez que el suministro llega a cero.

Delegado permanente

Una billetera designada puede transferir o quemar tokens de cualquier cuenta incondicionalmente. Raydium bloquea la creación de pools para mints con esta extensión — es incompatible con el invariante de que las reservas del pool no pueden ser incautadas.

No transferible

Los tokens no pueden ser movidos de la cuenta en la que se acuñaron. Raydium bloquea la creación de pools — un activo no tradeable no puede ser base o quote de un pool LP.

Estado de cuenta predeterminado

Las nuevas cuentas de token para este mint están congeladas por defecto y deben ser descongeladas por la autoridad de congelación. Usable pero raro.

Transferencia confidencial

Los saldos y montos de transferencia están encriptados. Raydium no soporta mints de transferencia confidencial (la matemática del pool requiere saldos en texto claro).

Puntero de metadatos + metadatos de token

Reemplaza los metadatos de Metaplex para mints de Token-2022. Soportado para listados de pools de Raydium.

Puntero de grupo / miembro

Declara un mint como perteneciente a un grupo (por ejemplo, una colección NFT). Informativo; Raydium lo usa para visualización. Consulta la página oficial de extensiones de Token-2022 para la lista completa.

Qué productos de Raydium soportan qué

Elegibilidad de mint para pools de Raydium — todas las extensiones permitidas a menos que se listen:
  • Bloqueadas: no transferible, delegado permanente, transferencia confidencial, estado de cuenta predeterminado (en configuraciones rechazadas).
  • Permitidas con advertencias (LP debe aceptar el riesgo): comisión de transferencia, hook de transferencia, autoridad de congelación activa.
  • Completamente permitidas: con interés, puntero de metadatos, puntero de grupo, autoridad de cierre de mint.
La respuesta de getPoolInfoFromRpc incluye los indicadores de extensión del mint — los clientes deben verificar antes de hacer LP.

Estándares de cuenta de token

Cuenta de Token Asociada (ATA)

Ambos programas comparten la convención de Cuenta de Token Asociada: una PDA derivada de [owner, programId, mint] vía el Programa de Token Asociado (ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL). Casi toda cuenta de token de usuario en Solana es una ATA.
El programa ATA crea cuentas propiedad del programa de token apropiado basado en qué programa posee el mint.

Cuentas de token que no son ATA

Una billetera puede tener múltiples cuentas de token para un solo mint; ATA es solo la convención. Los vaults del pool, por ejemplo, no son ATAs — son PDAs del programa del pool, manteniendo las reservas del pool.

Detectar a qué programa pertenece un mint

Toda cuenta de mint tiene un campo owner apuntando a SPL Token o Token-2022:
El SDK de Raydium maneja esta detección automáticamente — getPoolInfoFromRpc retorna el programId apropiado por token para que los clientes puedan construir ATAs correctas.

Instrucciones de swap por programa

El CPMM y CLMM de Raydium cada uno tienen dos instrucciones de swap: SwapV2 toma cuentas adicionales: cuentas de mint para ambos lados, el programa de token para cada lado (ya que pueden diferir), y — para mints con transfer-hook — el programa hook y sus cuentas requeridas. Los clientes siempre deben usar SwapV2 cuando al menos un lado es Token-2022; SwapV2 también funciona para pools solo de SPL, pero el Swap heredado es más barato en cómputo. El SDK elige la variante correcta automáticamente.

Migrar un proyecto de SPL Token a Token-2022

Token-2022 no es un reemplazo directo a nivel de mint — un mint en la dirección X es SPL o Token-2022, y eso es fijo en la creación. Para “migrar” debes:
  1. Crear un nuevo mint bajo Token-2022 con las extensiones que quieras.
  2. Proporcionar un mecanismo de swap/envoltorio para que los tenedores del antiguo mint de SPL intercambien por uno nuevo.
  3. Actualizar todos los pools LP, farms e integraciones para referenciar el nuevo mint.
Esto es pesado. La mayoría de proyectos lanzados bajo SPL se mantienen bajo SPL a menos que una necesidad específica de extensión fuerce el cambio.

Ejemplo trabajado: crear un mint de Token-2022 con comisión de transferencia

Este mint puede ser usado como LP en un pool CPMM de Raydium; los intercambiadores pagarán la comisión de transferencia del 0.5% además de la comisión de swap del pool.

Consideraciones de seguridad

Antes de hacer LP o intercambiar a través de un mint de Token-2022:
  • Verifica freeze_authority. Si no es nulo y es mantenido por una parte centralizada, puede congelar tu ATA (y cuestionablemente el vault del pool).
  • Verifica transfer_hook. El programa hook puede bloquear transferencias arbitrariamente — haz tu propia diligencia en la fuente del hook.
  • Verifica transfer_fee. Contabiliza la comisión en la salida de swap esperada.
  • Verifica permanent_delegate y non_transferable. El programa de Raydium rechaza estos, pero verifica si construyes una integración personalizada.
Consulta security/oracle-and-token-risks para el marco completo de aceptación de riesgo.

Referencias

Fuentes: