FT schreibt zwar ERC-20, aber das bedeutet nicht, dass es wie ein gewöhnliches ERC-20 behandelt werden und direkt angebunden werden kann. Als ich mir die Token-Beschreibung von TermMax erneut ansah, fiel mir zuerst nicht auf, ob man es transferieren kann, sondern dass sein Wert zwei Zeitpunkte hat: vor Ablauf kann man handeln, nach Ablauf wird es zum Nennwert in Schuld-Token eingelöst. Es wirkt wie eine Nullkupon-Anleihe, die jedoch eine vertraute Token-Schnittstelle verwendet. Für Entwickler liegt die Schwierigkeit nicht darin, balanceOf aufzurufen, sondern darin, den Kontostand nicht einfach mit dem aktuell einlösbaren Betrag gleichzusetzen.
Ein Beispiel: In der Wallet eines Nutzers befinden sich 100 FT. Die Seite zeigt nur die Zahl „100“ an, wodurch es leicht wirkt, als könne man jetzt sofort 100 Schuld-Token zurückbekommen. Doch vor dem Ablauf wird der Marktpreis der FT je nach verbleibender Laufzeit und den Anforderungen an die Kapitalrendite schwanken. Der sofortige Ausstiegswert von 100 FT entspricht nicht unbedingt dem Nennwert. Wenn der Integrator lediglich die Menge ausliest, aber nicht das Fälligkeitsdatum, den Nennwert und den Verkaufspreis anzeigt, sieht der Nutzer nur eine Zahl, während er tatsächlich eine zeitlich bedingte Forderung hält. Das ist kein bloßes Problem der Frontend-Textierung: Kredit-Aggregatoren, Wallet-Bewertungs- oder Beleihungs-Module könnten FT fälschlicherweise als stabilen Kontostand einstufen und dadurch die verfügbaren Vermögenswerte des Nutzers überschätzen. Umgekehrt kann eine reine Bewertung zum Marktabschlag die erwartete Einlöseleistung zum Laufzeitende unterschätzen. Beide Arten von Fehlern werden am Ende von den Personen getragen, die das integrierte Produkt nutzen.
Ich würde @TermMax FT so verstehen, dass es sich um ein zeitgebundenes Asset mit einem ERC-20-„Außenmantel“ handelt. Wenn die TMX-Ökologie mehr Wallets und Handelswerkzeuge anbinden möchte, sollte nicht zuerst die Kompatibilität der Schnittstelle bewiesen werden, sondern ob der Integrator in der Lage ist, gleichzeitig die FT-Menge, das Fälligkeitsdatum, den Nennwert und den Marktpreis darzustellen. Fehlt ein Feld, könnte der Nutzer die Forderung leicht als Bargeld missverstehen. #TermMax
Ein Beispiel: In der Wallet eines Nutzers befinden sich 100 FT. Die Seite zeigt nur die Zahl „100“ an, wodurch es leicht wirkt, als könne man jetzt sofort 100 Schuld-Token zurückbekommen. Doch vor dem Ablauf wird der Marktpreis der FT je nach verbleibender Laufzeit und den Anforderungen an die Kapitalrendite schwanken. Der sofortige Ausstiegswert von 100 FT entspricht nicht unbedingt dem Nennwert. Wenn der Integrator lediglich die Menge ausliest, aber nicht das Fälligkeitsdatum, den Nennwert und den Verkaufspreis anzeigt, sieht der Nutzer nur eine Zahl, während er tatsächlich eine zeitlich bedingte Forderung hält. Das ist kein bloßes Problem der Frontend-Textierung: Kredit-Aggregatoren, Wallet-Bewertungs- oder Beleihungs-Module könnten FT fälschlicherweise als stabilen Kontostand einstufen und dadurch die verfügbaren Vermögenswerte des Nutzers überschätzen. Umgekehrt kann eine reine Bewertung zum Marktabschlag die erwartete Einlöseleistung zum Laufzeitende unterschätzen. Beide Arten von Fehlern werden am Ende von den Personen getragen, die das integrierte Produkt nutzen.
Ich würde @TermMax FT so verstehen, dass es sich um ein zeitgebundenes Asset mit einem ERC-20-„Außenmantel“ handelt. Wenn die TMX-Ökologie mehr Wallets und Handelswerkzeuge anbinden möchte, sollte nicht zuerst die Kompatibilität der Schnittstelle bewiesen werden, sondern ob der Integrator in der Lage ist, gleichzeitig die FT-Menge, das Fälligkeitsdatum, den Nennwert und den Marktpreis darzustellen. Fehlt ein Feld, könnte der Nutzer die Forderung leicht als Bargeld missverstehen. #TermMax