@BabylonLabs_io zerlegt eine vollständige Rückzahlung in drei Zeilen und man erkennt: Die Zahlen, die sich im Wallet sehr ähnlich sind, können komplett unterschiedliche Konsequenzen haben.
Die erste Zeile ist „spending-cap“.
Dort steht, wie oft ein Vertrag maximal aufgerufen werden kann. Der für TBV-relevante Verträge gesetzte Grenzwert liegt höher als die tatsächliche Schuld. Das Mehr ist nur ein Spielraum bei den Berechtigungen – es wird nicht automatisch zu einem zusätzlichen Abzug, nur weil die Zahl in der Darstellung „weit“ ist.
Die zweite Zeile ist, wie viel dieses Mal tatsächlich zurückgezahlt wurde.
Während der Nutzer die Schuld ausliest, eine Transaktion vorbereitet und auf die Bestätigung wartet, kann sich die Schuld weiter verändern. Wenn der eingereichte Rückzahlungsbetrag unter der tatsächlichen Schuld zum Zeitpunkt der Bestätigung liegt, kann der Vertrag die Schuld nur um den empfangenen Betrag reduzieren. Die Transaktion kann erfolgreich sein – die Differenz kann weiterhin in der Position hängen bleiben; „Ausführung erfolgreich“ und „Schuld auf null“ sind nicht dasselbe Ergebnis.
Die dritte Zeile ist erst danach die verbleibende Schuld.
Diese Zeile ist die ruhigste, die Folgen sind jedoch am härtesten. Ein zu hoher „spending-cap“ lässt ungenutzte Aufrufberechtigungen übrig; eine zu geringe tatsächliche Rückzahlung lässt einen Restbetrag zurück, der noch ausgeglichen werden muss. Beide Seiten heißen zwar „es gibt eine kleine Abweichung vom Ziel“, aber wenn man die Richtung vertauscht, wechselt das Ergebnis von „nicht zu viel abgezogen“ zu „nicht vollständig zurückgezahlt“.
Nehmen wir $BABY als Beispiel für den aktuellen öffentlichen Testablauf: Autorisierung, tatsächlicher Abzug und der Schuldensaldo tauchen innerhalb einer einzigen Aktion nacheinander auf – man nimmt sie daher leicht für drei Versionen derselben Zahl. Der Vertrag interpretiert sie jedoch dreimal getrennt: erst, ob die Berechtigung ausreicht, dann, wie viel die Transaktion tatsächlich liefert, und zuletzt, wie die Schuld aktualisiert wird. Er behandelt nicht den nicht abgedeckten Teil automatisch als „nicht vorhanden“, nur weil der Nutzer subjektiv auf „alles“ geklickt hat.
Diese Kredit-/Leih-Assets sind derzeit allesamt mock-Assets ohne echten Wert. Die drei Zeilen können nur das Mechanismusverständnis erklären; um damit reale Verluste zu „verkalkulieren“, gibt es keine Grundlage. Einen festen Buffer gibt es auch nicht – sobald sich die Bestätigungszeit ändert, können sich die Zahlen entsprechend ändern. Zu prüfen ist also nicht, wie groß die Autorisierung im Wallet irgendwann einmal angezeigt wurde, sondern wie viel nach dem tatsächlichen Ablauf in der dritten Zeile am Ende wirklich noch übrig ist.
Genau hier liegt der Unterschied. Die überschüssige Autorisierung bleibt am Eingang stehen, die zu geringe Rückzahlung bleibt auf dem Konto.
#baby
Die erste Zeile ist „spending-cap“.
Dort steht, wie oft ein Vertrag maximal aufgerufen werden kann. Der für TBV-relevante Verträge gesetzte Grenzwert liegt höher als die tatsächliche Schuld. Das Mehr ist nur ein Spielraum bei den Berechtigungen – es wird nicht automatisch zu einem zusätzlichen Abzug, nur weil die Zahl in der Darstellung „weit“ ist.
Die zweite Zeile ist, wie viel dieses Mal tatsächlich zurückgezahlt wurde.
Während der Nutzer die Schuld ausliest, eine Transaktion vorbereitet und auf die Bestätigung wartet, kann sich die Schuld weiter verändern. Wenn der eingereichte Rückzahlungsbetrag unter der tatsächlichen Schuld zum Zeitpunkt der Bestätigung liegt, kann der Vertrag die Schuld nur um den empfangenen Betrag reduzieren. Die Transaktion kann erfolgreich sein – die Differenz kann weiterhin in der Position hängen bleiben; „Ausführung erfolgreich“ und „Schuld auf null“ sind nicht dasselbe Ergebnis.
Die dritte Zeile ist erst danach die verbleibende Schuld.
Diese Zeile ist die ruhigste, die Folgen sind jedoch am härtesten. Ein zu hoher „spending-cap“ lässt ungenutzte Aufrufberechtigungen übrig; eine zu geringe tatsächliche Rückzahlung lässt einen Restbetrag zurück, der noch ausgeglichen werden muss. Beide Seiten heißen zwar „es gibt eine kleine Abweichung vom Ziel“, aber wenn man die Richtung vertauscht, wechselt das Ergebnis von „nicht zu viel abgezogen“ zu „nicht vollständig zurückgezahlt“.
Nehmen wir $BABY als Beispiel für den aktuellen öffentlichen Testablauf: Autorisierung, tatsächlicher Abzug und der Schuldensaldo tauchen innerhalb einer einzigen Aktion nacheinander auf – man nimmt sie daher leicht für drei Versionen derselben Zahl. Der Vertrag interpretiert sie jedoch dreimal getrennt: erst, ob die Berechtigung ausreicht, dann, wie viel die Transaktion tatsächlich liefert, und zuletzt, wie die Schuld aktualisiert wird. Er behandelt nicht den nicht abgedeckten Teil automatisch als „nicht vorhanden“, nur weil der Nutzer subjektiv auf „alles“ geklickt hat.
Diese Kredit-/Leih-Assets sind derzeit allesamt mock-Assets ohne echten Wert. Die drei Zeilen können nur das Mechanismusverständnis erklären; um damit reale Verluste zu „verkalkulieren“, gibt es keine Grundlage. Einen festen Buffer gibt es auch nicht – sobald sich die Bestätigungszeit ändert, können sich die Zahlen entsprechend ändern. Zu prüfen ist also nicht, wie groß die Autorisierung im Wallet irgendwann einmal angezeigt wurde, sondern wie viel nach dem tatsächlichen Ablauf in der dritten Zeile am Ende wirklich noch übrig ist.
Genau hier liegt der Unterschied. Die überschüssige Autorisierung bleibt am Eingang stehen, die zu geringe Rückzahlung bleibt auf dem Konto.
#baby