FT diz “ERC-20”, mas isso não significa que ele possa ser tratado como um ERC-20 comum para ser integrado. Ao reler as informações de Tokens da TermMax, a primeira coisa que notei não foi se ele pode ser transferido, e sim que o seu valor tem dois momentos no tempo: antes do vencimento, ele pode ser negociado; após o vencimento, é resgatado pelo valor nominal para converter em tokens de dívida. Ele é como um título sem cupom, mas com uma interface de token familiar — para os desenvolvedores, a dificuldade não está em chamar o balanceOf, e sim em não conseguir equiparar diretamente o saldo ao montante atual que pode ser resgatado.
Por exemplo, se o usuário tem 100 FT na carteira, a página mostra apenas o número “100”. Isso faz parecer que já é possível sacar 100 tokens de dívida. Mas antes do vencimento, o preço de mercado do FT varia de acordo com o prazo restante e com as exigências de retorno do capital. Assim, o valor de saída instantânea de 100 FT não necessariamente equivale ao valor nominal. Se o integrador apenas ler a quantidade e não exibir a data de vencimento, o valor nominal e o preço de negociação, o usuário verá números, mas na prática estará com uma dívida que depende do tempo. Isso não é um problema meramente de copy de front-end: agregadores de empréstimos, avaliações de carteiras ou módulos de colateral, se tratarem o FT como saldo estável, podem superestimar os ativos disponíveis do usuário. Por outro lado, se calcularem apenas com desconto de mercado, podem subestimar o valor de resgate na data do vencimento. Em ambos os casos, os erros serão arcados pelas pessoas que usam o produto integrado.
Eu vou entender @TermMax de FT como um ativo com prazo, revestido por um “shell” compatível com ERC-20. Se o ecossistema TMX quiser integrar mais carteiras e ferramentas de negociação, a primeira coisa que precisa ser provada não é apenas a compatibilidade de interface, e sim se o integrador consegue exibir simultaneamente a quantidade de FT, a data de vencimento, o valor nominal e o preço de mercado. Se faltar um campo, o usuário pode interpretar a dívida como se fosse dinheiro. #TermMax
Por exemplo, se o usuário tem 100 FT na carteira, a página mostra apenas o número “100”. Isso faz parecer que já é possível sacar 100 tokens de dívida. Mas antes do vencimento, o preço de mercado do FT varia de acordo com o prazo restante e com as exigências de retorno do capital. Assim, o valor de saída instantânea de 100 FT não necessariamente equivale ao valor nominal. Se o integrador apenas ler a quantidade e não exibir a data de vencimento, o valor nominal e o preço de negociação, o usuário verá números, mas na prática estará com uma dívida que depende do tempo. Isso não é um problema meramente de copy de front-end: agregadores de empréstimos, avaliações de carteiras ou módulos de colateral, se tratarem o FT como saldo estável, podem superestimar os ativos disponíveis do usuário. Por outro lado, se calcularem apenas com desconto de mercado, podem subestimar o valor de resgate na data do vencimento. Em ambos os casos, os erros serão arcados pelas pessoas que usam o produto integrado.
Eu vou entender @TermMax de FT como um ativo com prazo, revestido por um “shell” compatível com ERC-20. Se o ecossistema TMX quiser integrar mais carteiras e ferramentas de negociação, a primeira coisa que precisa ser provada não é apenas a compatibilidade de interface, e sim se o integrador consegue exibir simultaneamente a quantidade de FT, a data de vencimento, o valor nominal e o preço de mercado. Se faltar um campo, o usuário pode interpretar a dívida como se fosse dinheiro. #TermMax