Nicht-verwahrend sollte mehr bedeuten als nur ein Schlagwort im Marketing eines Projekts. Mit STON.fi wird das Konzept direkt in der Art und Weise widergespiegelt, wie seine Smart-Contract-Architektur mit Vermögenswerten umgeht.
Wenn Nutzer mit STON.fi interagieren, werden ihre Token nicht in ein zentrales Konto eingezahlt, das vom Router kontrolliert wird. Die Assets verbleiben entweder in der eigenen Jetton-Wallet des Nutzers oder innerhalb der isolierten Smart Contracts, die für Liquiditätspools verantwortlich sind.
Der Router fungiert eher als Koordinator denn als Tresor. Er empfängt die Swap-Anfrage, ermittelt die erforderliche Route und leitet Anweisungen über das interne Nachrichtensystem von TON weiter. Die tatsächliche Token-Bewegung findet zwischen den relevanten Jetton-Wallets und den Pool-Contracts statt.
Ein typischer Swap folgt daher einer festgelegten Abfolge:
• Token verlassen die Jetton-Wallet des Nutzers
• Sie gelangen in die passende Pool-Token-Wallet
• Der Pool führt die Swap-Logik aus
• Die resultierenden Assets werden zurück in Richtung des Nutzers gesendet
• Integrierte Bedingungen und Bounce-Handling helfen dabei, fehlgeschlagene Operationen zu verhindern, sodass keine Assets „hängen bleiben“
Ein weiterer wichtiger Bestandteil des Designs ist, wie die Liquiditäts-Ownership von der Administration getrennt wird. Administrative Befugnisse können bestimmte protokollbezogene Aktionen ermöglichen, aber die Pool- und Router-Logik stellt kein allgemeines Mechanismus bereit, mit dem ein Administrator einfach die Liquidität eines anderen Nutzers übernehmen könnte.
LP-Token repräsentieren das Eigentum an einer Liquiditätsposition. Die Kontrolle über diese Token bestimmt, wer die entsprechende Position beanspruchen kann.
Das ist es, was STON.fi’s nicht-verwahrendes Modell mehr als nur eine Marketingformulierung macht: Die Architektur ist so ausgelegt, dass Nutzer die Kontrolle über ihre Assets behalten, statt sie an einen zentralen Custodian abzugeben.
#STONfi #TON #DeFi #Web3
Wenn Nutzer mit STON.fi interagieren, werden ihre Token nicht in ein zentrales Konto eingezahlt, das vom Router kontrolliert wird. Die Assets verbleiben entweder in der eigenen Jetton-Wallet des Nutzers oder innerhalb der isolierten Smart Contracts, die für Liquiditätspools verantwortlich sind.
Der Router fungiert eher als Koordinator denn als Tresor. Er empfängt die Swap-Anfrage, ermittelt die erforderliche Route und leitet Anweisungen über das interne Nachrichtensystem von TON weiter. Die tatsächliche Token-Bewegung findet zwischen den relevanten Jetton-Wallets und den Pool-Contracts statt.
Ein typischer Swap folgt daher einer festgelegten Abfolge:
• Token verlassen die Jetton-Wallet des Nutzers
• Sie gelangen in die passende Pool-Token-Wallet
• Der Pool führt die Swap-Logik aus
• Die resultierenden Assets werden zurück in Richtung des Nutzers gesendet
• Integrierte Bedingungen und Bounce-Handling helfen dabei, fehlgeschlagene Operationen zu verhindern, sodass keine Assets „hängen bleiben“
Ein weiterer wichtiger Bestandteil des Designs ist, wie die Liquiditäts-Ownership von der Administration getrennt wird. Administrative Befugnisse können bestimmte protokollbezogene Aktionen ermöglichen, aber die Pool- und Router-Logik stellt kein allgemeines Mechanismus bereit, mit dem ein Administrator einfach die Liquidität eines anderen Nutzers übernehmen könnte.
LP-Token repräsentieren das Eigentum an einer Liquiditätsposition. Die Kontrolle über diese Token bestimmt, wer die entsprechende Position beanspruchen kann.
Das ist es, was STON.fi’s nicht-verwahrendes Modell mehr als nur eine Marketingformulierung macht: Die Architektur ist so ausgelegt, dass Nutzer die Kontrolle über ihre Assets behalten, statt sie an einen zentralen Custodian abzugeben.
#STONfi #TON #DeFi #Web3
