SIWX は API Key を置き換えます。
X-API-KEY を渡す代わりに、各リクエストで Authorization: SIWX <token> を渡します。ゲートウェイが署名を検証し、有効な x402 サブスクリプションの存在をリアルタイムでチェックします。仕組み
従来のチャレンジ/レスポンスフローとは異なり、SIWX はステートレスかつ自己完結型です。クライアントがメッセージをローカルで構築・署名し、各リクエストに添付します。ステップバイステップ
- ウォレットアドレス、ドメイン、ナンス、有効期限を含む EIP-4361 メッセージを構築
- ウォレットの秘密鍵でメッセージに署名
- SIWX トークンとしてエンコード:
base64(message).signature - 各 API リクエストに添付:
Authorization: SIWX <token> - ゲートウェイが署名を検証し、ウォレットにアクティブな x402 サブスクリプションがあることを確認
- 有効であれば、リクエストは通常通り処理される(API Key 認証と同様)
トークンフォーマット
必須フィールド
有効期限はクライアントが設定します。数分、数時間、数日間有効なメッセージに署名できます。有効期限が長いほど再署名の頻度が減りますが、短い方がより安全です。
対応チェーン
前提条件
SIWX 認証には、ウォレットアドレスにリンクされたアクティブな x402 サブスクリプションが必要です。サブスクリプションがない場合、ゲートウェイはエラーでリクエストを拒否します。 サブスクリプションの取得:使用例
cURL
SDK
CLI
CLI はウォレットでログインすると自動的に SIWX を使用します:SIWX vs API Key
セキュリティに関する考慮事項
- ステートレス: サーバー側のセッションなし。各リクエストが独立して検証されます。
- 有効期限: クライアントが
Expiration Timeフィールドでトークンの有効期間を制御します。期限切れのトークンは拒否されます。 - ドメインバインディング: メッセージにはドメインとして
api.chainstream.ioが含まれます。他のドメインの署名は拒否されます。 - 秘密鍵の非露出: ウォレットはプレーンテキストメッセージに署名するだけです — 秘密鍵は決して送信されません。
- サブスクリプションチェック: 有効な署名があっても、ウォレットにアクティブな x402 サブスクリプションがない場合、リクエストは拒否されます。

