Busca en todas las páginas de la documentación
Las integraciones DeFi en Solana son patrones para componer liquidez, crédito, recibos de stake, precios y derivados a través de listas explícitas de cuentas y invocaciones entre programas (CPIs). Una vez que mapeas AMMs, enrutamiento de Jupiter, préstamos, LSTs, oráculos, perps y Jito/MEV como un gráfico de composabilidad, el diseño del producto se convierte en "qué programas, qué cuentas, qué modos de fallo", no en un montón de SDKs no relacionados.
Conceptos básicos de DeFi en Solana es la entrada práctica; AMMs (Raydium, Orca, Meteora), Préstamos y Empréstitos, Staking Líquido (LSTs), Oráculos y Jito y MEV se centran en una superficie cada uno. Esta página se sitúa debajo: cómo encaja la pila de DeFi para los desarrolladores.
Solana no distribuye una única "Máquina Virtual de DeFi". Distribuye un entorno de ejecución que mueve lamports y bytes propiedad del programa bajo reglas de escritura del propietario, más programas que interpretan esos bytes como pools, bancos, recibos de stake y libros de órdenes. La integración significa hablar correctamente los diseños de instrucciones y los gráficos de cuentas de esos programas.
Cada saldo duradero sigue siendo una cuenta de token SPL (o SOL nativo / envuelto). Las posiciones de DeFi añaden más cuentas: bóvedas de pools, PDAs de obligaciones, acuñaciones de LST, cuentas de margen, feeds de oráculo. Los clientes y programas deben declararlos para que Sealevel pueda bloquearlos y las CPI puedan pasarlos por la pila.
Piensa en el mapa del desarrollador como capas desde la intención del usuario hasta la inclusión:
Intención del usuario (swap, prestar, apalancar, cubrir)
|
v
+--------------------------------------+
| Agregadores / enrutadores (ej. Jupiter) | plan de ruta opcional fuera de cadena
+--------------------------------------+
| Programas de lugar: AMM / CLOB / perps / |
| préstamos / pools de stake | estado en cadena + CPI
+--------------------------------------+
| Oráculos (Pyth, Switchboard, ...) | entradas de precio y riesgo
+--------------------------------------+
| Programa de Tokens + ATAs / bóvedas | custodia de saldos
+--------------------------------------+
| Inclusión: tarifas de prioridad, propinas Jito | aterrizaje bajo contención
+--------------------------------------+Los AMMs (Raydium, Orca, Meteora y similares) mantienen reservas o liquidez concentrada y fijan precios de swaps por curva o matemáticas de ticks. Jupiter se sitúa por encima de muchos de ellos: cotiza fuera de cadena y devuelve una ruta para que no mantengas cada gráfico de pool. Los préstamos (Kamino, MarginFi y similares) mapean colateral y deuda a salud y liquidaciones. Los LSTs (jitoSOL, mSOL y similares; a menudo enrutamiento estilo Sanctum) envuelven SOL stakeado en reclamaciones fungibles para colateral y bucles. Los oráculos publican cuentas de precios que tratas como entradas con límite de tiempo. Los Perps y libros de órdenes añaden posiciones, emparejamiento y reglas de marca/financiación. Las rutas Jito y MEV deciden si el flujo de múltiples tramos aterriza atómicamente y quién captura el valor de sandwich o arb.
La regla: tu producto posee la composición. Cada tramo es una CPI validada o una lista de instrucciones construida por el cliente; la atomicidad es que una transacción tiene éxito o ninguna lo hace hasta que deliberadamente haces múltiples transacciones y aceptas estado parcial.
Antes de cualquier swap o depósito, resuelve las acuñaciones, decimales y ATAs para el usuario y los saltos intermedios. Las ATAs faltantes son un error común de "funciona en pruebas, falla en la wallet". El envoltorio/desenvoltorio de SOL es de primera clase; trata wSOL como una acuñación con creación/cierre, no como lamports flotantes dentro de cada pool.
Wallet (propiedad del sistema)
|
+--> ATA(mint_in) --transferencia/CPI--> bóvedas de pool/usuario
+--> ATA(mint_out) <--recepción------- programa del lugarEl trabajo directo con AMM se ajusta a depósito/retiro de LP, enrutamiento personalizado o swaps CPI en cadena sin un agregador. Valida el ID del programa, las acuñaciones del pool y las direcciones de las bóvedas antes de la CPI de transferencia. Ver AMMs (Raydium, Orca, Meteora).
La intuición del producto constante ayuda, pero la liquidez de producción es a menudo concentrada o dinámica. Actualiza el estado del pool en el momento de la compilación y aplica el deslizamiento (mínimo de salida / máximo de entrada).
Swaps con Jupiter es la ruta de producto predeterminada: cotizar → tx de swap → firmar con @solana/kit. Los deberes siguen siendo: fijar bps de deslizamiento, manejar el envoltorio de SOL, simular, volver a cotizar en caso de fallo. No codifiques rutas fijas para siempre; la liquidez migra.
Usa Jupiter para el mejor precio y bajo mantenimiento. Usa CPIs directas de AMM cuando tu programa deba controlar la ruta, la custodia o el recorte de tarifas dentro de una pila.
Los mercados de dinero convierten los depósitos en suministro y permiten préstamos bajo un factor de salud: deposita colateral, opcionalmente presta, monitoriza la salud y diseña para liquidadores. Los bucles de apalancamiento son préstamos + AMM/Jupiter, no una característica de cadena separada. Planifica la dependencia del oráculo y los picos de utilización. Detalles: Préstamos y Empréstitos.
Un LST es generalmente una acuñación SPL cuya tasa sigue al SOL stakeado (menos las tarifas del proveedor). Eso desbloquea colateral y una salida más rápida del mercado, además de riesgo de contrato, liquidez y desvinculación. Superficies: acuñar/canjear, swaps de LST, colateral con recortes de oráculo. Ver Staking Líquido (LSTs).
Cualquier préstamo, liquidación o financiación que dependa del valor en USD debe leer un feed de precios, aplicar edad máxima, confianza y ID de feed correcto. Pyth y Switchboard aún requieren comprobaciones de cierre por fallo en cuentas obsoletas o incorrectas.
acción de riesgo --> cargar feed --> ¿edad/conf OK? --> convertir unidades --> LTV o min-salida
|
cierre por fallo si está obsoleto o feed incorrectoNo uses el precio spot del último swap del pool solo como oráculo de riesgo para crédito con garantía insuficiente. Ver Oráculos.
Los CLOBs y perps optimizan para prioridad de precio-tiempo, límites y apalancamiento. Los gráficos de cuentas crecen (mercado, órdenes, posiciones, bóvedas). Los llenados parciales difieren de los swaps de precio único de AMM. Prefiérelos cuando la experiencia de límite o los modelos de derivados superen los swaps de curva. Ver Perps y Libros de Órdenes.
Las DeFi de múltiples tramos compiten en inclusión y ordenación. Las tarifas de prioridad pujan a través del precio de la unidad de cómputo. Los bundles y propinas de Jito son una ruta paralela a través de los motores de bloques.
Ruta A: tx única + precio de CU --> calendario del líder público
Ruta B: bundle + propina --> motor de bloques --> líderAcota el deslizamiento, considera bundles para flujo tóxico y no confundas propinas con tarifas de prioridad del Presupuesto de Cómputo. Ver Jito y MEV.
Ejemplo: exposición apalancada a LST.
El plano está completo cuando puedes nombrar el programa por tramo, las cuentas escribibles, las puertas de oráculo y cómo se compra la inclusión.
Los fallos de DeFi en producción son menos por álgebra que por gráficos de cuentas, versionado y contención. Adapta la profundidad a la superficie.
| Ruta | Qué integras | Fortalezas | Debilidades | Mejor ajuste |
|---|---|---|---|---|
| Swaps solo con Jupiter | API de cotización/swap + kit | Envío rápido; multi-lugar | Dependencia fuera de cadena | Wallets, rebalanceo |
| CPI directa de AMM | Cuentas de pool + ix | Control en cadena; LP | Rotación de diseño | Bóvedas, enrutadores personalizados |
| Préstamos + oráculo | Bancos, obligaciones, feeds | Crédito y apalancamiento | Riesgo de liquidación / pausa | Mercados de dinero, bucles |
| Pila de colateral LST | Pools + préstamos + oráculos | Colateral que genera rendimiento | Riesgo de desvinculación, proveedor | Tesorería y bucles |
| Perps / CLOB | Mercado + posiciones | Límites; derivados | Latencia y costo operativo | Lugares de trading, coberturas |
| Aterrizaje consciente de MEV | Propinas, bundles, tarifas | Mejores tasas de aterrizaje atómico | Infraestructura adicional | Liquidadores, arbs, tamaño |
Los límites de CU y cuentas limitan los saltos por transacción. Divide solo con recuperación: si el tramo 1 aterriza y el tramo 2 falla, la experiencia del usuario debe manejar el estado parcial.
Las actualizaciones de programas cambian discriminadores y cuentas restantes. Fija versiones de IDL/SDK y prueba transacciones principales en producción con fixtures a través de las actualizaciones.
Las cuentas activas serializan escritores bajo carga. Las tarifas, propinas, simulación y hashes de bloques frescos son parte de la integración DeFi, no solo de la "infraestructura".
Seguridad para integradores: verifica los IDs de programas externos, restringe las cuentas de oráculo/pool proporcionadas por el cliente, aplica deslizamiento y salud en cadena cuando hagas CPI, y documenta las autoridades de pausa/actualización del lugar.
Para revisiones de diseño: intención → gráfico de instrucciones, custodia por acuñación, política de oráculo, límites de deslizamiento/salud, estrategia de aterrizaje y qué artículo hermano posee la inmersión profunda.
Componer programas externos a través de cuentas explícitas y CPIs (o listas de instrucciones creadas por el cliente), y tratar los oráculos, el deslizamiento, la salud y la inclusión como requisitos de producto de primera clase, no como ocurrencias tardías.
Usa Jupiter para swaps de usuario al mejor precio y rebalanceos simples sin mantener gráficos de pools. Usa rutas directas de AMM para gestión de LP, CPI en cadena estrictamente controlada o características específicas del lugar que los agregadores no exponen.
Cuentas de tokens de usuario (entrada/salida), ATAs intermedias si son multi-salto, cuentas de pool o ruta, Programa de Tokens, a veces Programa del Sistema para crear ATA o envolver SOL, y cuentas de presupuesto de cómputo para tarifas.
Son programas separados. Las estrategias de apalancamiento y bóveda a menudo hacen CPI o secuencian ambos: pedir prestado de un mercado de dinero, intercambiar en un AMM o a través de Jupiter, luego depositar de nuevo.
Convierten SOL stakeado en un saldo SPL transferible que los mercados aceptan como colateral o liquidez, permitiendo bucles que generan rendimiento sin la experiencia de cuenta de stake nativa en cada salto.
Cuenta de feed correcta, límite de edad del precio, comprobaciones de confianza o estado, y conversión de unidades (exponente, decimales) antes de cualquier cálculo sensible al riesgo.
Los CLOBs usan cuentas de órdenes y posiciones con semántica de colocar/cancelar/emparejar y a menudo requisitos de latencia más estrictos; los AMMs generalmente fijan precios a partir del estado del pool en una única instrucción de estilo swap.
Cuando las estrategias atómicas de múltiples transacciones, liquidaciones o flujos sensibles a órdenes de alto valor necesitan mejor inclusión y ordenación que las tarifas de prioridad del mempool público por sí solas.
Muchos productos construyen transacciones de Jupiter fuera de cadena con kit. La CPI de agregador puramente en cadena es especializada y sensible a la versión; prefiere interfaces de lugar conocidas cuando debas hacer CPI desde un programa.
Cotizaciones obsoletas, CU insuficientes, cuentas escribibles faltantes, contención de cuentas activas y tarifas o propinas infravaloradas, más a menudo que errores matemáticos puros.
Decide la política de envoltorio de antemano. Muchos lugares quieren ATAs de wSOL: crea, financia, usa y cierra cuentas temporales para que los usuarios no se queden con polvo o transferencias fallidas.
La proporción del protocolo de colateral con recorte, valorado por oráculo, frente a la deuda; por debajo del umbral la posición es liquidable.
RPC y kit son suficientes para saldos actuales y transacciones únicas. El historial, PnL, escáneres de liquidadores y métricas de operaciones requieren eventos indexados analizados.
Fija SDKs/IDLs, prueba transacciones reales con fixtures, limita los cambios en las cuentas restantes detrás de las versiones del cliente y vigila las autoridades de actualización de las que dependes.
Nombra las acuñaciones y ATAs, nombra los IDs de programas externos, define la política de oráculo y deslizamiento/salud, simula transacciones completas, establece la estrategia de CU y tarifas/propinas, documenta la recuperación de fallos parciales y asume la respuesta a las actualizaciones del lugar.
Versiones de la pila: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1, y @solana/kit 7.0.0.
Revisado por Chris St. John·Última actualización: 15 jul 2026