📍Der SDK-Fehler, den ich fast gemacht hätte, als ich auf TON baute
Mein erster Instinkt war, das STONfi SDK als das komplette Toolkit zu behandeln. Das ist es nicht — es ist nur eine Schicht in einem Stapel, und das Überspringen der restlichen Teile macht Integrationen schnell spröde.
🧱 Was das SDK tatsächlich abdeckt
- TypeScript-Klassen für Router, Pool, LP Account und Vault
- Baut die Swap- und Liquidity-Transaktionsparameter
- Macht aus API-Router-Metadaten echte Contract-Instanzen
- Repräsentiert pTON, wenn natives TON Teil der Route ist
Es spricht nicht direkt mit der Chain und behandelt auch keine Wallet-Freigabe — absichtlich.
📦 Der Stack, den ich tatsächlich zusätzlich gebraucht habe
- Frontend: React, TypeScript, Vite/Nextjs, plus ston-fi/sdk, ston-fi/api, ton/ton, tonconnect/ui-react
- Backend: TypeScript, tsx, ston-fi/sdk, ston-fi/api, ton/ton
- Tausche das SDK nicht einfach gegen das Omniston-Paket, außer Aggregation ist wirklich das Ziel — das habe ich auf die harte Tour gelernt
🛠 Die Setup-Reihenfolge, die funktioniert hat
1. Projektgerüst erstellen, sicherstellen, dass die Basis-App zuerst läuft
2. Pakete installieren, Strict TypeScript aktivieren
3. Buffer-Polyfills nur dann hinzufügen, wenn der Browser-Build sie braucht
4. Shared tonClient- und stonApiClient-Instanzen nur einmal erstellen
5. Über die API simulieren, Router-Metadaten in dexFactory() einspeisen und dann die Contracts öffnen
⚙ Warum die Schichten getrennt bleiben
API-Daten, SDK-Contracts, RPC-Zugriff und Wallet-Signing als eigenständige Schichten zu halten, macht das Ganze testbar. Den Router dynamisch aus Live-Simulationen zu ziehen, hält alles auf Kurs mit dem Mainnet — statt mit einer vor Monaten fest verdrahteten Version.
Produktionsreifes Signal: Jede Schicht funktioniert allein, und die finale Transaktion entspricht der Simulation exakt.
Mini App oder direkt Full dApp? 👇
Kein Investment Advice — recherchiere auf eigene Faust!
$SOL
Mein erster Instinkt war, das STONfi SDK als das komplette Toolkit zu behandeln. Das ist es nicht — es ist nur eine Schicht in einem Stapel, und das Überspringen der restlichen Teile macht Integrationen schnell spröde.
🧱 Was das SDK tatsächlich abdeckt
- TypeScript-Klassen für Router, Pool, LP Account und Vault
- Baut die Swap- und Liquidity-Transaktionsparameter
- Macht aus API-Router-Metadaten echte Contract-Instanzen
- Repräsentiert pTON, wenn natives TON Teil der Route ist
Es spricht nicht direkt mit der Chain und behandelt auch keine Wallet-Freigabe — absichtlich.
📦 Der Stack, den ich tatsächlich zusätzlich gebraucht habe
- Frontend: React, TypeScript, Vite/Nextjs, plus ston-fi/sdk, ston-fi/api, ton/ton, tonconnect/ui-react
- Backend: TypeScript, tsx, ston-fi/sdk, ston-fi/api, ton/ton
- Tausche das SDK nicht einfach gegen das Omniston-Paket, außer Aggregation ist wirklich das Ziel — das habe ich auf die harte Tour gelernt
🛠 Die Setup-Reihenfolge, die funktioniert hat
1. Projektgerüst erstellen, sicherstellen, dass die Basis-App zuerst läuft
2. Pakete installieren, Strict TypeScript aktivieren
3. Buffer-Polyfills nur dann hinzufügen, wenn der Browser-Build sie braucht
4. Shared tonClient- und stonApiClient-Instanzen nur einmal erstellen
5. Über die API simulieren, Router-Metadaten in dexFactory() einspeisen und dann die Contracts öffnen
⚙ Warum die Schichten getrennt bleiben
API-Daten, SDK-Contracts, RPC-Zugriff und Wallet-Signing als eigenständige Schichten zu halten, macht das Ganze testbar. Den Router dynamisch aus Live-Simulationen zu ziehen, hält alles auf Kurs mit dem Mainnet — statt mit einer vor Monaten fest verdrahteten Version.
Produktionsreifes Signal: Jede Schicht funktioniert allein, und die finale Transaktion entspricht der Simulation exakt.
Mini App oder direkt Full dApp? 👇
Kein Investment Advice — recherchiere auf eigene Faust!
$SOL