當你不再先想着橋，而是先想你真正需要的資產時，跨鏈兌換會變得更容易理解。
舉個簡單的例子：
你在以太坊上有 USDC，但你的目標是 TON；而你實際想在那邊使用的是 USDT。
這同時發生了兩次獨立的變化：
以太坊 → TON
USDC → USDT
傳統的做法可能會讓事情顯得比實際需要的更復雜。
你可能會把 USDC 從以太坊橋到 TON，收到一個橋接後的表示，然後再進行一次兌換以獲得 USDT。
所以整個過程會變成：
以太坊 USDC → 橋 → 橋接後的 USDC → 兌換 → TON USDT
它是可行的，但涉及多個步驟和資產。
這就是 @ston_fi 背後的跨鏈方案開始變得有趣的地方。
藉助 Omniston，你的請求可以圍繞你在目的地真正想要的資產來提出。
不必先去想：
«“我該怎麼把我的 USDC 轉到 TON？”»
你可以這樣想：
«“我這裏有 USDC。我需要那邊的 USDT。”»
隨後，基礎設施會處理執行這筆跨鏈兌換所需的協調。
Omniston 使用 resolvers 來競爭訂單，而基於鏈接的 HTLC 的結算協調交易的源端和目的端。
所有技術層面的運作都在幕後完成。
從用戶的角度來看，關鍵部分會簡單得多：
我發送什麼 → 我收到什麼。
這種區分會實實在在地影響體驗。
如果你的最終目標是在 TON 上獲得 USDT，先接收一箇中間代幣再進行二次兌換，會增加另一個決策、另一筆交易，並且可能帶來額外成本。
直接以“目的地資產”爲導向的方法可以減少這種摩擦。
不過我仍然不建議你忽略這一點：
在簽名前務必檢查報價。
如果你是在以太坊上用 10 USDC 兌換 TON 上的 USDT，不要只看最終數字。
檢查源網絡。
檢查目的網絡。
檢查你將要收到的確切代幣。
檢查預期的數量。
檢查費用和報價價值。
🌐 app.ston.fi
舉個簡單的例子：
你在以太坊上有 USDC，但你的目標是 TON；而你實際想在那邊使用的是 USDT。
這同時發生了兩次獨立的變化：
以太坊 → TON
USDC → USDT
傳統的做法可能會讓事情顯得比實際需要的更復雜。
你可能會把 USDC 從以太坊橋到 TON，收到一個橋接後的表示，然後再進行一次兌換以獲得 USDT。
所以整個過程會變成：
以太坊 USDC → 橋 → 橋接後的 USDC → 兌換 → TON USDT
它是可行的，但涉及多個步驟和資產。
這就是 @ston_fi 背後的跨鏈方案開始變得有趣的地方。
藉助 Omniston，你的請求可以圍繞你在目的地真正想要的資產來提出。
不必先去想：
«“我該怎麼把我的 USDC 轉到 TON？”»
你可以這樣想：
«“我這裏有 USDC。我需要那邊的 USDT。”»
隨後，基礎設施會處理執行這筆跨鏈兌換所需的協調。
Omniston 使用 resolvers 來競爭訂單，而基於鏈接的 HTLC 的結算協調交易的源端和目的端。
所有技術層面的運作都在幕後完成。
從用戶的角度來看，關鍵部分會簡單得多：
我發送什麼 → 我收到什麼。
這種區分會實實在在地影響體驗。
如果你的最終目標是在 TON 上獲得 USDT，先接收一箇中間代幣再進行二次兌換，會增加另一個決策、另一筆交易，並且可能帶來額外成本。
直接以“目的地資產”爲導向的方法可以減少這種摩擦。
不過我仍然不建議你忽略這一點：
在簽名前務必檢查報價。
如果你是在以太坊上用 10 USDC 兌換 TON 上的 USDT，不要只看最終數字。
檢查源網絡。
檢查目的網絡。
檢查你將要收到的確切代幣。
檢查預期的數量。
檢查費用和報價價值。
🌐 app.ston.fi
