diff --git a/.gitbook/docs.json b/.gitbook/docs.json index 46996eed..0da8e849 100644 --- a/.gitbook/docs.json +++ b/.gitbook/docs.json @@ -1690,6 +1690,83 @@ ] } ] + }, + { + "language": "ja", + "groups": [ + { + "group": "INJECTIVE", + "pages": [ + { + "group": "DeFi", + "icon": "coins", + "expanded": false, + "pages": [ + "ja/defi/index", + { + "group": "ウォレット", + "pages": [ + "ja/defi/wallet/index", + "ja/defi/wallet/create", + "ja/defi/wallet/accounts" + ] + }, + { + "group": "トレーディング", + "pages": [ + "ja/defi/trading/index", + "ja/defi/trading/order-types", + "ja/defi/trading/fees", + "ja/defi/trading/24-5-equity-feeds", + "ja/defi/trading/margin", + "ja/defi/trading/margin-liquidation", + "ja/defi/trading/margin-funding-rates", + "ja/defi/trading/margin-performing-liquidations", + "ja/defi/trading/derivatives", + "ja/defi/trading/derivatives-perpetuals", + "ja/defi/trading/derivatives-expiry-futures", + "ja/defi/trading/derivatives-election-perpetual", + "ja/defi/trading/derivatives-pre-launch-futures", + "ja/defi/trading/derivatives-index-perpetual-futures", + "ja/defi/trading/derivatives-iassets" + ] + }, + { + "group": "トークン規格", + "pages": [ + "ja/defi/tokens/index", + "ja/defi/tokens/inj-coin", + "ja/defi/tokens/token-factory", + "ja/defi/tokens/cw20-standard" + ] + }, + "ja/defi/bridge", + "ja/defi/staking", + "ja/defi/governance", + "ja/defi/community-buyback", + "ja/defi/transactions", + "ja/defi/transaction-fees", + { + "group": "Open Liquidity Program", + "pages": [ + "ja/defi/open-liquidity-program/introduction", + "ja/defi/open-liquidity-program/epochs", + "ja/defi/open-liquidity-program/eligibility", + "ja/defi/open-liquidity-program/scoring", + "ja/defi/open-liquidity-program/formula-parameters", + "ja/defi/open-liquidity-program/reward-allocations", + "ja/defi/open-liquidity-program/flexible-reward-allocations", + "ja/defi/open-liquidity-program/reward-disbursements", + "ja/defi/open-liquidity-program/performance-tracking", + "ja/defi/open-liquidity-program/volatility-response-modifications", + "ja/defi/open-liquidity-program/fee-tiers" + ] + } + ] + } + ] + } + ] } ] }, diff --git a/.gitbook/ja/defi/bridge.mdx b/.gitbook/ja/defi/bridge.mdx new file mode 100644 index 00000000..3afb4a59 --- /dev/null +++ b/.gitbook/ja/defi/bridge.mdx @@ -0,0 +1,5 @@ +--- +title: ブリッジ +--- + +Injectiveエコシステムへの資産のブリッジは、23以上のネットワークをサポートしており、今後も拡大予定です。ここでは、Ethereum、Solana、IBC経由、およびWormholeプロトコルを使用した資産ブリッジのステップバイステップガイドをご覧いただけます。Injectiveエコシステムとの接続が簡単に行えます。 diff --git a/.gitbook/ja/defi/community-buyback.mdx b/.gitbook/ja/defi/community-buyback.mdx new file mode 100644 index 00000000..83e27a70 --- /dev/null +++ b/.gitbook/ja/defi/community-buyback.mdx @@ -0,0 +1,59 @@ +--- +title: Community Buyback +--- + +### Community Buybackとは？ + +Community Buybackは、誰でもInjectiveのデフレメカニズムに参加できる月次のオンチェーンイベントです。参加者はINJをコミットし、その見返りとしてInjectiveエコシステム全体で生成された収益の按分シェアを受け取ります。交換されたINJはその後永久にバーンされ、総供給量が減少します。 + +このプロセスはコミュニティに報酬を提供し、INJの希少性を高め、長期的な価値をエコシステムの成功と一致させます。Community Buybackは、元のBurn Auctionから進化したもので、勝者総取りモデルをよりシンプルでアクセスしやすい、コミュニティ主導のデザインに置き換えました。 + +
+ +### 主要な詳細一覧 + +最も重要なパラメーターのクイックリファレンス： + +* 頻度：28日 +* スロット数：固定 +* 資金源：エコシステムで生成された収益の一部 +* コミットメント：INJのみ、設定された最小/最大制限内 +* 分配：INJコミットメントに基づく按分 +* 結果：INJがバーンされ、参加者に資産が分配される +* 透明性：完全にオンチェーン + +### なぜ重要なのか + +* デフレデザイン – 各ラウンドでINJがバーンされ、総供給量が減少 +* 民主的なアクセス – 1人のオークション勝者ではなく、共有の機会 +* インセンティブの整合 – ネットワーク混雑（トランザクション手数料は関係なく低いまま）ではなく、エコシステム活動に応じてリワードがスケール +* オンチェーン証明 – すべてが透明で検証可能 + +### 仕組み + +1. **スロットを確保する**\ + 月に1回、固定数の予約スロットがオープンします。スロットが利用可能な間は、誰でもスロットを予約できます。 +2. **INJをコミットする**\ + 表示されている最小および最大制限内でINJをコミットしてスロットを予約します。コミットメントはイベントウィンドウ中にオンチェーンで行われ、提出後は変更できません。 +3. **収益を請求する**\ + イベントが終了すると、すべてのINJコミットメントがその月に収集された収益と交換されます。この収益は複数の異なるトークンで構成され、すべての参加者に按分で分配されます。\ + \ + 請求するには、Injective Hub → Community Buybackにアクセスし、Burn Historyの下にある参加したラウンドの横にあるClaimを押してください。 +4. **INJ Buyback**\ + すべての参加者から収集されたINJの合計は永久にバーンされ、INJの総供給量が減少します。 +5. **来月に備える**\ + 収益を追跡し、過去のラウンドの統計を監視し、Injective Hubダッシュボードから直接次のCommunity Buybackの最新情報を入手してください。すべてのスロット予約、コミットメント、バーントランザクション、および分配はオンチェーンで公開されています。 + +### FAQ + +**自分のシェアはどのように決まりますか？**\ +あなたのシェアは、あなたがコミットしたINJをすべての参加者がコミットしたINJの合計で割った値（按分）です。 + +**コミットメントを提出した後に撤回または変更できますか？**\ +いいえ、コミットメントは提出後に確定します。 + +**バーンが行われたことをどのように確認できますか？**\ +バーントランザクションはオンチェーンで記録されており、[Injective Hub](https://injhub.com/community-burn)で追跡できます。 + +**ラウンドを逃した場合はどうなりますか？**\ +来月のイベントがオープンするまで待つ必要があります。 diff --git a/.gitbook/ja/defi/governance.mdx b/.gitbook/ja/defi/governance.mdx new file mode 100644 index 00000000..eca99ea4 --- /dev/null +++ b/.gitbook/ja/defi/governance.mdx @@ -0,0 +1,33 @@ +--- +title: ガバナンス +--- + +## ガバナンス + +Injectiveはコミュニティ主導のブロックチェーンであり、INJをステーキングしたユーザーはブロックチェーンに関するガバナンスに参加できます。プロポーザルを提出することで、Injectiveプログラムの改訂、技術アップグレード、またはInjectiveエコシステム全体に影響を与えるその他の変更を行うことができます。 + +Injective Hub内では、ガバナンスポータルを通じて新しいプロポーザルが提出され、コミュニティ全体によって投票が行われます。 + +### リクエストの提出 + +新しいリクエストを提出するには、変更したい内容、その変更がInjectiveのどの領域に影響を与える可能性があるか、およびこの変更を要求する理由を概説するプロポーザルを作成する必要があります。 + +プロポーザルを作成した後、ガバナンスに提出するために少なくとも10 INJ（10e19 inj）をデポジットする必要があります。これは、あなたがInjectiveコミュニティのアクティブな参加者であり、プロポーザルリクエストを行う資格があることを確認するためです。 + +プロポーザルが投票段階に進むには、100 INJ（10e20 inj）のデポジットも必要です。これはあなたが直接デポジットするか、他のコミュニティメンバーと協力してデポジットすることができます。 + +### 投票期間 + +プロポーザルとデポジットが提出されると、プロポーザルは4日間の投票期間を経ます。 + +INJ保有者の33.4%がプロポーザルに投票する必要があり、その投票の50%が「賛成」である場合にプロポーザルが可決されます。 + +### 投票結果 + +プロポーザルが可決された場合、Injectiveのコントリビューターが協力して新しいリクエストを実行に移します。総投票の33.4%が`NoWithVeto`である場合、定足数に達しない場合、または最低デポジットに達しない場合、デポジットはバーンされます。その他のすべての投票結果では、デポジットが返金されます。 + +### はじめに + +* ガバナンスプロポーザルプロセスの詳細については、Injectiveの[ブログ](https://injective.com/blog/injective-governance-proposal-procedure/)をお読みください。 +* ブロックチェーンガバナンスに参加するには、[Injective Discord](https://discord.com/invite/NK4qdbv)または[Injective Governance Forum](https://gov.injective.network)に参加してください。 +* [Injective Hub](https://injhub.com/governance)にアクセスして、Injectiveのプロポーザルを確認し、投票に参加してください。 diff --git a/.gitbook/ja/defi/index.mdx b/.gitbook/ja/defi/index.mdx new file mode 100644 index 00000000..15257464 --- /dev/null +++ b/.gitbook/ja/defi/index.mdx @@ -0,0 +1,11 @@ +--- +title: "概要" +description: "このセクションでは、トレーダーがInjectiveでの取引商品について詳しく学び、取引を始めるための情報を提供します" +--- + +ここでは、Injectiveの**exchangeモジュール**の包括的な概要、チュートリアル、ガイド、リワードプログラム、リーダーボードコンペティション、および開発者やAPIトレーダー向けの一般的なリソースをご覧いただけます。 + +- [ウォレット](/ja/defi/wallet/) +- [トレーディング](/ja/defi/trading/) +- [トークン規格](/ja/defi/tokens/) +- [Open Liquidity Program (OLP)](/ja/defi/open-liquidity-program/) diff --git a/.gitbook/ja/defi/open-liquidity-program/eligibility.mdx b/.gitbook/ja/defi/open-liquidity-program/eligibility.mdx new file mode 100644 index 00000000..ec6309e7 --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/eligibility.mdx @@ -0,0 +1,42 @@ +--- +description: "OLP報酬の資格取得と維持方法" +title: "資格要件" +--- + +## Clean Slate Qualification + +Injectiveアドレスは、以下の基準を満たすことでOLPの資格を取得できます： + +- **アドレスは、資格取得プロセスの開始前にTrade & Earn（T&E）プログラムからオプトアウトしている必要があります**。アドレスは資格取得プロセス中にT&E報酬を獲得しません。プログラムによるオプトアウトの例については、[Python](https://github.com/InjectiveLabs/sdk-python/blob/master/examples/chain_client/24_MsgRewardsOptOut.py)、[Go](https://github.com/InjectiveLabs/sdk-go/blob/master/examples/chain/24_MsgRegisterAsDMM/example.go)、[TS](https://github.com/InjectiveLabs/injective-ts/wiki/04CoreModulesExchange#msgrewardsoptout)を参照してください。 + - 注意：資格取得プロセスの対象となるのは、オプトアウト完了翌日の00:00 UTCからです。アドレスがT&Eからのオプトアウトに成功したかどうかを確認するには、[このリスト](https://lcd.injective.network/injective/exchange/v1beta1/opted_out_of_rewards_accounts)を参照してください。 +- アドレスのメイカーボリュームが、[**対象市場**](./eligible-markets/)の**1日の合計exchangeメイカーボリュームの少なくとも0.25%を3日連続で**占める必要があります。セルフトレーディングは厳格に禁止されています。 + +これらの要件が両方とも満たされた場合、アドレスは4日目の00:00 UTCにOLP報酬の資格を取得します。資格取得後、特別な状況（システムの悪用、ウォッシュトレーディングなど）によりアドレスが除外されない限り、epochの残りの期間を通じて報酬の資格が維持されます。資格取得前のアクティビティは報酬にカウントされないことにご注意ください。 + + + メイカーボリュームを増やすために、取引戦略を単一のアドレスに集約することが賢明です。そうしないと、必要な閾値よりもメイカーボリュームが少ないアドレスは、複数アドレスの合計ボリュームが閾値を超えていても報酬の資格を得ることができません。 + + 単一のアドレスから複数の戦略を実行しながら取引[手数料割引](https://helixapp.com/fee-discounts)を維持する方法については、[`Injective authzモジュールのドキュメント`](https://docs.injective.network/develop/modules/Core/authz/)を参照してください。 + + +## 次のEpochの資格維持・事前資格 + +現在のepochで資格を取得した後、次のepochに自動的に資格を得るためには、**アドレスは資格取得日からepoch最終日までの[対象市場](./eligible-markets/)（KAVA報酬市場を除く）の合計exchangeメイカーボリュームの少なくとも0.25%を占める必要があります**。 + +- 例：アドレス`inj1a`はOLP報酬の資格がない状態でepoch 21に入ります。`inj1a`はepoch 21の1日目、2日目、3日目にそれぞれ[対象市場](./eligible-markets/)の1日の合計exchangeメイカーボリュームの1%、0.1%、0.2%を占めました。4日目、5日目、6日目には、`inj1a`は該当するボリュームのそれぞれ0.5%を占めました。`inj1a`はepochの7日目に資格を取得します。epoch 22の資格を維持するためには、`inj1a`はepoch 21の7日目から28日目までの累積該当メイカーボリュームの少なくとも0.25%を占める必要があります。この期間（7日目から28日目）の[対象市場](./eligible-markets/)の累積メイカーボリュームが$100Mだった場合、`inj1a`は同期間中にそれらの市場で累積メイカーボリューム$250,000を占める必要があります。 + +前のepochの事前資格によりepoch全体を通じて資格があった場合、そのアドレスはepoch全体の[対象市場](./eligible-markets/)のメイカーボリュームの少なくとも0.25%を占める必要があります。 + +- 例：アドレス`inj1a`はepoch 21での資格維持により事前資格を得た状態でepoch 22に入ります。epoch 22の[対象市場](./eligible-markets.md)の累積メイカーボリュームが合計$200Mだったとします。この場合、`inj1a`はepoch 23の自動資格を維持するために、epoch 22の終了までに$200Mのうち少なくとも$500,000の[対象市場](./eligible-markets.md)ボリュームを貢献する必要があります。 + +## 資格喪失 + +**epochにおいて該当するメイカーボリュームの少なくとも0.25%を占めることができなかったアドレスは、次のepochの開始時にOLPから資格喪失となります**。アドレスがプログラムに再参加を希望する場合、[Clean Slate Qualificationプロセス](./eligibility/#clean-slate-qualification)を再度行う必要があります（ただし、T&Eから再度オプトアウトする必要はありません）。アドレスが資格を持たない日に提供された流動性は、再資格取得後に遡及的に報酬が付与されることはありませんのでご注意ください。 + + + 資格喪失は各epochの終了時に発生します。つまり、次のepochの資格に関係なく、アドレスはepoch内で引き続き報酬を蓄積します。 + + +## 資格の追跡 + +[OLPダッシュボード](https://trading.injective.network/program/liquidity/eligibility)をご利用ください。 diff --git a/.gitbook/ja/defi/open-liquidity-program/epochs.mdx b/.gitbook/ja/defi/open-liquidity-program/epochs.mdx new file mode 100644 index 00000000..b93e781e --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/epochs.mdx @@ -0,0 +1,33 @@ +--- +description: "OLP Epochの期間とスケジュール" +title: "Epochs" +--- + +epochとは、マーケットメイカーの相対的なパフォーマンスが評価される期間です。各epoch中に複数のメトリクスが累積的に追跡され、新しいepochの開始時にリセットされます。報酬は各epochの完了後に支払われます（[報酬の支払い](/defi/open-liquidity-program/reward-disbursements)を参照）。現在、**各epochは28日間**です。 + +**最初の公開OLP epoch（epoch 21）は2023年6月13日00:00 UTCに開始されました**。 + +OLP epochの開始日と終了日は以下の表に示されています。この表は通常、数ヶ月先まで将来のepochを含めて随時更新されます。 + + + + + + + + + + + + + + + + + + + + + + +
Epoch開始日 (UTC)終了日 (UTC)
50Sep 2, 2025 00:00:00Sep 30, 2025 00:00:00
51Sep 30, 2025 00:00:00Oct 28, 2025 00:00:00
52Oct 28, 2025 00:00:00Nov 25, 2025 00:00:00
53Nov 25, 2025 00:00:00Dec 23, 2025 00:00:00
54Dec 23, 2025 00:00:00Jan 20, 2026 00:00:00
55Jan 20, 2026 00:00:00Feb 17, 2026 00:00:00
56Feb 17, 2026 00:00:00Mar 17, 2026 00:00:00
57Mar 17, 2026 00:00:00Apr 14, 2026 00:00:00
58Apr 14, 2026 00:00:00May 12, 2026 00:00:00
59May 12, 2026 00:00:00Jun 9, 2026 00:00:00
60Jun 9, 2026 00:00:00Jul 7, 2026 00:00:00
diff --git a/.gitbook/ja/defi/open-liquidity-program/fee-tiers.mdx b/.gitbook/ja/defi/open-liquidity-program/fee-tiers.mdx new file mode 100644 index 00000000..3b8d653a --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/fee-tiers.mdx @@ -0,0 +1,5 @@ +--- +title: "手数料ティア" +--- + +28日間のローリングベースで最低ステーキングINJ量と最低取引量の閾値基準を満たすトレーダーは、[Injective取引手数料の割引](https://www.helixapp.com/fee-discounts)を受ける資格があります。 diff --git a/.gitbook/ja/defi/open-liquidity-program/flexible-reward-allocations.mdx b/.gitbook/ja/defi/open-liquidity-program/flexible-reward-allocations.mdx new file mode 100644 index 00000000..d250479c --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/flexible-reward-allocations.mdx @@ -0,0 +1,12 @@ +--- +description: "市場および機関流動性プロバイダーへのOLP報酬配分" +title: "フレキシブル報酬配分" +--- + +epoch 43で実装された変更の一環として、特定の時期に特定の市場の流動性をブートストラップするための完全に裁量的な動的報酬が含まれています。[報酬配分](./reward-allocations/)に詳述されているのと全く同じ計算を用い、かつ市場の合計報酬に対する流動性プロバイダーのシェアを決定するための従来の計算式/スコアリング方法論に従い、これはMini Epochsのコンセプトを通じて実現されます。Mini Epochsは、メインの「親」epochの合計報酬から支出される「ブースト報酬」を発生させます。 + +Mini Epochsはフレキシブルであり、Primary Epoch内でペアが存在する開始/終了ポイントに制約されません。Mini Epochsは、Primary Epoch内の任意の日付（00:00 UTC）に開始または終了できますが、複数のepochにまたがることはできません。 + +Mini Epochsの報酬は明確に定義されます。すべての対象OLP参加者は、そのペアに対して別途報酬を獲得していない場合でも、Mini Epochsのペア固有の報酬を蓄積できます。もちろん、流動性プロバイダーのMini Epochへの参加は、たとえその特定の期間のみの機会的な参加であっても、Primary Epochへの参加を意味します。Mini Epochsの報酬は、Primary Epochの全体的な報酬と並んでOLPダッシュボードに表示されます。 + +例えば、あるペアに対して500 INJのMini Epochがある場合、Mini Epoch中にそのペアに流動性を提供すると、そのペアの通常の配分に加えて、500 INJ Mini Epochの比例配分を受ける権利があります。これは親epochの報酬から支出されます。この例では、親epochの報酬が30,000 INJの場合、29,500 INJが親epochのスコアに基づいて配分され、500 INJがMini Epochのスコアに基づいて配分されます。 diff --git a/.gitbook/ja/defi/open-liquidity-program/formula-parameters.mdx b/.gitbook/ja/defi/open-liquidity-program/formula-parameters.mdx new file mode 100644 index 00000000..ee3124e0 --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/formula-parameters.mdx @@ -0,0 +1,23 @@ +--- +description: "OLP計算式パラメータの値" +title: "計算式パラメータ" +--- + + + + + + + + + + + + + + + + + + +
パラメータ定義値（変更される場合があります）
aLiquidity Scoreの指数0.4
bUptime Scoreの指数3
cVolumeの指数0.8
MinDepthTotal Scoreのポイントを獲得するために必要な最低想定元本オーダーサイズ20k (BTC / INJ / ETH perp markets), 4k (other markets
MaxSpreadTotal Scoreのポイントを獲得するためにオーダーで許容されるミッドプライスに対する最大スプレッド50 bps (BTC & ETH perp markets), 100 bps (other markets)
diff --git a/.gitbook/ja/defi/open-liquidity-program/introduction.mdx b/.gitbook/ja/defi/open-liquidity-program/introduction.mdx new file mode 100644 index 00000000..5d78ff95 --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/introduction.mdx @@ -0,0 +1,20 @@ +--- +description: "Open Liquidity Program (OLP)の紹介" +title: "はじめに" +--- + +Injectiveは、すべてのDeFiアプリケーションにわたる共有流動性を実現する、世界初の真にオンチェーンなオーダーブック環境を独自に提供しています。より深い流動性を絶え間なく追求することで、Injectiveはユーザーとプロトコルに他では利用できない資本効率の高い市場へのシームレスなアクセスを提供しています。 + +イノベーションへの揺るぎないコミットメントに支えられ、Injectiveは機関投資家と一般トレーダーの両方に対応する[**Open Liquidity Program (OLP)**](https://trading.injective.network/program/liquidity)を創設しました。このマイルストーンは、マーケットメイカーや参加者が最小限の参入障壁でオーダーブックの流動性を提供することで報酬を獲得できる新しい時代を意味します。このガイドでは、Open Liquidity Programの包括的なウォークスルーを提供し、OLPメンバーになる方法の詳細を説明します。 + +OLPの報酬は、InjectiveのネイティブユーティリティおよびガバナンストークンであるINJの形式で支払われます。現在、各epoch（28日間）において、対象となる参加者は**30,000 INJ**を獲得できます。 + +この金額は、将来のepochに向けて事前に見直される場合があり、また、1つ以上のVolatility Response Modification（VRM）の結果として現在のepochに対して遡及的に減額される場合もあります。OLPのepochに関する詳細については、[Epochs](./epochs)をご覧ください。 + +報酬対象のトレーディングペアの一覧は、[OLPダッシュボード](https://trading.injective.network/program/liquidity)でご確認いただけます。 + + + すべての報酬はInjectiveコミュニティによるガバナンス承認を条件とします。 + + +OLP報酬の詳細については、[Injective Trading Portal](https://trading.injective.network/)内の[OLPダッシュボード](https://trading.injective.network/program/liquidity)をご覧ください。 diff --git a/.gitbook/ja/defi/open-liquidity-program/performance-tracking.mdx b/.gitbook/ja/defi/open-liquidity-program/performance-tracking.mdx new file mode 100644 index 00000000..4685dd9b --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/performance-tracking.mdx @@ -0,0 +1,34 @@ +--- +description: "OLPダッシュボード" +title: "パフォーマンス追跡" +--- + +市場配分、予想/獲得報酬、市場ごとのスコア、および資格に関する現在および過去の情報は、[Injective Trading Portal](https://trading.injective.network/)内の[OLPダッシュボード](https://trading.injective.network/program/liquidity)で確認できます。 + +スナップショットデータは[Scoresタブ](https://trading.injective.network/program/liquidity/scores)で確認できます。また、[Scoresタブ](https://trading.injective.network/program/liquidity/scores)でCSVファイルをダウンロードして、すべてのアドレスとすべての市場のスコアを同時に確認することもできます。この情報は、広範なレベルでデータを確認したい市場参加者にとって有用です。 + +現在および過去のepochのOLPデータは、プログラムで照会することもできます： + +> Epochsと市場： + +``` +curl -s -X POST -H "Content-Type: application/json" -d '{}' https://glp.rest.injective.network/api/olp/v1/epochs +``` + +> アドレスごとの報酬： + +``` +curl -s -X POST -H "Content-Type: application/json" -d '{"epoch_id":"epoch_231128_231225"}' https://glp.rest.injective.network/api/olp/v1/epoch-scores +``` + +> 市場ごとの報酬： + +``` +curl -X POST -H "Content-Type: application/json" -d '{"epoch_id": "epoch_240123_240219", "market_id":"0x4ca0f92fc28be0c9761326016b5a1a2177dd6375558365116b5bdda9abc229ce", "page": {"per_page": 200}}' https://glp.rest.injective.network/api/olp/v1/total-scores +``` + +> アドレスのスナップショット： + +``` +curl -X POST -H "Content-Type: application/json" -d '{"epoch_id": "epoch_240123_240219", "account_address": ""}' https://glp.rest.injective.network/api/olp/v1/epoch-scores/history +``` diff --git a/.gitbook/ja/defi/open-liquidity-program/reward-allocations.mdx b/.gitbook/ja/defi/open-liquidity-program/reward-allocations.mdx new file mode 100644 index 00000000..4d895960 --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/reward-allocations.mdx @@ -0,0 +1,113 @@ +--- +description: "OLP報酬配分（Epoch 43以降）" +title: "報酬配分" +--- + +## 市場報酬配分 + +報酬は[対象市場](/defi/open-liquidity-program/eligible-markets)に3つの異なる方法で配分されます： + +1. 静的配分 +2. 動的要素を含む最低配分 +3. フレキシブル報酬配分 + +### 静的市場報酬配分（事前配分） + +INJ報酬の13.33%がBTC/USDT PERP市場、ETH/USDT PERP市場、INJ/USDT PERP市場のそれぞれに事前配分され、5%がINJ/USDTスポット市場に事前配分されます。各epochの残りのINJは、最低配分100 INJで、残りの対象市場それぞれに配分されます。 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
市場配分
BTC/USDT Perp13.33%
ETH/USDT Perp13.33%
INJ/USDT Perp13.33%
INJ/USDT Spot5%
その他の対象市場計算式ベースの配分
+ + + 静的配分は、対象リストに追加される市場が増えるにつれて変更される場合があります + + +### 動的市場報酬配分 + +残りの報酬は、以下のスキームに基づいて対象市場（BTC/ETH/INJ Perpを除く）に配分されます。 + +まず、各epochは新たに開始され、すべてのペアが前のepochの取引量や流動性に関係なく、そのepochで利用可能な最大報酬を獲得する均等な機会を持ちます。各ペアはepochの1日目に、最低100 INJから可能な範囲で開始されます。 + +この変更前は、最低報酬が400 INJ、最大報酬が約900 INJであり、低ボリュームのペアと大幅に高いボリュームのペア間の報酬蓄積に十分な差異がありませんでした。この変更により、流動性プロバイダーは人気のある市場のボリュームに対して報酬を受けます。 + +各市場の報酬の範囲はepoch全体を通じて進行し、epochの最終日に当該市場の真の報酬に収束します。範囲$[Rewards_{min};Rewards_{max}]$は市場ごとに以下のように定義されます： + +$$ +MinVolume=Min(Market\ traded\ volume\ since\ beginning\ of\ epoch) \\ +MaxVolume=Max(Market\ traded\ volume\ since\ beginning\ of\ epoch) +$$ + +ここで + +$$ +Rewards_{min_{market\ i}}=100+\frac{Volume_{market_{i}}-MinVolume}{MaxVolume-MinVolume}(Rewards_{max}-100) +$$ + +かつ$Rewards_{max}$は引き続きこのページ下部のとおり計算されます。したがって、最高取引量の市場は$Rewards_{max}$を受け取り、最低取引量の市場は最低報酬100 INJとなります。 + +$Rewards_{min}$は報酬範囲の下限に過ぎず、最高取引量の市場で範囲が$[Rewards_{max};Rewards_{max}]$となる場合を除き、報酬と等しくなることはありません。その場合、報酬は$Rewards_{max}$に等しくなります。これは100 INJから$Rewards_{max}$までの線形関数です。 + +この範囲が定義された上で、市場の報酬を計算する手順は以下のとおりです： + +1. $Rewards_{Market_{i}}=Rewards_{min_{market\ i}}$から開始します +2. 残りの報酬_RR_を、$RR=TAR-\sum_{i}Rewards_{min_{market\ i}}$として上記の計算式を使用して配分します。 +3. 計算された報酬が$Rewards_{max}$を超える場合、上記の計算式に従ってすべての市場に再配分します。 +4. 残りの報酬がなくなるまで反復します。 + +**Epochの途中で追加された市場** + +epochの途中で対象リストに追加された市場の場合、事前配分は日割り計算されます。例えば、ARB/USDTがepochの15日目に追加された場合、その市場はepochの報酬の半分を受け取ります（28日中14日間が残っているため）。 + +### 市場配分上限 + +動的報酬配分を持つ各市場には、以下の計算式に基づくハードキャップが適用されます。ここで、$n$はBTC、ETH、INJ Perpを除く対象市場の数です： + +$$ +Rewards_{max} = TAR\ *\ \frac{1 - TPR}{n}*2 +$$ + +ここで、_TPR_は事前配分された報酬の合計割合（小数で表現、現在0.375）に等しく、_n_は事前配分されていないペアの数です。 + +上限を超える報酬配分は、[動的配分計算式](/defi/open-liquidity-program/reward-allocations#dynamic-market-reward-allocations)に従って他の対象市場に再配分されます。 + +## 報酬配分 + +個々の機関流動性プロバイダーへの報酬は、以下の方程式に基づいて配分されます： + +$$ +Rewards_{MM_i} = \sum_{Market}\left(Rewards_{Market} * \frac {TS_{MM_i, \ Market}} {\sum_{MM} TS_{MM,\ Market}} \right) +$$ + +**各機関流動性プロバイダーは、市場内での比例的な**[Total Score](/defi/open-liquidity-program/scoring#total-score)**に基づいて、ガバナンス承認を条件として報酬を受け取ります。** + + + 各epochの終了時に合計が1 INJ未満の報酬は、支払いプロセスのオーバーヘッドを削減するため無視されます。 + diff --git a/.gitbook/ja/defi/open-liquidity-program/reward-disbursements.mdx b/.gitbook/ja/defi/open-liquidity-program/reward-disbursements.mdx new file mode 100644 index 00000000..1a692684 --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/reward-disbursements.mdx @@ -0,0 +1,14 @@ +--- +description: "OLP報酬の支払い方法" +title: "報酬の支払い" +--- + +OLP報酬は、各epochの終了後に参加者のアドレスに直接送信されます。ただし、コミュニティによる4日間の投票期間を経て承認されるガバナンス提案が必要です。**獲得したINJ報酬の半分はこの即時提案で支払われ、残りの半分は3 epochのベスティング期間の対象となります**。対象アドレスがベスティング期間中のいずれかのepochで非アクティブになった場合（非アクティブとは、epochの開始時に日次ボリューム基準を満たしていない、_または_特定のepochの報酬が前epochの報酬の60%未満であることを指します）、ベスティングされた報酬は没収の対象となります。 + +すべての報酬はガバナンス承認を条件とし、epochあたり500 INJを超える報酬を受ける資格のあるすべてのアドレスは、Injectiveが提出するガバナンス提案に報酬支払いが含まれる前にKYC/KYB検証を受ける必要があります。任意のアドレスがパーミッションレスにOLPに参加できますが、報酬の資格はKYC/KYBに依存します。 + + + 支払いは通常、必要なガバナンスプロセスにより、各epochの終了から数日後に行われます。 + + +報酬の支払いは、[Injective Explorer](https://explorer.injective.network/)のCommunity Spend Poolページで追跡できます。 diff --git a/.gitbook/ja/defi/open-liquidity-program/scoring.mdx b/.gitbook/ja/defi/open-liquidity-program/scoring.mdx new file mode 100644 index 00000000..e143a61e --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/scoring.mdx @@ -0,0 +1,134 @@ +--- +description: "単一市場におけるマーケットメイカーのEpochパフォーマンスのスコアリング" +title: "スコアリング計算式/方法論" +--- + +Injectiveのオンチェーンオーダーブックにおいて深く持続的な流動性を促進するため、OLPでは以下のメトリクスが優先されます： + +- **両サイドの流動性**（bidとaskの両方の流動性） +- **流動性の深さ** +- **Bid-askスプレッド** +- **マーケットメイカーのアップタイム** +- **ボリューム**（メイカーおよびテイカー） +- **複数市場への参加** + +## Total Score + +任意の市場において、流動性プロバイダーのepochにおける$TS$（Total Score）は以下のように計算されます： + +$$ +TS_{Market} = (LS_{Epoch})^a \cdot (Uptime_{Epoch})^b \cdot (Volume_{epoch})^c +$$ + +ここで、$LS_{epoch}$はそのepochにおけるその市場での流動性プロバイダーの[Liquidity Score](/defi/open-liquidity-program/scoring#liquidity-score)、$Uptime_{Epoch}$はそのepochにおけるその市場での流動性プロバイダーの[Uptime Score](/defi/open-liquidity-program/scoring#uptime-score)、$Volume_{epoch}$はそのepochにおけるその市場での流動性プロバイダーの合計ボリューム（メイカーおよびテイカー）です。 + + + $a$、$b$、$c$は計算式の異なる構成要素を重み付けする指数[パラメータ](/defi/open-liquidity-program/formula-parameters)です。 + + +## Liquidity Score + +$$ +LS_{Epoch} = \sum \limits_{N=1}^{40,320} \min(LS_{N_{Bid}}, LS_{N_{Ask}}) +$$ + +epochにおける市場の流動性プロバイダーのLiquidity Score $LS_{Epoch}$は、該当市場のepoch内のすべてのオーダーブックスナップショットにわたるBidとAskのLiquidity Score（以下参照）の最小値の合計に、各市場固有のボラティリティパラメータ（Θで表現）を乗じたものです。$\min()$関数の下では片側のみの流動性はLiquidity Score 0となるため、両サイドの流動性が促進されます。 + +オーダーブックのスナップショットは10〜100ブロックごとにランダムに取得されます。これは平均して約1分ごとであり、1epochあたり約40,320のスナップショットがあることを意味します$(60 \cdot 24 \cdot 28 = 40,320)$。実際には、合計の上限はepoch内の実際のスナップショット数に応じて変動します。このガイドでは、epochにちょうど40,320のスナップショットがあったと仮定します。 + +$$ +LS_{N_{Bid}} = \frac{BidDepth_1}{Spread_1} \cdot \Theta_{vol} + \frac{BidDepth_2}{Spread_2} \cdot \Theta_{vol} + \ldots + \newline \forall \ BidDepth_i \geq MinDepth \text{ and } Spread_i \leq MaxSpread +$$ + +$$ +LS_{N_{Ask}} = \frac{AskDepth_1}{Spread_1} \cdot \Theta_{vol} + \frac{AskDepth_2}{Spread_2} \cdot \Theta_{vol} + \ldots \newline \forall \ AskDepth_i \geq MinDepth \text{ and } Spread_i \leq MaxSpread +$$ + +$LS_{N_{Bid}}$は、スナップショット$N$において流動性プロバイダーが配置した、サイズが$MinDepth$以上かつ$MaxSpread$以内のすべてのリミットオーダーについて、各bidオーダーの深さをそのオーダーのスプレッドで割り、そのスナップショットのボラティリティパラメータを乗じた合計です。 + +$LS_{N_{Ask}}$は$LS_{N_{Bid}}$と同じロジックですが、オーダーブックのask側に対して適用されます。 + +ボラティリティパラメータは以下のように計算されます： + +$$ +\Theta_{\text{vol}}(S_b)\;=\; +\min\!\bigl(\,\Theta_{\max},\; + \max\!\{\,1,\; + e^{\alpha\,\sigma_b\,|\frac{S_b-\mu_b}{S_b}|}\}\bigr) +$$ + +ここで、$\mu_b$は$N$ブロック（1000ブロック、約10分）にわたるオラクル価格の移動平均、$S_b$は現在のブロックのオラクル価格、$\sigma_b$は$N$ブロックにわたる実現ボラティリティを表します。この関数はクランプを持ち、現在のオラクル価格が移動平均から乖離した場合、または直近$N$ブロックでボラティリティが急上昇した場合に適切にスケールします。$\Theta_{\text{vol}} \in [1, \Theta_{\text{max}}]$の範囲 - 有限の範囲内に制限されます。ボラティリティへの感度とクランプを監視する2つの新しいパラメータ$(\alpha, \Theta_{\text{max}})$を導入しています。$\Theta_{\text{max}}$は10分間の期間における3%の価格変動に対して上記の上限10に向かう傾向があるため、$\alpha$は現在2,500に設定されています。$\alpha$の値が高いほど$\Theta$は$\Theta_{\text{max}}$に速く到達しますが、$\Theta_{\text{max}}$は現在市場ごとに10に設定されており（市場ごとに変更可能）、$\alpha$が高くてもその上限を超えることはありません。 + +$Spread$はミッドプライスから計算されます（ミッドプライスからの距離をミッドプライスで割ったもの）。 + + + $MinDepth$と$MaxSpread$の現在の値については、[計算式パラメータページ](/defi/open-liquidity-program/formula-parameters)をご覧ください。 + + +## Uptime Score + +$$ +Uptime_{Epoch} = \sum \limits_{N=1}^{40,320} \begin{cases}1&\text{if } \min(LS_{N_{Bid}}, LS_{N_{Ask}}) > 0\\ 0&\text{otherwise} \\\end{cases} +$$ + +$Uptime_{Epoch}$は、流動性プロバイダーが対象市場において[**正のBid Liquidity Scoreと正のAsk Liquidity Score**](/defi/open-liquidity-program/scoring#liquidity-score)を持っていたepoch全体のオーダーブックスナップショットの数です。これは、流動性プロバイダーがそのスナップショットにおいて、$MinDepth$以上のオーダーサイズで$MaxSpread$以下のスプレッドで、オーダーブックの両サイドにクォートしていたことを意味します。 + +epochの途中でOLP報酬の資格を（初めて）取得した流動性プロバイダーの場合、$Uptime_{Epoch}$は資格取得時点からepoch終了までの合計スナップショット数に基づいてスケーリングされます。 + +例えば、epochにちょうど40,320のスナップショットがあり、流動性プロバイダーが残りちょうど20,000スナップショットの時点で初めて資格を取得したとします。また、epochの残りの期間中に上記のスコアリング計算式で定義される$Uptime_{Epoch}$が18,000であったとします。この場合、$Uptime_{Epoch}$は$\frac{18000}{20000}*40320 = 36288$にスケーリングされます。 + + + epochの途中で資格を取得したが過去に資格を取得したことがあるアドレス（ある時点で資格を維持できなかったアドレス）の場合、$Uptime_{Epoch}$はスケーリングされません。これは、epoch間で資格を失うことへのディスインセンティブとなります。 + + +## Volume + +$Volume$は、epochにおけるその市場での流動性プロバイダーの累積的な対象メイカーおよびテイカーボリュームです。 + +## 完全展開計算式 + +完全に展開された計算式は以下のとおりです： + +$TS_{Market} =$ + +$$ +\left(\sum \limits_{N=1}^{40,320} \min(LS_{N_{Bid}}, LS_{N_{Ask}})\right)^a \cdot \left(\sum \limits_{N=1}^{40,320} \begin{cases}1&\text{if } \min(LS_{N_{Bid}}, LS_{N_{Ask}}) > 0\\ 0&\text{otherwise} \\\end{cases} \right)^b \cdot Volume^c +$$ + +$$ +\text {where} +$$ + +$$ +LS_{N_{Bid}} = \frac{BidDepth_1}{Spread_1} \cdot \Theta_{vol} + \frac{BidDepth_2}{Spread_2} \cdot \Theta_{vol} + \ldots + \newline \forall \ BidDepth_i \geq MinDepth \text{ and } Spread_i \leq MaxSpread +$$ + +$$ +LS_{N_{Ask}} = \frac{AskDepth_1}{Spread_1} \cdot \Theta_{vol} + \frac{AskDepth_2}{Spread_2} \cdot \Theta_{vol} + \ldots \newline \forall \ AskDepth_i \geq MinDepth \text{ and } Spread_i \leq MaxSpread +$$ + + + 各epochの個別報酬計算については、[報酬配分ページ](/defi/open-liquidity-program/reward-allocations)をご覧ください。 + + +[^1]: Market Maker + +[^2]: Market Maker + +[^3]: オーダーブックにおけるベストビッド価格とベストアスク価格の平均 + +[^4]: Market Maker + +[^5]: Market Maker + +[^6]: Market Makers + +[^7]: Market Maker + +[^8]: Market Maker + +[^9]: Market Maker + +[^10]: Market Maker diff --git a/.gitbook/ja/defi/open-liquidity-program/volatility-response-modifications.mdx b/.gitbook/ja/defi/open-liquidity-program/volatility-response-modifications.mdx new file mode 100644 index 00000000..c2c38f6d --- /dev/null +++ b/.gitbook/ja/defi/open-liquidity-program/volatility-response-modifications.mdx @@ -0,0 +1,41 @@ +--- +title: Volatility Response Modifications (VRMs) +--- + +Volatility Response Modifications（VRM）は、プロトコル全体の流動性効率を最適化するために設計された動的報酬システムの一部です。これらの修正により、市場状況に応じて報酬を再配分することが可能になり、ボラティリティの高い期間中にインセンティブがプロトコルのニーズに合致するよう調整されます。 + +当システムは、特定の閾値基準を用いて市場状況を継続的に監視しています： + +**トリガー条件** + +Volatility Response Modificationは以下の条件で発動される場合があります： + +1. 市場全体が24時間以内に5%以上の変動を経験した場合、**かつ** +2. 利用可能な流動性が、確立された30日間の閾値の少なくとも50%を満たしていない場合。主要取引ペアの閾値は通常以下のとおりです： + * BTC/USDT PERP：各サイド50 bps以内に$750,000 + * ETH/USDT PERP：各サイド50 bps以内に$500K + * INJ/USDT PERP：各サイド50 bps以内に$200K + +これらの条件が検出されると、システムは自動的にVRMプロセスを開始します。主観的な判断とは異なり、これらの明確な閾値により、すべての流動性プロバイダーに対して透明性と予測可能性が確保されます。 + +#### コミュニケーションプロセス + +トリガー条件が満たされた場合、明確で時間に配慮したコミュニケーションプロセスに従います： + +1. **即時アラート**：すべての登録済みOLP参加者は、VRMが発効したことを通知するNotifiを通じた即時通知を受け取ります。この時点で60分間のレスポンスウィンドウが開始されます。 +2. **レスポンスウィンドウ**：LPはVRMに対応し、必要な閾値まで流動性を回復するための60分間のウィンドウを持ちます。 +3. **確認通知**：60分間のウィンドウの終了時に、以下に詳述するVRMの結果を通知する別の通知が送信されます。なお、24時間以内に実施されるVRMは最大1回です。 +4. **透明性レポート**：修正をトリガーした市場状況と流動性レベルの概要は、epochの終了時にOLP報酬ガバナンス提案に付随するCommonwealthスレッドに含まれます。 + +#### Epoch報酬の調整 + +VRMイベントが発生した場合、現在のepochの合計INJ報酬に以下の調整が適用されます： + +* **流動性の回復**：60分間のレスポンスウィンドウ内に流動性が必要な閾値まで増加した場合、epoch全体の報酬は**2,500 INJ増額**されます（例：epochの報酬が40,000 INJではなく42,500 INJ）。 +* **流動性の不足**：レスポンスウィンドウ後に流動性閾値が満たされない場合： + * epoch内の最初のVRM：epoch全体の報酬から2,500 INJ減額 + * 同一epoch内の2回目以降のVRM：発生ごとに5,000 INJ減額 + +60分間のレスポンスウィンドウ後に流動性が不足した場合、これらの調整された報酬はより効率的な流動性提供戦略を支援するために振り替えられ、ボラティリティの高い市場状況下でもプロトコルの耐性が維持されます。 + +当プログラムの目標は、市場の質の維持に貢献する参加者に報酬を与える公平なシステムを構築することです。特にそれが最も重要な時に報酬が与えられます。これらの修正により、エコシステムのすべてのステークホルダーにより良いサービスを提供する、より耐性のあるプロトコルの構築を支援します。 diff --git a/.gitbook/ja/defi/staking.mdx b/.gitbook/ja/defi/staking.mdx new file mode 100644 index 00000000..63a717c0 --- /dev/null +++ b/.gitbook/ja/defi/staking.mdx @@ -0,0 +1,25 @@ +--- +title: ステーキング +--- + +### ステーキングとは？ + +ステーキングとは、ブロックチェーン上のトランザクションを検証するために資産（この場合はINJ）をロックアップするプロセスです。資産をステーキングしたユーザーは通常、ステーキングリワードの対象となります。 + +InjectiveはProof-of-Stakeメカニズムを採用しており、ユーザーはトランザクションを検証するInjectiveノード（バリデーター）にINJトークンをステーキングできます。その見返りとして、INJでステーキングリワードを獲得できます。 + +### INJをステーキングする + +[ステーキング](https://injhub.com/stake)ページでバリデーターにINJをステーキングし、リワードの獲得を開始しましょう。 + +### ステーキングリワードの引き出し + +INJをステーキングした瞬間からリワードが発生します。[Injective Hub](https://injhub.com/stake)のステーキングセクションでリワードを確認できます。十分なリワードが貯まったら、いつでも引き出すことができます。 + +### 再委任 + +再委任を使用すると、21日間のアンステーキング期間を経ることなく、ステーキング済みのINJをあるバリデーターから別のバリデーターに即座に移行できます。 + +### アンデリゲート + +INJのアンデリゲートとは、バリデーターから資産をアンステーキングするプロセスで、完了までに21日間かかります。 diff --git a/.gitbook/ja/defi/tokens/cw20-standard.mdx b/.gitbook/ja/defi/tokens/cw20-standard.mdx new file mode 100644 index 00000000..4a552cb3 --- /dev/null +++ b/.gitbook/ja/defi/tokens/cw20-standard.mdx @@ -0,0 +1,5 @@ +--- +title: CW20規格 +--- + +CW20トークン規格は、[ERC20規格](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)に近い形で、パーミッションレスなファンジブルトークンの作成と管理のフレームワークを提供します。上記のとおり、Cosmos SDKとのネイティブ統合により、TokenFactoryの使用が推奨されますが、何らかの理由でCW20規格を使用したい場合は、[CW20 Adapter](https://github.com/CosmWasm/cw-plus/blob/main/packages/cw20/README.md)を使用してCW20トークンをTokenFactoryトークンに、またはその逆に変換できます。CW20規格の詳細については、[こちら](https://github.com/CosmWasm/cw-plus/blob/main/packages/cw20/README.md)の正式な仕様をご覧ください。 diff --git a/.gitbook/ja/defi/tokens/index.mdx b/.gitbook/ja/defi/tokens/index.mdx new file mode 100644 index 00000000..e03519c0 --- /dev/null +++ b/.gitbook/ja/defi/tokens/index.mdx @@ -0,0 +1,21 @@ +--- +title: トークン規格 +--- + +Injectiveは、dAppを作成する際に使用できるさまざまなトークン規格を提供しています。このドキュメントでは、異なるタイプのトークンと、各トークンの使用に関する推奨事項とガイダンスを説明します。 + +## Denom + +denomは、InjectiveのBankモジュール内で資産がどのように表現されるかを示します。これらの資産は、取引、exchangeモジュールでの新しいマーケットの作成、オークションへの参加、別のアドレスへの転送などに使用できます。 + +denomの起源とInjectiveでの作成方法に応じて、異なるタイプのdenomがあります： + +* **Native denom** - このタイプのdenomは1つだけで、Injectiveのネイティブコインを表す`inj` denomです。 +* **Peggy denom** - これらのdenomは、Peggyブリッジを使用してEthereumからInjectiveにブリッジされた資産を表します。形式：`peggy{ERC20_CONTRACT_ADDRESS}` +* **IBC denom** - これらのdenomは、IBCを通じて他のIBC互換チェーンからブリッジされた資産を表します。形式：`ibc/{hash}` +* **Insurance Fund Denom** - これらのdenomは、Injectiveで作成された保険基金のトークンシェアを表します。形式：`share{id}` +* **Factory Denom** - これらの`tokenfactory` denomにより、任意のアカウントが`factory/{creator address}/{subdenom}`という名前で新しいトークンを作成できます。トークンは作成者アドレスで名前空間化されているため、名前の衝突を解決する必要がなく、パーミッションレスなトークン作成が可能です。これらのdenomの特別なユースケースは、CosmwasmのCW20トークンをInjectiveネイティブのBankモジュールで表現することです。形式：`factory/{CW20_ADAPTER_CONTRACT}/{CW20_CONTRACT_ADDRESS}`（`CW20_ADAPTER_CONTRACT`はCW20とネイティブBankモジュールを変換するアダプタコントラクトアドレス） + +これらのdenomタイプの詳細については、このドキュメントの後半で説明します。 + +[denomメタデータ](/developers/assets/token-metadata/)の取得方法を学びましょう。 diff --git a/.gitbook/ja/defi/tokens/inj-coin.mdx b/.gitbook/ja/defi/tokens/inj-coin.mdx new file mode 100644 index 00000000..aa28c649 --- /dev/null +++ b/.gitbook/ja/defi/tokens/inj-coin.mdx @@ -0,0 +1,70 @@ +--- +title: INJコイン +--- + +INJは、Injectiveおよびその広範なエコシステムを支えるネイティブ資産です。INJの各構成要素は、繁栄するWeb3エコシステムを育成するために意図的に設計されています。ブロックチェーンのネイティブ資産として、INJはInjective上のさまざまな操作を促進する中心的な役割を果たしています。InjectiveのTendermint Proof-of-Stake（PoS）コンセンサスフレームワークのカスタム実装に不可欠であり、INJはステーキングを通じてネットワークのセキュリティを確保するために重要です。さらに、INJはInjectiveのガバナンストークンとして機能し、広範なInjectiveエコシステム内での交換手段としても機能します。特に、INJはコアInjectiveモジュールを活用して、革新的なバーンメカニズムと動的供給メカニズムを通じてデフレ特性を実現することで、他のPoSチェーンのネイティブ資産とは一線を画しています。 + +### Base Denomination + +INJはEthereumとの互換性を維持するため、[Atto](https://en.wikipedia.org/wiki/Atto-)をbase denominationとして使用しています。 + +``` +1 inj = 1×10⁻¹⁸ INJ +``` + +これはEthereumのdenominationと一致します： + +``` +1 wei = 1x10⁻¹⁸ ETH +``` + +### Injectiveトケノミクスとユーティリティ + +#### 1. セキュリティとステーキング + +Injectiveはステーキングによってセキュリティが確保されており、これはINJの重要なユースケースです。バリデーターとデリゲーターは、ステーキングを通じてInjectiveネットワークに自由に参加できます。バリデーターはInjective上でノードを運用し、デリゲーターは選択した特定のノードにINJを委任できます。ステーキングされたINJは、ペナルティと報酬のシステムを通じてセキュリティが確保される堅牢な分散型環境を実現します。 + +バリデーターのステーキングされたINJは、悪意ある行動や責任を効果的に果たせなかった場合にスラッシングの対象となります。また、INJはトランザクションの検証とブロック作成への参加に対するバリデーターへの報酬としても使用されます。バリデーターへの報酬は、新たに鋳造されたINJ（ブロック報酬）と関連するトランザクション手数料の一部で構成されます。 + +INJ保有者は、バリデーター報酬の一部を得るために、必ずしもノードを運用せずともステーキングに参加できます。これを行うには、ユーザーはINJをバリデーターに委任します。これは対応するブラウザウォレットを通じて、またはInjective Hubから直接行うことができます。INJをロックアップする見返りとして、ユーザーはバリデーターのINJ報酬の一部を、選択したバリデーターが課す手数料（コミッション）を差し引いた上で、比例配分で受け取ります。ユーザーのステーキングされたINJは、委任先のバリデーターがスラッシングイベントを受けた場合にもスラッシングの対象となります。これにより、バリデーターとデリゲーターの双方がネットワーク全体のセキュリティに貢献するインセンティブが整合されます。 + +Injectiveチェーンのセキュリティ確保に加えて、INJはElectro Chainsを通じて広範なエコシステムにもセキュリティサービスを拡張しています。これらのInjectiveベースのロールアップは、inEVMに見られるような複数のバーチャルマシンのサポートなど、多数の技術的利点を提供します。これらのロールアップはInjectiveに決済されるため、INJがこれらのネットワークの基盤セキュリティレイヤーを支えています。この相互接続されたセキュリティフレームワークは、Injectiveネットワークだけでなく、Electro Chainsの多様なエコシステムの完全性と堅牢性を維持するINJの重要な役割を強調しています。 + +#### 2. ガバナンス + +INJは、チェーンのすべてのパラメータにわたるコミュニティ主導のガバナンスに使用されます。Injectiveは独自にスマートコントラクトのアップロードに対するパーミッショニングレイヤーも備えており、メインネットにスマートコントラクトをインスタンス化するには、ステーカーのコミュニティが投票する必要があります。これにより、コミュニティはInjective全体のすべてのパラメータを直接ガバナンスする権限を持ちます。 + +ガバナンスにおいて、INJは提案の作成とアクティブな提案に対するトークン加重投票に使用されます。スパム防止策として、Injectiveは提案が投票段階に進むためにINJで行われる最低デポジットを要求します。このデポジット閾値は、提案者が全額を満たすか、他のユーザーが提案デポジットにINJを拠出することで累積的に満たすことができます。最大デポジット期間が経過するまでに最低デポジット額に達しない場合、提案は自動的に却下され、デポジットはバーンされます。また、投票期間終了時に提案が可決されなかった場合も、提案デポジットはバーンされます。 + +提案への投票は、ガバナンスによって設定され、すべてのガバナンス投票に一律に適用されるプリセットされた投票期間中に行われます。投票プロセスでは、ステーキングされたINJのみが投票に参加する資格があります。したがって、バリデーターとデリゲーターのみがアクティブな提案に投票できます。投票力はトークン加重であり、1 INJが1票に相当します。デリゲーターはステータスを維持するためにガバナンスに積極的に参加する必要はありません。ただし、提案に直接投票するオプションがあります。デリゲーターが投票しない場合、その投票力は特定の投票イベントについて、委任先のバリデーターに自動的に継承されます。 + +INJは、以下を含むチェーンのすべての側面をガバナンスするために使用されます： + +* Auctionモジュールパラメータ +* Exchangeモジュールカスタム提案およびパラメータ +* Insuranceモジュールパラメータ +* Oracleモジュールカスタム提案 +* Peggyモジュールパラメータ +* Wasmxモジュールパラメータ +* ソフトウェアアップグレード +* Cosmos-SDKモジュールパラメータ（[auth](https://docs.cosmos.network/main/modules/auth#parameters)、[bank](https://docs.cosmos.network/main/modules/bank)、[crisis](https://docs.cosmos.network/main/modules/crisis)、[distribution](https://docs.cosmos.network/main/modules/distribution)、[gov](https://docs.cosmos.network/main/modules/gov)、[mint](https://docs.cosmos.network/main/modules/mint)、[slashing](https://docs.cosmos.network/main/modules/slashing)、[staking](https://docs.cosmos.network/main/modules/staking)モジュール） + +ガバナンスプロセスの詳細については、[こちら](https://blog.injectiveprotocol.com/injective-governance-proposal-procedure)をご覧ください。 + +#### 3. 交換手段 + +INJは、ブロックチェーン上の当事者間における商品やサービスの売買を促進するためのデフォルト資産として使用されます。一般的な例としては、トランザクション手数料（ガス）の支払い、NFTの売買、取引手数料の支払い、または担保としての資産の預入などがあります。ほとんどの商品やサービスは任意の資産で表示できますが、Injectiveで発生するすべてのトランザクション手数料はINJで支払われます。さらに、exchangeモジュールを介したInjectiveの共有流動性レイヤーを活用するアプリケーションによって生成されるすべてのプロトコル収益はINJで蓄積されます。 + +#### 4. Exchange dAppsインセンティブ + +exchangeプロトコルは、メイカー0.1%、テイカー0.2%のグローバル最低取引手数料を実装しています。exchangeプロトコル上での取引活動を促進するインセンティブメカニズムとして、共有オーダーブックに注文を発注するexchange dAppsは、それらが発注したすべての注文から生じる取引手数料の40%を報酬として受け取ります。 + +#### 5. Exchange手数料のバリューアクルーアル + +exchange手数料の残りの60%は、オンチェーンのbuy-back-and-burnイベントが行われ、集約されたexchange手数料バスケットがINJと引き換えに最高入札者にオークションされます。このオークションのINJ収益はその後バーンされ、INJの総供給量をデフレさせます。 + +オークションメカニズムの詳細については、[こちら](../community-buyback/)をご覧ください。 + +#### 6. デリバティブの裏付け担保 + +INJは、Injectiveのデリバティブ市場において、ステーブルコインの代替として証拠金や担保として利用できます。一部のデリバティブ市場では、INJは保険プールステーキングの裏付け担保としても使用でき、ステーカーはロックされたトークンに対して利息を得ることができます。 diff --git a/.gitbook/ja/defi/tokens/token-factory.mdx b/.gitbook/ja/defi/tokens/token-factory.mdx new file mode 100644 index 00000000..6e094277 --- /dev/null +++ b/.gitbook/ja/defi/tokens/token-factory.mdx @@ -0,0 +1,11 @@ +--- +title: Token Factory +--- + +TokenFactoryトークンは、Cosmos SDKのBankモジュールにネイティブに統合されたトークンです。名前は`factory/{creatorAddress}/{subdenom}`の形式を取ります。トークンは作成者アドレスで名前空間化されているため、名前の衝突を解決する必要がなく、パーミッションレスなトークン作成が可能です。 + +この統合により、CW20規格とは異なり、スマートコントラクトに直接クエリする必要なく、すべての資産の総供給量の追跡とクエリがサポートされます。このため、TokenFactory規格の使用が推奨されます。HelixやMitoなどの製品は、bankトークンのみを使用するInjective exchangeモジュール上に構築されています。TokenFactoryトークンは、injectived CLIやスマートコントラクトを通じて作成できます。Wormholeを介してInjectiveにブリッジされたトークンもTokenFactoryトークンです。 + +Injectiveでのトークン作成の詳細については、[トークンローンチ](../../developers-defi/token-launch/)をご覧ください。 + +TokenFactory規格の詳細については、[Token Factoryモジュール](../../developers-native/injective/tokenfactory/)をご覧ください。 diff --git a/.gitbook/ja/defi/trading/24-5-equity-feeds.mdx b/.gitbook/ja/defi/trading/24-5-equity-feeds.mdx new file mode 100644 index 00000000..fd5e4200 --- /dev/null +++ b/.gitbook/ja/defi/trading/24-5-equity-feeds.mdx @@ -0,0 +1,67 @@ +--- +title: "24/5 株式フィード" +description: "Injectiveにおけるオンチェーン株式の24/5価格設定の仕組み" +--- + +Injectiveは、複数のPythセッションフィードを単一の統合Oracleストリームに集約することで、特定の米国株式の24/5価格設定をサポートしています。これにより、原資産の株式がプレマーケット、通常取引時間、アフターアワーズ、およびオーバーナイトセッションをまたいで移動する場合でも、株式Perpetualのスムーズで継続的な取引が可能になります。 + +### 概要 + +米国株式は4つの異なるセッションで取引されます。Pythはそれぞれに対して別々の価格フィードを公開しています： + +- プレマーケット +- 通常取引時間 +- アフターアワーズ +- オーバーナイト / 場外流動性 + +InjectiveはSEDAを使用して、これら4つのセッションフィードをシンボルごとに1つのOracle価格に統合し、約2秒ごとに更新します。この統合ストリームが、Injective株式Perpetualの正規インデックス価格になります。 + +現在サポートされているオンチェーン株式： + +- TRADFI +- TSLA +- META +- TTI +- AAPL +- NVDA +- MSTR +- AMZN +- COIN +- GOOGL +- HOOD +- CRCL +- MSFT +- PLTR + +今後数週間でさらに多くの株式がこのモデルに移行する予定であり、オンチェーンガバナンスがアップグレードを正式化するにつれて、このリストは更新されます。 + +### 集約の仕組み + +サポートされている各株式について、SEDAは以下を行います： + +1. 4つの関連するPythフィードをサブスクライブ +2. ライブの市場フェーズに基づいて正しいセッションフィードを選択 +3. 軽量な整合性および継続性チェックを適用 +4. Injectiveに1つの継続的な価格を出力 + +これにより以下が保証されます： + +- セッション間のギャップなし +- 継続的なチャートとOracleフロー +- 24/5取引のための一貫したMark/Index価格設定 +- セッション移行時のノイズ最小化 + +集約間隔は約2秒で、すべてのセッションにわたりトレーダーにほぼリアルタイムの応答性を提供します。 + +### トレーダーとマーケットメイカーへのメリット + +1. **真の24/5株式取引**：Injective上の株式Perpetualは、中断なく米国株式の4つのセッションすべての価格動向を追跡できます。 +2. **よりクリーンな価格設定**：複数のフィードを管理する必要がなく、セッション切り替えによる急激なジャンプもありません。SEDAがすべてを1つの継続ストリームに標準化します。 +3. **より良いリスクモデリング**：マージン、清算、Mark Priceロジックは1つの一貫したOracleを使用し、予測可能性を向上させ、誤ったリスクトリガーを減らします。 +4. **プロフェッショナルグレードの延長取引カバレッジ**：プレマーケットやアフターアワーズなどの流動性の低い期間も、Pythの専門フィードにより正確に反映されます。 + +### 取引行動と注意事項 + +- ボラティリティはセッションによって大きく異なります。プレマーケットとアフターアワーズは流動性が低くなる可能性があるため、継続的な価格設定にもかかわらず、より広いスプレッドが予想されます。 +- セッション間にニュースが入るとギャップが発生することがあります。統合フィードは、「フィード境界」のアーティファクトではなく、実際の最初の取引価格をチャートに反映させます。 +- 24/7ではなく24/5です。Oracleは週末のみ一時停止し、原資産の株式市場構造に合わせています。 diff --git a/.gitbook/ja/defi/trading/derivatives-election-perpetual.mdx b/.gitbook/ja/defi/trading/derivatives-election-perpetual.mdx new file mode 100644 index 00000000..bc00652a --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-election-perpetual.mdx @@ -0,0 +1,26 @@ +--- +hidden: true +title: Election Perpetual +--- + +Election Perpetual Futures契約（Election Perp）は、Injective上のデリバティブ金融商品の一種であり、選挙市場へのレバレッジ付きエクスポージャーを得ることを可能にします。Election Perpは、従来の暗号資産ではなく、Polymarket上の市場価格を追跡するPerpetual Futures契約です。 + +従来の先物契約とは異なり、これらの契約には満期日がなく、無期限に保有することができます。取引はUSDTで決済されます。他のPerpと同様に、Election Perpはファンディングレートメカニズムを使用して、契約価格を原資産のインデックス価格に近い状態に維持します。 + +### Election Perpetual Futuresの仕組み + +* 契約はPolymarket上の市場（例：[Presidential Election Winner 2024](https://polymarket.com/event/presidential-election-winner-2024)）を追跡します。 +* トレーダーは最大3倍のレバレッジで、Election Perpをロング（買い）またはショート（売り）することができます。 +* 契約価格をインデックスに一致させるため、ロング保有者とショート保有者の間で定期的なファンディングペイメントが発生します。 + +Expiry Futuresでは、清算価格と決済価格を追跡するためにMark Priceが必要です。Mark Priceは通常、原資産のスポット価格に基づいているため、インデックス価格が一般的なOracleフィードに存在しないElection Perpには通常のOracle価格フィードを使用できません。しかし、清算価格を決定するためにはMark Priceが依然として必要です。これを解決するために、Election Perpetual Futuresは独自のOracleフィードをMark Priceとして使用します。 + +### Mark Priceメカニズム + +Injective上のElection PerpのMark Priceは、Storkが提供する独自のOracleフィードに基づいています。2024ELECTION PERPの例では、StorkはPolymarket上の2024年大統領選挙市場の中間値を照会します。その後、Mark Priceの急激な変動を防ぐために6時間のTWAP（時間加重平均価格）を適用します。その価格はより人間が読みやすい形式（すなわち$0から$1の間の価格）にスケールダウンされ、Mark Priceとして使用されます。 + +### マーケット決済 + +Election Perpは満期のある商品ではありませんが、取引ペアにはおおよその存続期間があります（すなわち、選挙の終了時）。Polymarket上の原資産市場が決済に達すると（すなわち、トークン価格が$0または$1に決済される）、利益を得る機会がなくなるため、Election Perpの取引活動はゼロに向かう傾向があります。その時点で、関係者がマーケットを決済するためのガバナンス提案を提出する場合があります。そのような提案が可決された場合、マーケットは決済され、未決済ポジションを持つトレーダーはOracleのMark Price（$0または$1に収束）で強制清算されます。 + +2024ELECTION PERPに関しては、TRUMPWINを原資産として取引ペアが上場されました。2つ以上の資産（すなわち、民主党および共和党の候補者それぞれ）を上場して流動性を分散させるのではなく、1つの資産を上場する決定がなされました。この資産について、前述のPolymarket上の市場がDonald J. Trumpに対して「yes」で決済された場合（すなわち、Donald J. Trumpが2024年大統領選挙に勝利した場合）、Mark Priceは$1に決済され、市場が「no」で決済された場合（すなわち、Kamala Harrisまたは他の候補者が大統領選挙に勝利した場合）、Mark Priceは$0に決済されます。 diff --git a/.gitbook/ja/defi/trading/derivatives-expiry-futures.mdx b/.gitbook/ja/defi/trading/derivatives-expiry-futures.mdx new file mode 100644 index 00000000..557076d4 --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-expiry-futures.mdx @@ -0,0 +1,16 @@ +--- +description: Injective上のExpiry Futuresについて +title: Expiry Futures +--- + +TradFi[^1]において、先物契約とは、二者間で将来の特定の時点に所定の価格で資産を取引することを義務付ける契約です。これにより、トレーダーは原資産の将来の価格を固定してヘッジや価格変動への投機を行うことができます。Injectiveは、このような先物契約を完全に分散化された形で提供しています—それがExpiry Futuresです。 + +Perpetual Futuresと同様に、Injective上のExpiry Futuresはマージンを使用して取引され、トレーダーはレバレッジを利用できます。ただし、Perpetual Futuresとは異なり、Expiry Futuresには満期日があり、ファンディングペイメントは不要です。維持マージン閾値が満たされない場合は、清算が発生する可能性があります。 + +満期時、Expiry Futures市場はOracle Priceを使用して決済され、通常は原資産のスポット価格に設定されます。その結果、先物の価格は満期日が近づくにつれてスポット価格に収束する傾向があります。 + +InjectiveにおけるExpiry Futuresの興味深い活用例として、Pre-Launch Futuresがあります。詳細については続きをお読みください。 + +[^1]: Traditional Finance（伝統的金融） + + diff --git a/.gitbook/ja/defi/trading/derivatives-iassets.mdx b/.gitbook/ja/defi/trading/derivatives-iassets.mdx new file mode 100644 index 00000000..de4ffcda --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-iassets.mdx @@ -0,0 +1,34 @@ +--- +title: iAssets +--- + +iAssetsは、RWA（Real World Asset）デリバティブの新しいクラスであり、株式、コモディティ、FXなどの伝統的市場を、完全にオンチェーン、コンポーザブル、かつ資本効率の高い形でInjective上に実現します。 + +RWAの基本的なトークン化された表現とは異なり、iAssetsは二次的なユーティリティを持つプログラマブルな金融プリミティブです。これは、オフチェーン資産の静的なミラーではなく、以下を実現するために設計されていることを意味します： + +* 動的な流動性配分 +* ポジションベースのエクスポージャー +* クロスマーケットのコンポーザビリティ（例：iAssetsを他のオンチェーンデリバティブやDeFi戦略と組み合わせる） + +iAssetsは、原資産の事前資金調達やラッピングを必要としません。代わりに、Injectiveのオンチェーンのperpetual futuresエンジンと分散型Oracleインフラストラクチャによって駆動される、純粋な合成デリバティブとして存在します。iAssetsの詳細については、[ホワイトペーパー](https://injective.com/iAssets_Paper.pdf)をご参照ください。 + +iAssetsは、他のInjectiveのPerpetual Futures契約と同様に取引されます： + +* マージンはUSDT（またはその他のサポートされたステーブルコイン）で設定されます +* レバレッジが利用可能です（市場によって異なりますが、通常、株式で25倍、コモディティで50倍、FXで100倍です） +* ポジションはUSDTで決済され、現物の受け渡しは行われません +* 清算はInjectiveのオークションベースのメカニズムに従います + +iAssetsと暗号資産のPerpの主な違いは、Mark Priceの挙動にあります。以下の表に違いの概要を示しますが、メンテナンスウィンドウや取引休日については例外があります。 + +| 資産クラス | 価格フィード時間 | 取引時間 | +| ------------------------ | -------------------------------------- | ------------- | +| 暗号資産 | 24/7 | 24/7 | +| iAssets（株式） | 平日9:30 AM ETから4:00 PM ET | 24/7 | +| iAssets（FX/コモディティ） | 日曜6:00 PM ETから金曜5:00 PM ET | 24/7 | + +* iAssetsは、Mark Priceが更新されていない場合でも、Injective上で24/7取引が継続されます。Helixなどのフロントエンドを通じてiAssetsを取引する際には、Oracleの稼働状況をチェックし、潜在的なリスクについて常に警告が表示されます。 +* 市場時間外では、価格フィードは一定に保たれます。Mark Priceが更新されないため、これらの時間帯に清算されることは事実上不可能です。 +* これにより、ユーザーは24時間体制でポジションの取得または解消が可能ですが、PNLは次の価格更新サイクルが再開されるまで変動しません。 + +iAssetsのMark Priceは、Pythなどの分散型Oracleを通じてソーシングされ、プライマリ市場ソースから高精度・低遅延の価格データを集約しています。iAssetsに使用される価格フィードの詳細については、[Pyth](https://docs.pyth.network/price-feeds/market-hours)をご覧ください。 diff --git a/.gitbook/ja/defi/trading/derivatives-index-perpetual-futures.mdx b/.gitbook/ja/defi/trading/derivatives-index-perpetual-futures.mdx new file mode 100644 index 00000000..f261e2c8 --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-index-perpetual-futures.mdx @@ -0,0 +1,19 @@ +--- +title: Index Perpetual Futures +--- + +Index Perpetual Futures契約（Index Perp）は、暗号資産市場で広く使用されているデリバティブ金融商品の一種です。Index Perpは、単一の資産ではなくインデックスの価格を追跡するPerpetual Futures契約です。暗号資産の文脈では、このインデックスは通常、暗号資産のバスケットを表すか、またはBUIDL/USDT Index Perpのケースのように、トークンのスマートコントラクトによって決定されるオンチェーンプロダクトの総供給量を表します。 + +従来の先物契約とは異なり、これらの契約には満期日がなく、無期限に保有することができます。取引はUSDTで決済されます。他のPerpと同様に、Index Perpはファンディングレートメカニズムを使用して、契約価格を原資産のインデックス価格に近い状態に維持します。 + +### Index Perpetual Futuresの仕組み + +* 契約はインデックス（例：BlackrockのBUIDLファンドの総供給量）を追跡します。 +* トレーダーは最大5倍のレバレッジで、インデックスをロング（買い）またはショート（売り）することができます。 +* 契約価格をインデックスに一致させるため、ロング保有者とショート保有者の間で定期的なファンディングペイメントが発生します。 + +Futures契約では、清算価格と決済価格を追跡するためにMark Priceが必要です。Mark Priceは通常、原資産のスポット価格に基づいているため、インデックス価格が一般的なOracleフィードに存在しないIndex Perpには通常のOracle価格フィードを使用できません。しかし、清算価格を決定するためにはMark Priceが依然として必要です。これを解決するために、Index Perpは独自のOracleフィードをMark Priceとして使用します。 + +### Mark Priceメカニズム + +Injective上のIndex PerpのMark Priceは、Storkが提供する独自のOracleフィードに基づいています。BUIDL/USDT Index Perp（NAV（Net Asset Value）Index Perpの一種）の例では、StorkはEthereum上の[スマートコントラクト](https://etherscan.io/token/0x7712c34205737192402172409a8f7ccef8aa2aec)に基づいてBUIDLファンドの総供給量を照会します。その後、Mark Priceの急激な変動を防ぐために1時間のTWAP（時間加重平均価格）を適用します。その価格はより人間が読みやすい形式にスケールダウンされ（実際のNAVは10^5で除算されます。例えば、BUIDLファンドの供給量が5億の場合、BUIDL/USDT Index PERPの価格は5000となります）、Mark Priceとして使用されます。 diff --git a/.gitbook/ja/defi/trading/derivatives-perpetuals.mdx b/.gitbook/ja/defi/trading/derivatives-perpetuals.mdx new file mode 100644 index 00000000..adfb403c --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-perpetuals.mdx @@ -0,0 +1,16 @@ +--- +description: Injective上のPerpetual Futuresについて +title: Perpetuals +--- + +Expiry Futures契約は、二者間で将来の特定の時点に所定の価格で資産を取引することを義務付ける契約であり、トレーダーが原資産の将来の価格を固定してヘッジや価格変動への投機を行うことを可能にします。Injectiveは、このExpiry Futuresだけでなく、Perpetual Futuresも完全に分散化された形で提供しています。 + +Injective上のPerpetual Futuresはマージンを使用して取引され、トレーダーはレバレッジを利用できます。Expiry Futuresとは異なり、Perpetual Futuresには特定の満期日がありません。そのため、ファンディングペイメントが必要となります。また、維持マージン閾値が満たされない場合は清算が発生する可能性があります。Perpetual Futuresは差金決済であり、原資産の受け渡しではなく現金で決済されます。これにより、所定の満期日があり原資産の受け渡しで決済しなければならない従来のExpiry Futures契約よりも柔軟性が高くなります。 + +Injective上では、Perpetual Futures契約はUSDTなどのステーブルコインでマージンが設定されます。そのため、トレーダーは契約を取引するために原資産を所有・保管する必要がありません。また、Perpetual Futuresは従来の先物契約よりも流動性が高く、一般的にスリッページが少なくなります。 + +Perpetual Futuresは、契約価格が原資産の価格に近い状態を維持するためのファンディングメカニズムも使用しています。これによりファンディング手数料が発生する可能性があり、ファンディングレートの不利な側にいるトレーダーが支払います。Perpetual Futures契約の価格が原資産の価格から大きく乖離すると、ファンディングギャップが発生します。ファンディングレートはそのギャップに基づいて計算され、正のレートはロングポジションからショートポジションへ支払われ、負のレートはその逆となります。ファンディングペイメントは通常数時間ごとに交換され、ロングポジションとショートポジションの間で直接決済されます。 + +ファンディングペイメントの目的は、Perpetual Futures契約の価格を原資産（スポット）と一致させるようトレーダーにインセンティブを与えることです。これにより、契約が人為的に過大評価または過小評価されることを防ぎます。 + +InjectiveにおけるPerpetual Futuresの興味深い活用例として、Pre-Launch Perpetual Futuresがあります。詳細については続きをお読みください。 diff --git a/.gitbook/ja/defi/trading/derivatives-pre-launch-futures.mdx b/.gitbook/ja/defi/trading/derivatives-pre-launch-futures.mdx new file mode 100644 index 00000000..7866857b --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives-pre-launch-futures.mdx @@ -0,0 +1,46 @@ +--- +description: 公開前の資産投機 +title: Pre-Launch Futures +--- + +多くの資産は公開ローンチ時に大量の取引活動を生み出しますが、一般的に公開前は取引できません。高まる関心を捉え、投資家が公開リリース前に資産を投機できるようにするため、InjectiveはPre-Launch Futures（PLF）を作成しました。Injective上の最初のPre-Launch Futures市場はExpiry Futures契約に基づいていますが、PLF[^1]はPerpetual Futures契約の形態を取ることもできます。 + +### Pre-Launch Futuresの仕組み + +Expiry Futuresでは、清算価格と決済価格を追跡するためにMark Priceが必要です。Mark Priceは通常、原資産のスポット価格に基づいているため、トークンのローンチ前にはスポット価格が存在しないPre-Launch Futuresには通常のOracle価格フィードを使用できません。Expiry FuturesベースのPLF[^2]は、公開ローンチ日の前後に取引されるよう設計されており、市場の満期日前にスポット価格が存在するようになります（Perpetual FuturesベースのPLF[^3]には適用されません）。これにより、資産が公開取引されると、Mark Priceを公開スポット価格に設定でき、満期時にスポット価格で最終的に決済することが可能になります。ただし、清算価格を決定するために、それ以前にもMark Priceが必要です。 + +これを解決するために、Pre-Launch Futuresは当初、直近24時間の1分ごとの最終取引価格の指数加重移動平均（EWMA）をMark Priceとして使用します。 + +### Mark Priceメカニズム + +Mark Priceは2つの価格フィードに基づいています：1）EWMA（Exponentially Weighted Moving Average）価格フィードと2）CEX API価格フィードです。使用されるCEXは、Binance、OKX、またはBybitのうち、原資産を最初に上場した取引所です。 + +タイムラインの各フェーズにおいて、異なる価格フィードが使用されます。 + +* 資産がCEXに上場される前 → EWMA価格フィード +* 資産がCEXに上場されてから24時間以内 → EWMA価格フィード +* 資産がCEXに上場されてから24時間後 → CEX API価格フィード + +この設計は、EWMA価格フィードとCEX API価格フィードの間に大きな差がある場合に、Mark Priceの急激な歪みを防ぐために使用されます。 + +**EWMA価格の計算に使用される計算式：** + +$$\mathrm{Price_t = \sum \limits_{i=0}^{1439} [(t-i_{minutes} < t_{init} ?\ assumed\ price : last\ traded\ price _{t-i_{minutes}}) \cdot e^{-i/1440} ] \cdot \frac{1-e^{-1/1440} }{ 1-e^{-1}}}$$ + +各変数の説明： + +* `t_init` は、原資産市場における最初の取引時刻です。 +* `assumed price` は、原資産の想定価格です。この価格は、原資産市場における最初の取引から24時間前に `last traded price` が存在しない場合に使用されます。つまり、最初の24時間が経過し、原資産市場で取引が行われた後は、assumed priceはMark Priceに影響を与えなくなります。 + * TIA/USDT Pre Launch Futuresで使用されるassumed priceは `2.5` です。 + * PYTH/USDT PLFで使用されるassumed priceは `0.3` です。 + * JUP/USDT PLFで使用されるassumed priceは `0.55` です。 + * ZRO/USDT PLFで使用されるassumed priceは `5` です。 + * W/USDT PLFで使用されるassumed priceは `2` です。 + * OMNI/USDT PLFで使用されるassumed priceは `40` です。 +* `last traded price` は、原資産市場における最終取引価格です。 + +[^1]: Pre-Launch Futures + +[^2]: Pre-Launch Futures + +[^3]: Pre-Launch Futures diff --git a/.gitbook/ja/defi/trading/derivatives.mdx b/.gitbook/ja/defi/trading/derivatives.mdx new file mode 100644 index 00000000..dd183118 --- /dev/null +++ b/.gitbook/ja/defi/trading/derivatives.mdx @@ -0,0 +1,12 @@ +--- +title: デリバティブ +--- + +Injectiveは複数のデリバティブ取引をネイティブでサポートしています： + +* [Perpetual](./derivatives-perpetuals.md) +* [Expiry Futures](./derivatives-expiry-futures.md) +* [Election Perpetual](./derivatives-election-perpetual.md) +* [Pre-Launch Futures](./derivatives-pre-launch-futures.md) +* [Index Perpetual Futures](./derivatives-index-perpetual-futures.md) +* [iAssets](./derivatives-iassets.md) diff --git a/.gitbook/ja/defi/trading/fees.mdx b/.gitbook/ja/defi/trading/fees.mdx new file mode 100644 index 00000000..08482225 --- /dev/null +++ b/.gitbook/ja/defi/trading/fees.mdx @@ -0,0 +1,13 @@ +--- +title: 取引手数料とリベート +--- + +Injective上のすべての取引は手数料リベートの対象となります。手数料受取人は、取引がmakerまたはtakerフローであるかに関係なく、常に取引手数料の一律40%を受け取ります。注文を発信するRelayerは手数料受取人を設定できます。そのため、APIトレーダーが自分のアドレスを手数料受取人として設定すると、その40%はトレーダーのbank（サブアカウント0）アドレスに送られます。HelixなどのExchange dAppで取引が行われた場合、その40%の手数料はそのExchange dAppが手数料受取人として設定したアドレスに送られます。 + +maker取引の場合、一部のペアの取引手数料は現在マイナスです（このページの残りの部分では-0.01%を例として使用します）。これは60%がmakerに、40%が手数料受取人に分配されます（HelixなどのExchange dAppでは、そのdAppが設定したアドレスに送られます）。そのため、取引価値の0.006%がmakerに、0.004%が手数料受取人にリベートされます。自分を手数料受取人として設定した取引の場合、makerはこれらのペアに対して-0.01%の手数料の全額を受け取ります。 + +例えば、トレーダーが1 BTC/USDT PERPを$50,000で購入する指値注文を出したとします。この指値注文がmakerフローを構成する場合、-0.01%のmaker取引手数料の対象となります。この取引がHelixで行われた場合、手数料受取人はトレーダー自身のbankアドレスではありません。そのため、この取引の手数料リベートは$50,000 * 0.0001 * 0.6 = $3です。しかし、この取引がセルフリレーで行われた場合、手数料リベートは$5（$50,000の-0.01%全額）となります。 + +トレーダーが1 BTC/USDT PERPの成行買い注文を出したとします。この注文はtakerフローを構成するため、トレーダーはマイナスのmaker取引レートの対象ではなく、少額の手数料を支払います（このページの残りの部分では0.05%を例として使用します）。BTCが$50,000の場合、この取引手数料は$25です。この$25のうち、$10（40%）が手数料受取人に送られます。この取引がセルフリレーで行われた場合、その$10を受け取り、実効取引手数料は$15に下がり、実効取引手数料率は0.03%となります。 + +上記の例のトレーダーが[ティアー4ステータス](https://helixapp.com/fee-discounts)を持っている場合、taker手数料は20%割引され、同じ取引の取引手数料は$20になります。この$20のうち$8が手数料受取人としてのトレーダー自身のアドレスに送られ、実効取引手数料率は0.024%または$12となります。 diff --git a/.gitbook/ja/defi/trading/index.mdx b/.gitbook/ja/defi/trading/index.mdx new file mode 100644 index 00000000..b058f68f --- /dev/null +++ b/.gitbook/ja/defi/trading/index.mdx @@ -0,0 +1,8 @@ +--- +title: トレーディング +--- + +* [注文タイプ](/ja/defi/trading/order-types/) +* [取引手数料とリベート](/ja/defi/trading/fees/) +* [マージン取引](/ja/defi/trading/margin/) +* [デリバティブ](/ja/defi/trading/derivatives/) diff --git a/.gitbook/ja/defi/trading/margin-funding-rates.mdx b/.gitbook/ja/defi/trading/margin-funding-rates.mdx new file mode 100644 index 00000000..4b861505 --- /dev/null +++ b/.gitbook/ja/defi/trading/margin-funding-rates.mdx @@ -0,0 +1,44 @@ +--- +title: "ファンディングレート" +--- + +マージン取引は利益を拡大する可能性を提供する一方で、ファンディング要件という新たな複雑さも伴います。マージン要件の影に隠れがちですが、ファンディングレートを理解することは、Helixでの責任あるレバレッジ取引にとって不可欠です。 + +**ファンディングレートとは？** + +従来の先物契約では、取引所における価格は時間の経過とともにスポット価格に収束します。一方、Injective上のPerpetual Futuresには満期がないため、契約価格と原資産のスポット価格との間に乖離が生じる可能性があります。これらの価格を同期させるために、ファンディングペイメントと呼ばれるメカニズムが機能します。 + +ファンディングレートとは、本質的にロングポジションとショートポジションの間で定期的に交換される手数料です。これらの支払いの方向は、市場の全体的なセンチメントに依存します： + +- **正のファンディングレート：**大多数のトレーダーがロングの場合、ロングポジションがショートポジションにファンディング手数料を支払います。これにより、契約価格をスポット価格に近づける取引活動が促進されます。 +- **負のファンディングレート：**逆に、大多数のトレーダーがショートの場合、ロングポジションがショートポジションからファンディング手数料を受け取ります。これにより、契約価格をスポット価格に向けて上昇させる取引活動が促進されます。 + +ファンディングレートの具体的な計算は、契約価格とインデックス価格（スポット価格を表す参照値）の差に加え、金利要素を考慮した計算式に基づきます。これらのレートは一見すると小さく見えるかもしれませんが、時間の経過とともに蓄積され、取引体験に大きな影響を与える可能性があります。 + +**ロングポジション保有者**にとって、正のファンディングレートは追加コストを意味します。各ファンディング間隔（例：毎時0分）ごとにショートポジションへファンディング手数料を支払うことになります。逆に、負のファンディングレートの場合は支払いを受け取り、オープンポジションから本質的にパッシブインカムを得ることになります。 + +**ショートポジション保有者**にとっては、ファンディングのダイナミクスが逆転します。正のファンディングレートは収入源となり、負のファンディングレートはロングポジションに対する定期的な支払いとなります。そのため、潜在的なファンディングコストをマージン計算やリスク管理戦略に組み込むことが極めて重要です。 + +## ファンディングの計算方法 + +ファンディングは以下のように計算されます：$\mathrm{FundingRate = cap(TWAP + HourlyInterestRate)}$ + +_ここで_ $\mathrm{TWAP = \frac{Cumulative\ Price}{(LastTimestamp + 3600 - NextFundingTimestamp)*24}}$ + +また、_Cumulative Price_ は以下に記述されるように、直近の取引価格とMark Priceの差分の累積です。システムは常に _Premium_ を計算しており、これは契約がMark Priceからどの程度乖離して取引されているかを表します。これはパーセンテージ差として計算されます： + +$\text{Premium} = \frac{\text{Trade Price} - \text{Mark Price}}{\text{Mark Price}}$ + +ここで _Trade Price_ は特定のブロック内の取引の出来高加重平均価格（VWAP）です。 + +この値を使用して、_Cumulative Price_ が1時間を通じて蓄積されます。各取引が発生するたびに、現在の _Premium_ に最後の更新からの経過時間（秒単位）を乗じます： + +$\text{New Cumulative Price} = \text{Old Cumulative Price} + (\text{Premium} \times \Delta t)$ + +**例：** + +INJ/USDT PERPで10,000 USDTの想定元本をロングしている場合（レバレッジに関係なく）、ファンディングレートが+0.02%であれば、毎時0分に2 USDTのファンディング支払いを行います。逆に、同じファンディングレートで10,000 USDTの想定元本をショートしている場合、2 USDTのファンディング支払いを受け取ります。 + +BTC/USDT PERPで20,000 USDTの想定元本をショートしており、ファンディングレートが-0.0035%の場合、毎時0分に0.7 USDTのファンディング支払いを行います。逆に、同じ金額をロングしている場合、0.7 USDTのファンディング支払いを受け取ります。 + +なお、極端な価格変動が発生するまれなケースでは、Helixに表示される推定ファンディングレートと、毎時0分に実際に課金されるファンディング手数料との間にわずかな差異が生じる場合があります。 diff --git a/.gitbook/ja/defi/trading/margin-liquidation.mdx b/.gitbook/ja/defi/trading/margin-liquidation.mdx new file mode 100644 index 00000000..b1c2f70a --- /dev/null +++ b/.gitbook/ja/defi/trading/margin-liquidation.mdx @@ -0,0 +1,42 @@ +--- +title: 清算 +--- + +マージン取引のレバレッジを活用することには、清算のリスクが伴います。このメカニズムはトレーダーとDEXの両方の安全装置として機能し、エクイティが臨界閾値を下回ったときに自動的にポジションをクローズします。これは、さらなる損失を防ぎ、システムの安定性を保護するために行われます。 + +清算は、アカウントの維持マージンが一定のレベルを下回ったときにトリガーされます。この維持マージンは契約総額の一定割合であり、通常、最初に預け入れた初期マージンより低く設定されています。価格変動に対するバッファーとして機能します。 + +**維持マージン要件** + +マージンは _Margin ≥ InitialMarginRatio * Price * Quantity_ を満たす必要があります。例えば、最大20倍のレバレッジがある市場では、初期マージン比率は0.05となります。新しいポジションは、その想定元本の少なくとも5%のマージンを持ちます。 + +マージンはMark Price要件を満たす必要があります： + +_Margin ≥ Quantity * (InitialMarginRatio * MarkPrice - PNL)_ + +PNLは、現在のMark Priceでポジションをクローズした場合の予想損益です。Mark Priceについて解くと： + +* 買いの場合：_MarkPrice ≥ (Margin - Price * Quantity) / ((InitialMarginRatio - 1) * Quantity)_ +* 売りの場合：_MarkPrice ≤ (Margin + Price * Quantity) / ((InitialMarginRatio + 1) * Quantity)_ + +アクティブなポジションのライフサイクルを通じて、以下のマージン要件が満たされない場合、ポジションは清算の対象となります。（注：表記の簡素化のため、ファンディングなしと仮定します。） + +* ロングの場合：_Margin ≥ Quantity * MaintenanceMarginRatio * Mark Price - (MarkPrice - EntryPrice)_ +* ショートの場合：_Margin ≥ Quantity * MaintenanceMarginRatio * Mark Price - (EntryPrice - MarkPrice)_ + +例えば、Bitcoin先物契約（$100,000相当）に10%のマージンを使用したとします。初期マージンは$10,000、維持マージンは5%（$5,000）です。Bitcoinの価格が大幅に下落し、契約におけるエクイティが$5,000を下回った場合、ポジションは自動的に清算されます。 + +**清算の仕組み** + +清算がトリガーされると： + +1. **取引所がポジションを強制的にクローズします。**これは、現在の市場価格に関係なく、先物契約を売却することを意味します。 +2. **売却代金は、プラットフォームへの未払い債務をカバーするために使用されます。**これには初期マージン、未払いのファンディング手数料、およびポジションで発生した損失が含まれます。 +3. **残余資金はアカウントに戻されます。**ただし、清算により初期マージンの預け入れ全体を失う可能性があることを忘れないでください。 + +清算を避けるために： + +* **マージンを監視する：**アカウントのマージンレベルとポジションに影響を与える市場の動きを常に注視してください。 +* **ストップロス注文を使用する：**これらの事前設定注文は、価格が一定のポイントに達したときに自動的にポジションを売却し、損失を最小限に抑え、清算を防止する可能性があります。 +* **十分なマージンを維持する：**ポジションの過度なレバレッジを避けてください。高いマージンは価格変動に対するより大きなバッファーを提供します。 +* **ファンディングレートを理解する：**特にボラティリティの高い市場では、潜在的なファンディングコストをリスク管理計算に組み込んでください。 diff --git a/.gitbook/ja/defi/trading/margin-performing-liquidations.mdx b/.gitbook/ja/defi/trading/margin-performing-liquidations.mdx new file mode 100644 index 00000000..55f67d25 --- /dev/null +++ b/.gitbook/ja/defi/trading/margin-performing-liquidations.mdx @@ -0,0 +1,77 @@ +--- +title: 清算の実行 +--- + +このガイドでは、Injective上のトレーダーが `MsgLiquidatePosition` 関数を使用して、担保不足のポジションを清算する方法について詳しく説明します。 + +**続行する前に、以下の内容を理解してください：** + +* **清算メカニズム：** Injectiveは動的な清算メカニズムを採用しており、特定の担保比率を超えた（すなわち閾値を下回った）ポジションは、あらゆるマーケット参加者による清算の対象となります。清算を実行することには報酬がありますが、相当な初期資本が必要です。 +* **MsgLiquidatePosition関数：** この関数により、トレーダーは対象となるポジションの清算を開始し、清算手数料を獲得する機会を得ることができます。 + +**清算のケース：** + +ポジションの状態に応じて2つの異なるケースがあります。いずれの場合も、ポジション全体の清算が必要です。 + +#### 1) ポジションのエクイティが正またはゼロの場合 + +ポジションは、最悪価格を破産価格に設定した成行注文で売却されます。ポジション全体を破産価格を最悪価格として清算できない場合にのみ、清算者は指値注文を送信する必要があります。 + +**メリット** + +* ポジションが破産していない場合、保険基金への損失がゼロであることが保証されます。 +* 既存のオーダーブックの流動性が使用され、清算者は破産価格までの潜在的なディスカウント（裁定取引）によって清算を行うインセンティブを維持します。 + +**デメリット** + +* 破産価格での引き受けは、特にMark Priceが破産価格に非常に近い場合、清算者にとって十分に魅力的でない可能性があります。 + * この懸念は、Injectiveに現在存在するように、少なくとも1人の「ホワイトナイト」清算者が常に存在すると仮定すれば軽減されます。 + +**例** + +維持マージン比率5%の市場における以下のロングポジションを考えてみましょう。 + +
数量エントリー価格マージン清算価格破産価格
11028.428
+ +このポジションは、$8 ≤ Oracle Price ≤ $8.42 の場合に清算可能であり、エクイティが非負です。 + +清算者は、最悪価格$8の成行注文でオーダーブック上でポジションを売却できる場合に清算を実行できます。 + +清算者は、清算に参加したい場合は独自の注文を提出することもできますが、オーダーブックに十分な流動性がある場合は必須ではありません。オーダーブックに十分な流動性がない場合は、清算者が清算の一部として使用される独自の注文（価格は$8以上でなければならない）を提出する必要があります。 + +#### 2) ポジションのエクイティが負の場合 + +ポジションは、最悪価格をOracle Priceに設定した成行注文で売却されます。ポジション全体をOracle Priceを最悪価格として清算できない場合にのみ、清算者は指値注文を送信する必要があります。 + +**メリット** + +* 保険基金が極端な価格でのポジションの成行売却による制御不能な損失を被ることがありません。代わりに、保険基金はOracle Priceの変動に基づいてのみ資本を失います。 + +**デメリット** + +* 正のエクイティの場合と同様（ただしさらに悪い状況）、Oracle Priceでのポジションの引き受けは、暗黙の裁定取引がないため、清算者にとってまったく魅力的でない可能性があります。これにより清算が遅延する可能性があります。 + +**例** + +以下のロングポジションを考えてみましょう。 + +
数量エントリー価格マージン清算価格破産価格
11028.428
+ +このポジションは、Oracle Price < $8 の場合にエクイティが負になります。Oracle Priceが$7.50と仮定します。 + +清算者は、最悪価格$7.50の成行注文でオーダーブック上でポジションを売却できる場合に清算を実行できます。 + +上記のケースと同様に、清算者は清算に参加したい場合は独自の注文を提出することもできますが、オーダーブックに十分な流動性がある場合は必須ではありません。オーダーブックに十分な流動性がない場合は、清算者が清算の一部として使用される独自の注文（価格は$7.50以上でなければならない）を提出する必要があります。 + +**ポジションの清算手順：** + +1. **清算可能なポジションの特定：** Injectiveの `LiquidablePositions` エンドポイントを使用して、担保比率が清算閾値を下回るポジションを特定します。関連するデータポイントは以下の通りです： + + * **担保：** ポジションの担保として預け入れられたトークンの合計価値。 + * **負債：** ポジション内で借り入れたトークンの合計価値。 + * **清算閾値：** 清算を回避するために必要な最低担保比率。 + + 例として、[Go用はこちら](https://github.com/InjectiveLabs/sdk-go/blob/master/examples/exchange/derivatives/20_LiquidablePositions/example.go)、[Python用はこちら](https://github.com/InjectiveLabs/sdk-python/blob/master/examples/exchange_client/derivative_exchange_rpc/23_LiquidablePositions.py)をご参照ください。 +2. **清算トランザクションの準備：** `MsgLiquidatePosition` 関数を使用して注文トランザクションを構築し、[APIドキュメント](https://api.injective.exchange/?python#derivatives-msgliquidateposition)に記載されたパラメータを指定します。必須ではありませんが、成行注文よりも指値注文の使用を強く推奨します。 + +清算の実行には指値注文が必要です。これらの手順に従い、上述の要因を考慮することで、マーケットメーカーは `MsgLiquidatePosition` 関数を効果的に活用し、Injectiveの清算メカニズムに参加して潜在的な利益機会を獲得することができます。 diff --git a/.gitbook/ja/defi/trading/margin.mdx b/.gitbook/ja/defi/trading/margin.mdx new file mode 100644 index 00000000..b41f0a0d --- /dev/null +++ b/.gitbook/ja/defi/trading/margin.mdx @@ -0,0 +1,31 @@ +--- +title: マージン取引 +--- + +Injectiveの複数の先物タイプはマージン取引を伴います。マージン取引とは、特定の先物契約を取引する際に、潜在的なリターンとリスクを増幅させるために借入資本を使用することと定義されます。ただし、マージン取引は利益と同様に損失も増幅させる可能性があるため、始める前にリスクを理解することが重要です。 + +本質的に、マージン取引により、自分の資本だけでは通常制御できないより大きなポジションを先物契約で制御できます。これは資本を借り入れることで実現され、原資産の将来の価格にレバレッジをかけた賭けを行います。 + +**仕組み：** + +1. **マージンを預け入れる：**契約総額の一部を初期マージンとして預け入れます。この預け入れは、Injectiveでは通常USDT建てであり、借入資本の担保となります。 +2. **より大きなポジションを制御：**初期マージンで、はるかに高い想定元本の先物契約を制御できます。例えば、Bitcoin先物契約の価値が$100,000でマージン要件が10%の場合、$10,000を預け入れるだけで契約全体を制御できます。 +3. **利益と損失の増幅：**原資産の価格変動は、ポジションに対して拡大されます。価格が有利に動けば、原資産を単純に保有する場合と比べて利益が倍増します。逆に、価格が不利に動けば、損失も増幅され、価格が大幅に下落した場合、初期マージンが全額失われる可能性があります。 + +**マージン要件の理解：** + +先物契約に必要なマージンの量は、以下のような複数の要因によって異なります： + +* **原資産のボラティリティ：**ボラティリティの高い資産は通常、より高いマージンが必要です。 +* **契約条件：**同じ資産の異なる先物契約は、異なるマージン要件を持つ場合があります。 +* **取引所またはクリアリングハウス：**各取引所またはクリアリングハウスが独自のマージン要件を設定する場合があります。 + +マージン取引は万人向けではないことを忘れないでください。市場とリスク管理技術の深い理解が必要なハイリスクな戦略です。大きな損失の可能性に不安がある場合は、従来の取引方法に留めるのが最善です。 + +**Helixでのマージン取引を検討する際の追加の注意事項：** + +* **清算：**原資産の価格が不利に動き、マージンが一定の閾値（維持マージン）を下回った場合、損失をカバーするためにポジションが清算されます。初期マージンの預け入れ全体を失う可能性があります。 +* **ファンディングレート：**場合によっては、レバレッジポジションを維持するために支払われる手数料であるファンディングレートが請求される場合があります。これらの手数料は市場状況によって異なり、利益を圧迫する可能性があります。 +* **リスク管理：**マージン取引の際は、ストップロス注文やその他のリスク管理ツールを常に使用して、潜在的な損失を制限してください。 + +マージン取引は経験豊富なトレーダーにとって強力なツールとなり得ますが、責任を持って使用し、リスクを明確に理解した上で利用することが重要です。Injectiveでのマージン取引を検討する場合は、十分な調査を行い、失っても問題ない資本でのみ取引してください。 diff --git a/.gitbook/ja/defi/trading/order-types.mdx b/.gitbook/ja/defi/trading/order-types.mdx new file mode 100644 index 00000000..6aa2e465 --- /dev/null +++ b/.gitbook/ja/defi/trading/order-types.mdx @@ -0,0 +1,22 @@ +--- +description: Injectiveの注文タイプについて +title: 注文タイプ +--- + +以下は、Injectiveでサポートされている注文タイプの一覧です： + +* **BUY (1)：**現在の市場価格または指定した指値価格で資産を購入する標準的な買い注文です。Injectiveの成行注文には、注文が執行される市場価格の上限を設定する価格もあります。 +* **SELL (2)：**現在の市場価格または指定した指値価格で資産を売却する標準的な売り注文です。Injectiveの成行注文には、注文が執行される市場価格の上限を設定する価格もあります。 +* **STOP\_BUY (3)：**ストップロス買い注文は、Oracle価格が指定されたトリガー価格に達するか超えると、通常の買い注文に変換されます。 +* **STOP\_SELL (4)：**ストップロス売り注文は、Oracle価格が指定されたトリガー価格以下に下落すると、通常の売り注文になります。 +* **TAKE\_BUY (5)：**テイクプロフィット買い注文は、Oracle価格が指定されたトリガー価格に達するか超えると、通常の買い注文に変換されます。 +* **TAKE\_SELL (6)：**テイクプロフィット売り注文は、Oracle価格が指定されたトリガー価格以下に下落すると、通常の売り注文になります。 +* **BUY\_PO (7)：**Post-Only買い。この注文タイプは、注文がオーダーブックにのみ追加され、既存の注文とマッチしないことを保証します。あなたがマーケットの「maker」であり、「taker」ではないことを保証します。 +* **SELL\_PO (8)：**Post-Only売り。BUY\_POと同様に、売り注文がオーダーブックに流動性を追加するのみで、既存の注文とマッチしないことを保証します。 +* **BUY\_ATOMIC (9)：**アトミック買い注文は、Frequent Batch Auctions（FBA）をバイパスして即座に執行される成行注文です。スマートコントラクトが即座に取引を執行する必要がある場合を対象としています。グローバルexchangeパラメーターで定義されたより高い手数料が支払われます（現在は通常の取引手数料の2倍）。 +* **SELL\_ATOMIC (10)：**アトミック売り注文はBUY\_ATOMICと同様で、FBAをバイパスして現在の市場価格で即座に執行されます。 + +補足： + +* **Immediate-Or-Cancel (IOC)：**IOC注文はまだサポートされていません。最も近い注文タイプは成行注文（**BUY**）です。 +* 成行注文の最悪値価格は「price」パラメーターです。 diff --git a/.gitbook/ja/defi/transaction-fees.mdx b/.gitbook/ja/defi/transaction-fees.mdx new file mode 100644 index 00000000..cb0120e1 --- /dev/null +++ b/.gitbook/ja/defi/transaction-fees.mdx @@ -0,0 +1,48 @@ +--- +title: GasとFee +--- + +## GasとFee + + +Injectiveにおける`Gas`と`Fee`の違いについて学びましょう。 + +前提知識 → [Cosmos SDK Gas](https://docs.cosmos.network/main/build/modules/auth#gas--fees) + + +Gasは、ステートマシン上で特定の操作を実行するために必要な計算量を表します。 + +InjectiveはGasの概念を利用して、実行中の操作のリソース使用量を追跡します。Injective上の操作は、チェーンのストアに対する読み取りまたは書き込みとして表現されます。 + +Feeはメッセージ実行中にユーザーに計算され、請求されます。このFeeは、メッセージ実行で消費されたすべてのGasの合計から計算されます： + +``` +fee = gas * gas price +``` + +Gasは、操作に過剰な計算能力が必要とならないようにし、悪意のあるユーザーによるネットワークスパムを防止するために使用されます。 + + +**最低Gas価格：**バリデーターによって設定された最低Gas価格は現在`160,000,000inj`です。`inj`で支払われる金額を求めるには、Gas価格にGas量を掛けて1e18で割ります（INJは18桁の小数を持ちます）。 + +**例：**`gasWanted`が104,519の場合、`gasFees` = 160,000,000 \* 104,519 / 1e18 = 0.000016723`inj` + + +### Cosmos SDK `Gas` + +Cosmos SDKでは、Gasはメインの`GasMeter`と`BlockGasMeter`で追跡されます： + +* `GasMeter`：状態遷移につながる実行中に消費されたGasを追跡します。トランザクション実行ごとにリセットされます。 +* `BlockGasMeter`：ブロック内で消費されたGasを追跡し、Gasが事前に定義された制限を超えないようにします。この制限はTendermintコンセンサスパラメーターで定義され、ガバナンスパラメーター変更プロポーザルを通じて変更できます。 + +Cosmos SDKにおけるGasの詳細については、[こちら](https://docs.cosmos.network/main/learn/beginner/gas-fees)をご覧ください。 + +Cosmosでは、トランザクションによってトリガーされない操作でも状態遷移を引き起こすことがあります。具体的な例としては、`BeginBlock`と`EndBlock`の操作、およびトランザクションからの状態遷移を実行する前にストアの読み取りと書き込みを行う可能性のある`AnteHandler`チェックがあります。 + +#### `BeginBlock`と`EndBlock` + +これらの操作はTendermint CoreのApplication Blockchain Interface（ABCI）によって定義され、各Cosmos SDKモジュールによって定義されます。名前が示すように、それぞれブロック処理の開始時と終了時に実行されます（つまり、トランザクション実行の前と後）。 + +#### `AnteHandler` + +Cosmos SDK [`AnteHandler`](https://docs.cosmos.network/v0.45/modules/auth/03_antehandlers.html)は、トランザクション実行前に基本的なチェックを行います。これらのチェックは通常、署名検証、トランザクションフィールドの検証、トランザクション手数料などです。 diff --git a/.gitbook/ja/defi/transactions.mdx b/.gitbook/ja/defi/transactions.mdx new file mode 100644 index 00000000..11d884a0 --- /dev/null +++ b/.gitbook/ja/defi/transactions.mdx @@ -0,0 +1,21 @@ +--- +title: トランザクション +--- + +ユーザーがInjectiveとやり取りして状態変更を行いたい場合、トランザクションを作成します。トランザクションが作成されると、特定の状態変更を開始するアカウントに関連付けられた秘密鍵からの署名が必要です。署名後、トランザクションはInjectiveにブロードキャストされます。 + +ブロードキャストされ、すべての検証（署名検証、値の検証など）を通過した後、トランザクションはコンセンサスプロセスを通じてネットワークの承認を受けるブロックに含まれます。 + +### メッセージ + +簡単に言えば、メッセージはInjectiveに対して望む状態変更についての指示です。メッセージはモジュール固有のオブジェクトであり、それが属するモジュールのスコープ内で状態遷移をトリガーします。すべてのトランザクションには少なくとも1つのメッセージが必要です。 + +**さらに、同じトランザクション内に複数のメッセージをパックすることができます。**各モジュールで利用可能なメッセージは、[Native開発者](/developers-native)セクションで確認できます。 + +### トランザクションコンテキスト + +メッセージに加えて、すべてのトランザクションにはコンテキストがあります。コンテキストには`fees`、`accountDetails`、`memo`、`signatures`などが含まれます。 + +### トランザクションフロー + +Injectiveにブロードキャストしたいすべてのトランザクションは同じフローに従います。フローは、トランザクションの準備、署名、ブロードキャストの3つのステップで構成されます。トランザクションがブロックに含まれると、メッセージを使用して指定された状態変更がInjectiveに適用されます。 diff --git a/.gitbook/ja/defi/wallet/accounts.mdx b/.gitbook/ja/defi/wallet/accounts.mdx new file mode 100644 index 00000000..b369f48d --- /dev/null +++ b/.gitbook/ja/defi/wallet/accounts.mdx @@ -0,0 +1,121 @@ +--- +title: アカウント +--- + +このセクションでは、Injectiveの組み込みアカウントシステムについて説明します。 + + +このドキュメントでは、Injectiveの組み込みアカウントシステムについて説明します。 + +前提知識： + +* [Cosmos SDK Accounts](https://docs.cosmos.network/main/basics/accounts) +* [Ethereum Accounts](https://ethereum.org/en/whitepaper/#ethereum-accounts) + + +Injectiveは、EthereumのECDSA secp256k1曲線を使用するカスタム`Account`タイプを定義しています。これは、完全な[BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki)パスのための[EIP84](https://github.com/ethereum/EIPs/issues/84)を満たします。InjectiveベースのアカウントのルートHDパスは`m/44'/60'/0'/0`です。 + +### アドレスと公開鍵 + +Injectiveでは、デフォルトで3種類の`Addresses`/`PubKeys`が利用可能です： + +* **アカウント**用のアドレスと鍵。ユーザー（つまり`message`の送信者）を識別します。**`eth_secp256k1`**曲線を使用して導出されます。 +* **バリデーターオペレーター**用のアドレスと鍵。バリデーターのオペレーターを識別します。**`eth_secp256k1`**曲線を使用して導出されます。 +* **コンセンサスノード**用のアドレスと鍵。コンセンサスに参加するバリデーターノードを識別します。**`ed25519`**曲線を使用して導出されます。 + +| | アドレス bech32 プレフィックス | Pubkey bech32 プレフィックス | 曲線 | アドレスバイト長 | Pubkeyバイト長 | +| ------------------ | --------------------- | -------------------- | --------------- | ------------------- | ------------------ | +| アカウント | `inj` | `injpub` | `eth_secp256k1` | `20` | `33`（圧縮） | +| バリデーターオペレーター | `injvaloper` | `injvaloperpub` | `eth_secp256k1` | `20` | `33`（圧縮） | +| コンセンサスノード | `injvalcons` | `injvalconspub` | `ed25519` | `20` | `32` | + +### クライアント向けアドレスフォーマット + +`EthAccount`は、EthereumのWeb3ツールとの互換性のために、[Bech32](https://en.bitcoin.it/wiki/Bech32)フォーマットとhexフォーマットの両方で表現できます。 + +Bech32フォーマットは、CLIおよびRESTクライアントを通じたCosmos-SDKクエリとトランザクションのデフォルトフォーマットです。hexフォーマットは、Cosmos `sdk.AccAddress`のEthereum `common.Address`表現です。 + +* アドレス（Bech32）：`inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku` +* アドレス（[EIP55](https://eips.ethereum.org/EIPS/eip-55) Hex）：`0xAF79152AC5dF276D9A8e1E2E22822f9713474902` +* 圧縮公開鍵：`{"@type":"/injective.crypto.v1beta1.ethsecp256k1.PubKey","key":"ApNNebT58zlZxO2yjHiRTJ7a7ufjIzeq5HhLrbmtg9Y/"}` + +Cosmos CLIまたはRESTクライアントを使用してアカウントアドレスをクエリできます： + +```bash +# 注：--output (-o) フラグは出力フォーマットをJSONまたはYAML（テキスト）で定義します +injectived q auth account $(injectived keys show -a) -o text +| + '@type': /injective.types.v1beta1.EthAccount + base_account: + account_number: "3" + address: inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku + pub_key: null + sequence: "0" + code_hash: xdJGAYb3IzySfn2y3McDwOUAtlPKgic7e/rYBF2FpHA= +``` + +```bash +# GET /cosmos/auth/v1beta1/accounts/{address} +curl -X GET "http://localhost:10337/cosmos/auth/v1beta1/accounts/inj14au322k9munkmx5wrchz9q30juf5wjgz2cfqku" -H "accept: application/json" +``` + +アカウントAPIの完全なドキュメントについては、[Swagger API](https://lcd.injective.network/swagger/)リファレンスをご覧ください。 + + +Cosmos SDK Keyringの出力（つまり`injectived keys`）は、Bech32フォーマットのアドレスのみをサポートします。 + + +### 秘密鍵/ニーモニックからInjectiveアカウントを導出する + +以下は、秘密鍵および/またはニーモニックフレーズからInjectiveアカウントを導出する例です： + +```js +import { Wallet } from 'ethers' +import { Address as EthereumUtilsAddress } from 'ethereumjs-util' + +const mnemonic = "indoor dish desk flag debris potato excuse depart ticket judge file exit" +const privateKey = "afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890" +const defaultDerivationPath = "m/44'/60'/0'/0/0" +const defaultBech32Prefix = 'inj' +const isPrivateKey: boolean = true /* 例示のため */ + +const wallet = isPrivateKey ? Wallet.fromMnemonic(mnemonic, defaultDerivationPath) : new Wallet(privateKey) +const ethereumAddress = wallet.address +const addressBuffer = EthereumUtilsAddress.fromString(ethereumAddress.toString()).toBuffer() +const injectiveAddress = bech32.encode(defaultBech32Prefix, bech32.toWords(addressBuffer)) +``` + +以下は、秘密鍵から公開鍵を導出する例です： + +```js +import secp256k1 from 'secp256k1' + +const privateKey = "afdfd9c3d2095ef696594f6cedcae59e72dcd697e2a7521b1578140422a4f890" +const privateKeyHex = Buffer.from(privateKey.toString(), 'hex') +const publicKeyByte = secp256k1.publicKeyCreate(privateKeyHex) + +const buf1 = Buffer.from([10]) +const buf2 = Buffer.from([publicKeyByte.length]) +const buf3 = Buffer.from(publicKeyByte) + +const publicKey = Buffer.concat([buf1, buf2, buf3]).toString('base64') +const type = '/injective.crypto.v1beta1.ethsecp256k1.PubKey' +``` + +## サブアカウント + +Injectiveのサブアカウントにより、1つのメインウォレットアドレスで複数の独立した取引アカウントを管理できます。これは、特にプロフェッショナルトレーダーやマーケットメイカーなどのパワーユーザーにとって有用です。 + + +サブアカウントの技術的な実装の詳細については、[Trading Account](/developers/concepts/trading-account)の開発者ドキュメントをご覧ください。 + + +### 主な機能と説明 + +- **プログラマティックアクセス**：この機能は、InjectiveのネイティブAPIを介したプログラマティック取引に対して高いアクセス性を提供するように設計されており、金融アプリケーション開発者に対応しています。 +- **高度なアカウント管理**：サブアカウント機能は、ユーザー（例：機関投資家やアルゴリズムトレーダー）が単一のプライマリInjectiveアドレス内で資金と取引戦略を分離できる高度なアカウント管理機能を提供します。 +- **分離と整理**：あるサブアカウント内の資金と注文は他のサブアカウントから分離されており、リスク管理、異なるトレーディングボットの運用、または異なる戦略の同時適用にとって重要です。 +- **シームレスな転送**：ユーザーは、Injectiveネットワーク上の特定のメッセージを使用して、メインアカウント残高とさまざまなサブアカウント間、および異なるサブアカウント間で資産を簡単に転送できます。 +- **Exchangeモジュールとの統合**：サブアカウント機能はInjectiveのコアexchangeモジュールの一部であり、スポット、パーペチュアル、先物、およびオプション市場向けのオンチェーンオーダーブックとマッチングエンジンを含みます。 + +サブアカウントは、単一のユーザーアカウントによって制御される、分離されたリンク済みの「ポートフォリオ」のように機能します。これにより、InjectiveのDeFiエコシステムの参加者に柔軟性と運用上の制御が提供されます。 diff --git a/.gitbook/ja/defi/wallet/create.mdx b/.gitbook/ja/defi/wallet/create.mdx new file mode 100644 index 00000000..444839df --- /dev/null +++ b/.gitbook/ja/defi/wallet/create.mdx @@ -0,0 +1,16 @@ +--- +description: さまざまな方法を使用してInjectiveでウォレットを作成する方法を学びます。 +title: ウォレットの作成 +--- + +Injectiveでのウォレット作成は、Injectiveアドレスに資金を送信するだけで簡単に行えます。このドキュメントでは、人気のウォレットソリューション（MetaMask、Ledgerなど）を使用したウォレットの作成方法、およびローカルCLI環境で`injectived`を使用したウォレットの作成と資金供給方法を説明します。 + +### ブラウザウォレット + +お好みのウォレットを使用して、[ブログのチュートリアル](https://injective.com/blog/how-to-create-an-injective-wallet-2/)に従ってInjectiveウォレットを作成できます。 + +### ローカルウォレット + +CLI環境で[injectived](/developers/injectived/)を使用して、開発目的のInjectiveウォレットを作成できます。`injectived keys` [コマンド](/developers/injectived/advanced/#keys)を使用して行えます。 + +`injectived`を使用したkeyring管理の詳細については、[set-up-keyring](/infra/set-up-keyring/)ページもご覧ください。 diff --git a/.gitbook/ja/defi/wallet/index.mdx b/.gitbook/ja/defi/wallet/index.mdx new file mode 100644 index 00000000..82290bed --- /dev/null +++ b/.gitbook/ja/defi/wallet/index.mdx @@ -0,0 +1,47 @@ +--- +title: ウォレット +--- + +Injectiveウォレットを使用すると、Injective上の資産を監視できます。資産は、Injective上のネイティブトークン、およびEthereum、Solana、Polygon、その他のIBC対応チェーンからブリッジされた資産が含まれます。[Injective Hubステーキングウォークスルー](https://injective.com/blog/injective-hub/)をご覧ください。 + +Injectiveでは、さまざまなウォレットがサポートされています。ユーザーは、EthereumまたはCosmosネイティブのウォレットを使用してInjective上でトランザクションを提出できます。 + +### 概要 + +Injectiveの`Account`タイプはEthereumのECDSA secp256k1曲線を使用しています。簡単に言えば、InjectiveのAccountはEthereumのアカウントとネイティブ（互換）であり、MetaMaskなどのEthereumネイティブウォレットがInjectiveとやり取りできます。KeplrやLeapなどの人気のCosmosウォレットもInjectiveと統合されています。 + +#### Ethereumベースのウォレット + +上記のとおり、Ethereumベースのウォレットを使用してInjectiveとやり取りできます。現在、最も人気のEthereumベースのウォレットがInjectiveでサポートされています： + +1. [MetaMask](https://metamask.io/) +2. [Ledger](https://www.ledger.com/) +3. [Trezor](https://trezor.io/) +4. [Torus](https://tor.us/index.html) + +Ethereumネイティブウォレットを使用してInjectiveでトランザクションに署名するプロセスは次のとおりです： + +1. トランザクションをEIP712 TypedDataに変換、 +2. Ethereumネイティブウォレットを使用してEIP712 TypedDataに署名、 +3. トランザクションをネイティブのCosmosトランザクションにパックし（署名を含む）、チェーンにブロードキャスト。 + +このプロセスはエンドユーザーからは抽象化されています。以前にEthereumネイティブウォレットを使用したことがある場合、ユーザーエクスペリエンスは同じです。 + +#### Cosmosベースのウォレット + +Injectiveは、CosmosおよびIBCと互換性のある主要なウォレットをサポートしています： + +1. [Cosmostation](https://cosmostation.io/) +2. [Keplr](https://www.keplr.app/) +3. [Leap](https://www.leapwallet.io/) + +#### Injectiveネイティブウォレット + +現在、[Ninji Wallet](https://ninji.xyz/)が唯一のInjectiveネイティブウォレットです。このウォレットは、Injectiveエコシステムとの相乗効果を得るように特別に設計されています。 + +#### CEXベースのウォレット + +Injectiveをサポートする中央集権型取引所（CEX）が開発したウォレットもいくつかあります。これらのCEXのアクティブユーザーであれば、そのウォレットを使用することで、よりシームレスなWeb3体験を得られます。現在、InjectiveをサポートするCEXベースのウォレットは以下のとおりです： + +1. [Bitget Wallet](https://web3.bitget.com/en/) +2. [OKX Wallet](https://www.okx.com/web3)