メインコンテンツへスキップ

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

このページは AI による自動翻訳です。すべての内容は英語版を正とします。英語版を表示 →

ファームとは何か

ファーム は、スタッキング用トークンをステークするアカウントに 1 つ以上の リワード ミント を配布するスタンドアロンのオンチェーン プログラムです。スタッキング用ミントはほぼ常に CPMM、AMM v4、またはレガシー ペア プールで発行された LP トークンですが、単一資産ファーム (SOL、RAY、またはプロジェクト トークンを直接ステーク) もサポートされており、長期実行されている小数のプログラムで使用されています。 主な特性:
  • 排出ベース、手数料ベースではない。 CLMM の組み込みリワード ストリームとは異なり、ファーム リワードはスワップ取引量またはプール活動に結びついていません。ファームの予算は作成者によって事前に預託され、なくなるまで一定の秒当たりレートで排出されます。
  • プールとは独立している。 プールはファームが存在することを認識しません。ウォレット間で LP を移動してもファームに通知されません。ユーザーは最初に ファームから明示的に Withdraw を実行する必要があります。同様に、プールから Withdraw することはファームから引き出すことはありません。
  • ユーザーあたり、リワードあたりの台帳。 各ステーカーはファーム 1 つあたりの UserStake(または「台帳」)アカウントを保有し、ステーク額とファームの各リワード ストリームのシェアあたりリワード カウンターのスナップショットを追跡します。
  • 複数リワード対応。 ファーム v5 は最大 2 つのリワードをサポート。v6 は最大 5 つをサポートします。各リワードには独自のボルト、秒当たりレート、開始時刻、終了時刻があります。

3 つの運用中バージョン

Raydium は 3 つのファーム プログラム バージョンをリリースしています。すべて運用中であり、各々が独自の PDA スキームと命令セットを持ちます。インテグレーター は、これらを概念モデルを共有する 3 つの異なるプログラムとして扱う必要があります。
バージョンプログラム ID の場所最大リワード数注目すべき相違点
v3reference/program-addresses を参照1最初のスキーマ。最も古いファーム (RAY-USDC、SOL-USDC) は現在でもこれを経由しています。
v5reference/program-addresses を参照22 番目のリワード スロットと AddReward スタイルのトップアップを追加しました。
v6reference/program-addresses を参照5現在のバージョン。スロットを拡張し、管理がシンプルになり、v6 専用アダプターを介した CLMM ポジション ファーミングをサポートします(実際には稀)。
SDK は raydium.farm を単一のファサードとして公開します — バージョンはファーム アカウントのオーナーから推論されます。オンチェーン インテグレーションを構築する場合は、手動でディスパッチする必要があります。

シェアあたりのリワード会計処理

ファーム プログラムは DeFi 利回り契約全体で見られる標準的な「マスターシェフ」パターンを使用しています:
reward_per_share := total_rewards_distributed_by_stream / total_staked
pending(user)    := user.staked × (reward_per_share − user.reward_debt)
  • reward_per_share はファーム アカウントに固定小数点カウンター (v5 以降では Q64.64、v3 では Q56.8) として保存されます。これは常に増加します。
  • user.reward_debt はユーザーの最後のインタラクション時の reward_per_share のスナップショットです。これはユーザーが負う債務ではなく、将来の見積もりを計算するために使用されるオフセットです。
  • Deposit および Withdraw では、ファームは最初に保留中のリワードを決済し(user.pending_reward にクレジットするか、バージョンに応じてユーザーの ATA に直接送信)、その後 user.reward_debt を現在のカウンターに更新します。
  • Harvest では、ファームは pending_reward を支払い、reward_debt を再度スナップショットします。
秒当たりの排出レートは遅延更新を介した会計に入ります:
elapsed        := min(now, reward.end_time) − reward.last_update_time
new_emissions  := reward.per_second × elapsed
if total_staked > 0:
    reward_per_share += new_emissions / total_staked
reward.last_update_time := now
遅延:「秒ごと」に命令は発行されません。カウンターはファームに触れるたびに更新されます(DepositWithdrawHarvest、管理者更新)。アクティビティがないファームは次のインタラクションで閉じられる増加するギャップを蓄積します。

スタッキング用ミント対リワード ミント

スタッキング用ミントはエスクローで保有され、焼却されません。 ユーザーが 100 LP をステークすると、ファームはユーザーの ATA から 100 LP をファームのステーキング ボルトに移動します。Withdraw では、ファームは 100 LP を戻します。ファームはプールを呼び出すことはありません。 リワード ミントは、作成者によって事前に資金提供されたボルトから支払われます。 作成者がファームをセットアップするとき、完全なリワード予算(たとえば、1,000,000 RAY + 500,000 USDC)を 2 つのリワード ボルトに預託します。ファーム プログラムは新しいトークンをミントしません。ストリームの期間にわたってボルト内にあるものを配布するだけです。ボルトが end_time の前に枯渇した場合、排出は停止します。

排出スケジュール

各リワード ストリームには 3 つの時間パラメーターがあります:
  • start_time — 排出が始まる UNIX タイムスタンプ。これ以前は、見積もりはありません。
  • end_time — 排出が停止するタイムスタンプ。その後、このストリームから reward_per_share は増加しません。
  • per_secondstart_time ≤ now < end_time の間の排出レート。
リワードは v5 / v6 で AddReward / SetRewards を介して拡張できます(end_time を前に移動、ボルトをトップアップ)。RestartRewards を介して end_time の後に再開できます。管理者の協力なしに短縮することはできません。

ファームではないもの

  • 手数料ディストリビューターではない。 CPMM と CLMM はプール状態に直接トレード手数料を収集します。ファームはプール手数料に触れません。プール手数料からトークン ホルダーへの唯一の経路は LP 償還または CLMM の CollectFee です。
  • 自動ではない。 ファーム リワードを獲得するには、LP を明示的にステークする必要があります。トークンをウォレットに保有している LP ホルダーはファームから何も獲得しません。
  • 交換可能ではない。UserStake アカウントは 1 つの (farm, user) ペアに結びついています。最初にアンステークしないで別のウォレットにステークを転送することはできません。
  • CLMM ポジションと直接互換性がない。 ファーム v6 は CLMM アダプターを導入しましたが、実際には CLMM プールは独自の組み込みリワード ストリーム(products/clmm/fees を参照)を使用し、ファーム排出は使用しません。

ファームが正しいツールである場合

以下を実行する場合にファームを使用してください:
  • プロジェクトの CPMM または AMM v4 プールの 1 つに対して外部トークン(プロジェクト トークン、パートナーのトークンなど)で LP にインセンティブを与える。
  • 独自のコントラクトをデプロイすることなく、単一資産ミント上でステーキング プログラム(クラシック「RAY をステーク、RAY を獲得」)を実行する。
  • そのプールへの管理者アクセスを必要とせずに、既存のプール上に追加のリワードをレイアウトする。
プールが CLMM である場合は、代わりに CLMM の組み込みリワード ストリームを使用してください。経済的には同等ですが、ポジションのフィー成長内会計に参加し(インレンジ ポジションは必然的に獲得、アウト オブ レンジ ポジションは獲得しない)、ユーザーがポジション NFT を移動する必要はありません。

チャプターの内容

  • accounts — バージョンごとの完全なオンチェーン状態レイアウト。
  • instructions — 各ファーム命令とそのアカウント リスト および前提条件・事後条件。
  • code-demos — ステーキング、ハーベスト、および新しいファームの作成に関する TypeScript の例。

次のステップ

出典: