STON.fiのトークンスワップをサンドボックスで動作させた開発者に対し、コード内に一見無害に見えるショートカットを残したままメインネットへ移行すると、ユーザー資金が消失する可能性があるという警告が出されています。開発者ブログで公開されたコミュニティ作成のチェックリストは、多くの統合プロセスが失敗する具体的なポイントを概説し、本番環境でのローンチに向けた具体的なレシピを提示しています。

なぜ移行が重要なのか

STON.fiは、TONブロックチェーン上の複数のDEXにわたる流動性を集約するルーターを提供しています。ユーザーにワンクリックのスワップを提供したいプロジェクトは、通常、フロントエンドまたはスマートコントラクトのラッパーからルーターを呼び出します。テスト環境では、ルーターのアドレスは固定されており、手数料スケジュールも既知で、サンドボックスは誤った送信先へのトランザクションも許容します。しかし、メインネットではルーターがアップグレードされる可能性があり、手数料パラメータが変更されることもあります。また、たった一つのアドレスの指定ミスが、実際のトークンを機能しないコントラクトへと送ってしまうことになります。したがって、その経済的なリスクは、スムーズなユーザー体験を実現するか、あるいはプロジェクトの評判を一晩で失墜させるほどの損失を招くかの違いとなります。

最も一般的な間違い：値のハードコーディング

ローンチの失敗における繰り返されるパターンは、テスト時に有効だったルーターアドレスや手数料定数をハードコーディングしてしまうことです。STON.fiがパフォーマンス向上やバグ修正のためにルーターをアップグレードする場合（これは日常的なイベントです）、ハードコーディングされたアドレスはもはや機能するコントラクトを指さなくなります。その結果、統合プロセスはユーザーには見えないエラーを投じるか、さらに悪い場合には、トークンを処理できないアドレスに黙って資金をルーティングしてしまいます。コミュニティガイドは、たった一つのルールを強調しています。それは、「どのルーターを使用するかはSTON.fiのREST APIに決定させる」ことです。

ステップバイステップの安全チェックリスト

このチェックリストは、移行プロセスを「環境」「コントラクトとの相互作用」「手数料計算」「エッジケースの処理」という4つの論理的なレイヤーに分類しています。

  • 環境変数を早期に検証する。 テスト中はWebSocketエンドポイントとREST APIのベースURLをサンドボックスに向け、ローンチ前にメインネットのノードに切り替えます。ここでのタイポは、実際のスワップをテスト用ルーターにリダイレクトさせ、トークンを永久にロックしてしまう可能性があります。

  • コントラクトアドレスを埋め込まない。 STON.fi APIに対してシミュレーションリクエストを実行し、レスポンスから現在のルーターアドレスを取得して、実行時にdexFactory（または同等のコントラクトファクトリ）に渡します。これにより、将来のルーターアップグレードにも自動的に適応できます。

  • 手数料をその場で計算する。 APIの構成ペイロードから手数料パラメータを取得し、手数料計算ルーチンで使用します。ハードコーディングされたパーセンテージは、プラットフォームが経済モデルを微調整した瞬間に時代遅れとなります。

  • 公式のSDKとTonConnectを優先する。 SDKはBOC (Bag of Cells) 構造を自動的に構築し、ガスリミット、データエンコーディング、署名検証のチェックも含まれています。手動でのBOCコンパイルは、SDKでカバーできない非常に特殊なユースケースに限定すべきです。

  • 失敗モードのテストを行う。 サンドボックス内で、ガス不足（out-of-gas）、許可不足（insufficient allowance）、不正なレスポンスなどのシナリオをシミュレートします。コントラクトがユーザーに返金するか、あるいは明確なエラーイベントを発行することを確認してください。本番環境でユーザーにこれらのバグを発見させることは、ユーザー離れを招きます。

  • 紹介報酬の引き出しパスを確認する。 DEXのバージョン2では、紹介手数料はウォレットではなく専用のVaultコントラクトに送られます。統合プロセスでは、Vaultの引き出しメソッドを呼び出し、紹介者のアカウントにクレジットする前に、受け取ったトークンを処理する必要があります。

開発者の間で議論されていること

一部の開発者は、SDKは不要なオーバーヘッドを追加するものであり、手動で作成したBOCペイロードの方がサイズが小さく、ガス代も安く済むと主張しています。ガイドはこの見解を認めつつも、SDKにはルーターアドレスや手数料スキーマの更新も含まれていることを指摘しています。つまり、手動で構築したペイロードは、STON.fiのアップグレードのたびに再検討が必要になるということです。したがって、トレードオフは「わずかなガス代の節約」か「サイレントな機能不全のリスク」かの選択になります。

次に注視すべきこと

  • ルーターのアップグレード通知。 STON.fiは開発者チャンネルで今後のルーターの変更を投稿しています。これらのフィードを購読しておけば、メインネットへの切り替え前にサンドボックスで新しいアドレスを事前にテストできます。
  • 手数料パラメータの改定。 手数料率は市場状況に応じて調整される可能性があるため、構成エンドポイントを定期的に取得する仕組みを監視サービスに組み込んでおきましょう。
  • SDKのバージョンリリース。 新しいSDKリリースには、メインネットローンチ後に発見されたエッジケースのバグ修正が含まれていることがよくあります。SDKを最新の状態に保つことは、ルーターアドレスを更新することと同じくらい重要です。

結論は明確です。「テスト環境で動作する」スワップが、そのままメインネットでの安全な体験につながるわけではありません。ルーターアドレスから手数料スケジュールに至るまで、あらゆる重要な値をライブの STON.fi API から取得し、ユーザーがインターフェースに触れる前にエラーパスを厳格に検証することで、開発者はプロダクション環境へのラストワンマイルを越える際、ユーザーの資金を守り、信頼を維持することができます。

Source: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0