Participaciones en bóvedas ERC-4626: por qué una vista previa no garantiza el depósito

Que previewDeposit devuelva un resultado positivo no significa que una bóveda ERC-4626 vaya a aceptar el depósito. La función estima cuántas participaciones corresponderían a una cantidad de activos en las condiciones actuales, pero deja expresamente fuera de su respuesta los límites de depósito y la existencia de una autorización suficiente para gastar los tokens. Por eso, una vista previa puede mostrar una cifra útil aunque la transacción prevista no esté disponible.

Para interpretar el resultado hay que separar cuatro preguntas: qué contabiliza la bóveda, qué produciría el intercambio, cuánto puede operar ahora una dirección y quién tiene permiso para mover los tokens. La especificación ERC-4626 para bóvedas tokenizadas asigna esas preguntas a métodos distintos. El problema aparece cuando se lee una sola respuesta como si resolviera las cuatro.

Primero, identifica qué contabiliza la bóveda

ERC-4626 estandariza una interfaz para bóvedas con un único token ERC-20 subyacente. Distingue entre el activo, que es ese token subyacente, y la participación, que es el token de la bóveda y representa un derecho proporcional sobre sus tenencias subyacentes. Tener un saldo de participaciones no equivale a tener ese mismo saldo del activo subyacente.

El método asset() identifica el contrato del token subyacente. En cambio, las operaciones ERC-20 de la propia bóveda, como balanceOf y totalSupply, se refieren a participaciones. Antes de interpretar una cantidad, hay que saber qué contrato la proporcionó y si está expresada en activos o en participaciones. Una participación no tiene por qué corresponder a un token subyacente.

totalAssets() informa de la cantidad de activos subyacentes gestionados por la bóveda. Según la especificación, debería incluir la capitalización de los rendimientos y debe incluir las comisiones cobradas contra los activos de la bóveda. Es una cifra contable: por sí sola, no indica cuánto puede retirar inmediatamente un propietario concreto.

Reconocer el nombre de un token no resuelve estas diferencias. La guía de BTC-Pulse sobre cómo identificar el contrato del token y no solo su símbolo explica por qué los nombres mostrados en pantalla son insuficientes. Aquí la comparación es únicamente conceptual: no documenta qué activos admite ERC-4626 ni demuestra compatibilidad con puentes. El punto de partida para una bóveda sigue siendo el resultado real de asset().

Elige la operación según la cantidad que quieras fijar

Los cuatro métodos de intercambio no son nombres alternativos para una misma instrucción. Cada uno fija una cantidad y determina la otra. Las definiciones de deposit, mint, withdraw y redeem establecen las siguientes correspondencias.

Si la instrucción es «aportar esta cantidad de tokens subyacentes», corresponde usar deposit. Si es «obtener este número de participaciones», mint fija esa cantidad de participaciones. Para salir, withdraw especifica los activos subyacentes que se desean recibir, mientras que redeem especifica las participaciones que se quieren quemar. Consultar la vista previa equivocada puede invertir el significado de la cifra mostrada.

También importan los papeles de cada dirección. El destinatario, o receiver, recibe las participaciones recién emitidas al entrar o los activos subyacentes al salir. En las retiradas y los reembolsos, el propietario, u owner, es la dirección cuyas participaciones se queman. Quien realiza la llamada, o caller, puede ser distinto del propietario y del destinatario. Estas diferencias determinan qué dirección debe consultarse para conocer la capacidad y qué autorización exige la ejecución.

Una conversión contable no es una cotización de ejecución

convertToShares y convertToAssets ofrecen conversiones idealizadas. Deben excluir las comisiones, no variar según quién realiza la llamada y no reflejar el deslizamiento ni otras condiciones de la cadena que afecten al intercambio real. Ambos métodos deben redondear hacia abajo. El estándar los describe como estimaciones aproximadas para aplicaciones que necesitan una valoración media, no el resultado de una operación específica.

Las vistas previas responden a una pregunta operativa más concreta. Por ejemplo, previewDeposit estima las participaciones de un depósito e incluye sus comisiones. Compararlo con convertToShares puede mostrar que el resultado de la operación es menos favorable que la conversión idealizada. Sin embargo, no identifica automáticamente la causa exacta: las comisiones, las condiciones relacionadas con el deslizamiento y los detalles de implementación requieren un examen propio.

Esta distinción también evita errores al retirar. Estimar activos a partir de una cantidad de participaciones no demuestra que esos activos estén disponibles en ese momento para su propietario. La conversión expresa un valor en otra unidad; la capacidad indica qué cantidad puede ejecutarse bajo los límites aplicables. Ni una conversión ni el total de activos gestionados sustituyen al máximo correspondiente al propietario concreto.

La vista previa tiene un ámbito temporal preciso

La especificación describe las vistas previas como simulaciones en el bloque actual, dadas las condiciones actuales de la cadena. Hay una precisión fundamental: las comparaciones con las operaciones reales se refieren a llamadas realizadas dentro de la misma transacción. Una cifra que una web consultó antes no reserva ese resultado de intercambio para una transacción posterior.

Dentro de ese ámbito, y para un comportamiento conforme al estándar, deposit debería devolver las mismas participaciones o más que previewDeposit. mint debería exigir los mismos activos o menos que previewMint. withdraw debería quemar las mismas participaciones o menos que previewWithdraw. Y redeem debería entregar los mismos activos o más que previewRedeem. La dirección de cada comparación depende de si la vista previa calcula lo que se recibe o lo que se aporta.

Los requisitos de las vistas previas de cada operación también incluyen las comisiones de depósito o retirada pertinentes. Por eso resultan más útiles para su operación correspondiente que una conversión sin comisiones. Pero no son intercambiables: estimar los activos necesarios para emitir participaciones no equivale a estimar los activos que se recibirían al reembolsarlas.

Las vistas previas omiten deliberadamente sus límites correspondientes. La de depósito presupone que este se acepta incluso sin una autorización suficiente para gastar el token. Del mismo modo, las de salida no acreditan que el propietario tenga suficientes participaciones ni que la operación encaje en la capacidad actual. Estas omisiones facilitan la composición entre protocolos, pero dejan preguntas importantes sin resolver para quien prepara una transacción.

Tampoco está garantizado que una vista previa nunca revierta. No debe hacerlo por los límites específicos de usuario o globales de la bóveda señalados por el estándar, pero puede revertir por otras condiciones que también harían revertir su operación correspondiente. «La vista previa devolvió un valor» y «la transacción tendrá éxito» son afirmaciones diferentes, incluso antes de considerar los cambios entre llamadas separadas.

Comprueba por separado los límites y los permisos

La capacidad de entrada corresponde al destinatario: maxDeposit(receiver) devuelve activos y maxMint(receiver), participaciones. La capacidad de salida corresponde al propietario: maxWithdraw(owner) devuelve activos y maxRedeem(owner), participaciones. Comparar valores expresados en unidades distintas puede dar una falsa impresión de que la operación cabe, o no cabe, dentro del límite.

Estos máximos deben tener en cuenta los límites globales y los específicos del usuario, y no deben sobrestimar la cantidad aceptada; pueden subestimarla cuando sea necesario. Los métodos no deben revertir. Si los depósitos o las retiradas están totalmente deshabilitados, el máximo correspondiente debe ser cero. Ese cero se refiere a una operación y una dirección concretas, no necesariamente a la existencia de un saldo de participaciones.

Los máximos de deposit y mint presuponen que el usuario tiene activos infinitos, en lugar de comprobar su saldo del token subyacente. Un máximo elevado no demuestra que el monedero posea los tokens necesarios ni sustituye la comprobación de permisos. Capacidad, tenencias y autorización son datos distintos para evaluar si la acción prevista es viable.

El estándar exige admitir un flujo de depósito del token subyacente mediante approve/transferFrom. Esa autorización pertenece al contrato del activo. Cuando otra dirección retira o reembolsa por cuenta del propietario, el flujo delegado admitido utiliza, en cambio, autorización sobre las participaciones de ese propietario en la bóveda. La guía sobre aprobaciones de tokens y permisos de gasto ayuda a entender la diferencia: aprobar un gasto cambia el permiso, pero no necesariamente transfiere la propiedad de inmediato.

Por tanto, una autorización de gasto sobre el token subyacente no es el mismo permiso que una autorización sobre las participaciones. Conviene registrar el contrato del token, el propietario y la dirección autorizada a gastar, en lugar de depender de una etiqueta genérica de «aprobado». Tener permiso para actuar tampoco permite eludir los límites de la bóveda: la autorización no anula las restricciones de capacidad.

Un monedero puede presentar varias llamadas como una sola acción. La explicación de BTC-Pulse sobre la autorización programable de los monederos smart contract describe cómo se pueden agrupar la aprobación y el depósito, sin eliminar los riesgos de implementación y permisos. Es una función opcional del monedero, no un requisito de ERC-4626. Una interfaz combinada sigue necesitando distinguir quién llama, quién posee las participaciones, quién recibe los fondos y qué tokens están sujetos al permiso de gasto.

El redondeo importa, pero no existe una fórmula universal

Los contratos terminan calculando cantidades discretas de tokens, por lo que el redondeo importa. La sección de seguridad del estándar favorece a la bóveda cuando una división no es exacta: redondear hacia abajo lo que recibe el usuario y hacia arriba lo que debe aportar. Ese criterio debe distinguirse del requisito explícito de que ambos métodos de conversión redondeen siempre hacia abajo.

Estas direcciones no establecen una fórmula universal entre activos y participaciones. La especificación deja intencionadamente los detalles contables y de asignación a cada implementación. También recomienda reproducir los decimales del token subyacente cuando sea posible, sin garantizar que siempre coincidan. Por eso hay que establecer las unidades antes de comparar enteros sin ajustar o saldos mostrados al usuario.

Las consideraciones de seguridad sobre redondeo y selección de vistas previas advierten expresamente que emitir y reembolsar una misma cantidad de participaciones puede implicar cantidades de activos significativamente distintas. El redondeo puede aportar una diferencia pequeña; las comisiones de entrada o salida pueden generar una mayor. Una vista previa de emisión no demuestra qué devolvería un reembolso posterior, y los métodos de conversión no eliminan esas diferencias.

Cómo analizar un depósito fallido o una salida restringida

Consideremos un supuesto cualitativo, no una bóveda observada: previewDeposit devuelve una cantidad positiva de participaciones, pero maxDeposit para el destinatario previsto devuelve cero. No hay contradicción. La vista previa estima el intercambio sin considerar los límites de depósito; el máximo informa de que ese destinatario no tiene capacidad actual para esa operación.

Un permiso de gasto insuficiente sobre el token subyacente podría ser otro obstáculo, pero la vista previa positiva no lo habría comprobado. Aumentar el permiso no resolvería un máximo de cero. A la inversa, disponer de capacidad no aporta los tokens que falten ni crea autorización para gastarlos. Son ramas distintas del diagnóstico, no formas alternativas de describir una misma comprobación.

El razonamiento también se aplica a la salida. Poseer participaciones y obtener una estimación de activos mediante previewRedeem no demuestra que se pueda salir inmediatamente si maxRedeem(owner) es cero. El estándar señala además que algunas implementaciones exigen una solicitud previa independiente antes de retirar. No establece un procedimiento universal de solicitud, un plazo de espera ni un motivo único para las restricciones.

Antes de considerar otra transacción, una secuencia de consultas de solo lectura permite ordenar la información:

1. Identificar contratos y unidades. Separar el token subyacente del token de participaciones, y los activos de las participaciones.
2. Definir la operación prevista. Determinar si se quiere fijar la cantidad de activos aportados, participaciones emitidas, activos recibidos o participaciones quemadas.
3. Consultar la vista previa correspondiente. Interpretar sus unidades sin olvidar que refleja las condiciones actuales y que la comparación con la ejecución se circunscribe a la misma transacción.
4. Comprobar el máximo correspondiente. Consultar al destinatario previsto para entrar o al propietario para salir, no una dirección conectada elegida sin atender a su función.
5. Separar saldo y autorización de gasto. Establecer qué token debe poseerse y sobre qué token se necesita permiso.
6. Revisar los requisitos de la implementación. Buscar solicitudes previas documentadas u otras condiciones ajenas a la llamada estandarizada.
7. Conservar el registro temporal. No tratar resultados obtenidos bajo condiciones distintas de la cadena como una evaluación sincronizada de ejecución.

La secuencia ayuda a precisar qué pregunta queda pendiente. No demuestra que una bóveda concreta sea solvente, cumpla la normativa o sea segura; un máximo de cero tampoco diagnostica por sí solo insolvencia. Averiguar por qué está restringida la capacidad exige pruebas específicas de la implementación, no inferencias basadas en poseer participaciones o en una cifra de la vista previa.

Lo que la interfaz no puede certificar

Reconocer los nombres de las funciones no es un certificado de seguridad. La especificación advierte de implementaciones maliciosas que se ajustan a la interfaz, pero no a sus requisitos, y recomienda revisar antes de una integración de qué maneras podrían perderse los depósitos de los usuarios. Una interfaz puede exponer los métodos esperados y, aun así, tener un comportamiento inadecuado o inseguro.

El estándar también deja deliberadamente sin especificar cómo se asignan los tokens depositados y cuáles son los detalles contables. Estandariza la interacción de las aplicaciones con las bóvedas, no una estrategia de inversión, una rentabilidad, una garantía del capital o un calendario de salida. Esas propiedades necesitan documentación y análisis de implementación propios; no se deducen de la etiqueta ERC-4626.

Las vistas previas tienen otra limitación: al reflejar las condiciones de la cadena, pueden manipularse y no siempre son oráculos de precios seguros, según advierte la sección de seguridad. Esta permite que los métodos de conversión empleen diseños como medias ponderadas por tiempo. Pero permitir construir un oráculo robusto no certifica que todo método de conversión lo sea. Un valor útil para mostrar en pantalla no es automáticamente adecuado para las decisiones financieras de otro protocolo.

Preguntas frecuentes y una secuencia de interpretación reutilizable

¿Una participación equivale siempre a un token subyacente?

No. Participaciones y activos son unidades contables distintas. Hay que utilizar la conversión o la vista previa específica que corresponda a la pregunta, sin interpretar su resultado como una garantía del capital.

¿Una vista previa que devuelve un resultado demuestra que mi aprobación es suficiente?

No. La vista previa de depósito presupone expresamente la aceptación aunque no exista autorización suficiente sobre el token. Los permisos deben comprobarse aparte para el token pertinente y para quien realiza la llamada.

¿maxDeposit comprueba cuánto tengo?

No. Presupone activos infinitos y no debe basarse en el saldo del token subyacente. Informa de la capacidad del destinatario, no de si el monedero puede financiarla.

¿Puedo sustituir previewRedeem por previewMint?

No. previewMint estima los activos necesarios para obtener participaciones; previewRedeem, los activos recibidos al devolverlas. Las comisiones y el redondeo pueden producir diferencias sustanciales entre ambos resultados.

¿Las participaciones son necesariamente transferibles?

No. Aunque las bóvedas deben implementar participaciones ERC-20, la especificación permite que una bóveda no transferible revierta las llamadas a transfer o transferFrom. La interfaz del token no demuestra que las transferencias estén permitidas sin restricciones.

¿ERC-4626 define la estrategia de inversión?

No. La asignación de activos y los detalles contables dependen de la implementación. Entender la interfaz no sustituye el examen de lo que una bóveda concreta hace con los tokens depositados.

La secuencia de interpretación debe quedar explícita: identidad → unidades → operación → vista previa correspondiente → límites → autorización → límites de la implementación. Si una pantalla solo responde al paso de la vista previa, la siguiente pregunta útil es qué comprobación de capacidad o permisos falta, no si una cifra positiva basta para que el depósito esté disponible.