ブリッジのことを先に考えるのをやめて、実際に必要な「資産」のほうを考え始めると、クロスチェーン・スワップはぐっと理解しやすくなります。

簡単な例を見てみましょう。

Ethereum上にUSDCはありますが、目的地はTONで、そこで使いたいのはUSDTです。

これは同時に起きる2つの別の変更です：

Ethereum → TON
USDC → USDT

従来のやり方だと、必要以上に複雑に感じてしまうことがあります。

たとえば、USDCをEthereumからブリッジして、TON上でブリッジされた表現を受け取り、その後USDTを得るためにさらに別のスワップをします。

すると道のりはこうなります：

Ethereum USDC → ブリッジ → ブリッジされた USDC → スワップ → TON USDT

動作はしますが、複数のステップと複数の資産が関わってきます。

ここで @ston_fi の背後にあるクロスチェーン・アプローチが面白くなってきます。

Omnistonでは、依頼は「目的地で本当にほしい資産」に基づいて行えます。

考え方としては、

«“どうやってUSDCをTONに載せる？”»

ではなく、

«“ここにUSDCがある。あちらではUSDTが必要だ。”»

と考えられます。

そして、そのために必要なクロスチェーン・スワップの実行に向けた調整は、インフラ側が処理します。

Omnistonは、オーダーを競うためにリゾルバを使い、リンクされたHTLCベースの決済がトランザクションの送信側と受信側を調整します。

その裏側の技術的な仕組みは、目に見えないところにあります。

ユーザーの視点では、重要な部分はずっとシンプルです：

「送るもの」→「受け取るもの」

この違いは、体験に実際に大きな差を生み得ます。

最終目標がTON上のUSDTで、いったん中間トークンを受け取ってから再度スワップする必要がある場合、判断がもう1回増え、別のトランザクションが発生し、場合によっては追加コストもかかります。

ダイレクトに「目的地の資産」を指定するアプローチなら、その摩擦を減らせます。

ただし、見落としてほしくないことがもう1つあります：

署名する前に必ず見積もり（クオート）を確認してください。

たとえばEthereum上の10 USDCをTON上のUSDTにスワップするなら、最終的な数字だけを見ないでください。

送信元のネットワークを確認。

受信先のネットワークを確認。

受け取る正確なトークンを確認。

見込まれる受取量を確認。

手数料と、提示された金額（クオート）を確認。

🌐 app.ston.fi