FT dice “ERC-20”, pero eso no significa que pueda tratarse como un ERC-20 común para integrarlo. Cuando volví a revisar la documentación del Token de TermMax, lo primero que noté no fue si puede transferirse, sino que su valor tiene dos momentos en el tiempo: antes del vencimiento se puede negociar, y después del vencimiento se canjea la deuda por su valor nominal. Es como un bono sin cupón, pero envuelto en una interfaz de token familiar. Para los desarrolladores, el problema no es llamar a balanceOf, sino no poder equiparar directamente el saldo con el importe canjeable vigente.
Por ejemplo: si en la cartera del usuario hay 100 FT, la página solo muestra “100” como un número; es fácil pensar que ahora mismo se pueden recuperar esos 100 tokens de deuda. Pero antes del vencimiento, el precio de mercado de los FT cambiará con el tiempo restante y las exigencias de retorno del capital; así que el valor de salida inmediata de 100 FT no necesariamente equivale al valor nominal. Si la parte integradora solo lee la cantidad pero no muestra la fecha de vencimiento, el valor nominal y el precio de transacción, el usuario verá un número, aunque en realidad posea un derecho de cobro sujeto a condiciones temporales. Esto no es un problema menor de copy para frontend: agregadores de préstamos, la valoración de carteras o módulos de colateral podrían sobreestimar los activos disponibles si tratan los FT como un saldo estable; pero si solo se calculan con un descuento de mercado, también podrían subestimar el valor de canje al vencimiento. En ambos casos, los errores los asumirá quien use el producto integrado.
Voy a entender los FT de @TermMax como un activo con vencimiento que porta un “envoltorio” de ERC-20. Si el ecosistema TMX quiere integrarse con más carteras y herramientas de trading, lo primero que debería demostrar no es la compatibilidad del interfaz, sino si la parte integradora puede mostrar simultáneamente la cantidad de FT, la fecha de vencimiento, el valor nominal y el precio de mercado. Si falta un campo, el usuario podría interpretar mal el derecho de cobro como efectivo.#TermMax
Por ejemplo: si en la cartera del usuario hay 100 FT, la página solo muestra “100” como un número; es fácil pensar que ahora mismo se pueden recuperar esos 100 tokens de deuda. Pero antes del vencimiento, el precio de mercado de los FT cambiará con el tiempo restante y las exigencias de retorno del capital; así que el valor de salida inmediata de 100 FT no necesariamente equivale al valor nominal. Si la parte integradora solo lee la cantidad pero no muestra la fecha de vencimiento, el valor nominal y el precio de transacción, el usuario verá un número, aunque en realidad posea un derecho de cobro sujeto a condiciones temporales. Esto no es un problema menor de copy para frontend: agregadores de préstamos, la valoración de carteras o módulos de colateral podrían sobreestimar los activos disponibles si tratan los FT como un saldo estable; pero si solo se calculan con un descuento de mercado, también podrían subestimar el valor de canje al vencimiento. En ambos casos, los errores los asumirá quien use el producto integrado.
Voy a entender los FT de @TermMax como un activo con vencimiento que porta un “envoltorio” de ERC-20. Si el ecosistema TMX quiere integrarse con más carteras y herramientas de trading, lo primero que debería demostrar no es la compatibilidad del interfaz, sino si la parte integradora puede mostrar simultáneamente la cantidad de FT, la fecha de vencimiento, el valor nominal y el precio de mercado. Si falta un campo, el usuario podría interpretar mal el derecho de cobro como efectivo.#TermMax