本記事は下記の翻訳となります。
『PoL for Developers: Reward Vaults Explained』
Proof of Liquidity は、開発者が BGT リワードを使用してアプリケーションの利用を促進することで、アプリケーションのアクティビティをブートストラップすることを可能にします。開発者は、ユーザーにあらゆるアクションや一連のアクションを取るよう促し、自分のものではない BGT でユーザーに報酬を与えることができます。
PoL では、アプリケーションにプッシュされ、付与される BGT はバリデーターから来ることを思い出してください。バリデーターはブロックを生成するたびに報酬を発行し、cutting board（カッティングボード）を通じて、それらの BGT 報酬をホワイトリストに登録された rewards vaults（報酬ボールト）にどのように分配するかを定義します。
Berachain 上の PoL rewards vault は、バリデーターから BGT を受け取るホワイトリストに登録されたスマートコントラクトです。これは、作成者によって定義された特定の ERC20 トークンをステーキングトークンとして受け入れ、その vault（ボールト）にプッシュされた BGT の比例配分をステーカーに付与します。アプリケーションがその ERC20 トークンを何にするか、そしてエンドユーザーがそのトークンをどのように取得するかを決定します。これにより、開発者がユーザーにどのようにアプリケーションと対話してほしいかを考える上で、大きな創造の余地が残されています。
あらゆるアクションにリワードを
BEX、Bend、Berps という 3 つのアプリケーションを例に挙げ、BGT 獲得が可能な rewards vaults について説明します。
BEX では、ユーザーは適格な LP トークンをホワイトリストに登録された rewards vault に預けることで BGT を獲得できます。各ペア（HONEY-WBERA、HONEY-ETH など）には独自の LP トークンがあるため、それぞれのペアが独自の rewards vault を持つ可能性があります。ただし、バリデーターから BGT を受け取る資格のある rewards vault は一部のペアに限られます。すべての rewards vaults はガバナンスを通じて承認される必要があるため、BEX のプールの一部のみが BGT を獲得できます（すべてが承認されない限り）。BEX は、BGT-earning pool（BGT 獲得可能な各プール）に対して rewards vaults を持ち、各 vault が受け入れる ERC20 は、そのプールの LP トークンです。
Berachain の ネイティブな lending protocol（レンディングプロトコルである Bend では、ユーザーは借り入れた HONEY の量を表す debt token（借入トークン）を預けることで BGT を獲得します。これは Bend によって自動的に処理されます。借り入れるには、ユーザーは受け入れられているトークンの 1 つで担保を預け、それを使って HONEY を借りる必要があります。
Berachain のネイティブな perps platform（パーペチュアル取引プラットフォーム）である Berps では、ユーザーは Berps プラットフォームの担保として使用される vault に流動性を提供することで BGT を獲得できます。この vault はすべての取引の相手方となるため、人々が勝っているときはその価値が下がり、負けているときは価値が上がります。ユーザーが HONEY を vault に預けると、預けた量と同じ量の bHONEY を受け取ります。ユーザーはこの bHONEY トークンを Berps の rewards vault にステークします。
これらの例では、BGT を獲得するアプリケーションはそれぞれ、エンドユーザーが rewards vault にステークする必要のあるトークンを獲得するまでの道筋を柔軟に定義できます。Bex ではプールに流動性を提供する必要があり、Bend では HONEY を借りる必要があり、Berps では vault に流動性を提供する必要があります。これらの例は比較的シンプルですが、ユーザーを様々なアプリケーションのフローを通じて最終的なステーキングトークンにアクセスさせる複雑な道筋も可能です。アプリケーションは今や、バリデーターの BGT を使って、ユーザーに特定の道筋を辿らせることができます！
スマートコントラクトレベルでは、ユーザーが BGT を獲得するために rewards vault にステークするには、特定の ERC20 トークンが必要です。そのトークンをどのように獲得するかは、その rewards vault の作成者に完全に委ねられており、シンプルな一段階のアクションから、ERC20 の claim （請求）で終わる複雑な多段階の道筋まで、幅広く設定できます。
このモデルにより、開発者は特定のアクションを rewards vault でカプセル化でき、一つのアプリケーションが複数の rewards vault を持って、ターゲットとするアクションにインセンティブを与えることができます。これはアクティビティのブートストラップ、より多くの流動性の獲得（より安価に）、そしてユーザーを特定の方法でアプリケーションと対話するよう導く羊飼いの役割を果たすために使用できます。
PoL についてよくある誤解は、プロトコルがガバナンストークンをステーキングトークンとして使用しなければならず、TGE（トークン生成イベント）を行ったプロトコルのみが PoL に参加できるというものです。このモデルでは、トークンはユーザーが特定のアクション（例えば、vault に receipt token（レシートトークン）をステークするなど）を取ったことを証明するために使用されます。これは、独自のネイティブトークンを持たないプロトコルも Proof of Liquidity（PoL）に参加できることを意味します。これらのプロトコルはネイティブのガバナンストークンを持っていなくても、BEX、Bend、Berps と同様に、帳簿管理のための receipt token を発行することができます。
ガバナンストークンと reward vaults の概念を切り離すことで、プロトコルがステーキングトークンを獲得するユーザークエストを設計する際に、無限の創造性を発揮できることがより明確になります。プロトコルは、それぞれ独自のステーキングトークンを持つ複数の reward vaults を実装することもできます。例えば、パーペチュアル取引プロトコルは、特定の資産でロングポジションを取るユーザーに対して 1 つの receipt token を、ショートポジションを取るユーザーに対して別のトークンを発行することができます。この設定により、各資産のロングポジションとショートポジションに対して別々の reward vaults を作成することが可能になります。同様に、アプリケーションは自社のトークンでロングポジションを取るユーザーにインセンティブを与える reward vault を作成する一方で、競合他社のトークンをショートするユーザーに報酬を与える別の vault を設定することもできます。
さらに、プロトコルはマネーマーケットの借入側に reward vault を設定することもできます。例えば、WETH が借入側にある場合、プロトコルは LST ループを収益性のあるものにすることができます。これは、取引所での WETH の借入レートがステーキング利回りからの供給レートよりも高い場合でも可能です。この差が reward vault を通じて提供されるインセンティブよりも小さければ実現可能です。
無料の昼食はありません
Proof of Liquidity は、Berachain 上の開発者に新しい設計空間を開きます。これにより、開発者は報酬の直接的なコストを負担することなく、ユニークでインセンティブ付きのユーザージャーニーを構築できるようになります。バリデーターの BGT 発行を活用することで、開発者は特定の行動を促進し、流動性を向上させ、ユーザーをアプリケーションとのカスタマイズされた対話へと導くことができます。
しかし、このツールには責任が伴います。プロジェクトは BGT ホルダーの投票を獲得して reward vault をホワイトリストに登録し、BGT 発行の対象となるためには、BGT エコシステムに価値をもたらすことを示さなければなりません。
アプリケーションと BGT ホルダーの共生関係により、インセンティブの一致が保たれ、Berachain エコシステムの持続可能な成長の基盤が築かれます。
開発者がユーザーのためにインセンティブ付きのフローを作成できるのは素晴らしいことですが、これは無償で行われるわけではありません。そうでなければ、BGT は単なる補助金トークンになってしまいます。
アプリケーションが BGT 獲得可能な rewards vault を取得するには、BGT ホルダーによって承認されたガバナンスを経る必要があることを思い出してください。アプリケーションは、他の要素とともに、BGT ホルダーにもたらす価値に基づいて評価されます。
BGT ホルダーと共有できる価値の種類を理解するために、BEX、Bend、Berps を例に挙げてみましょう。これら 3 つのアプリケーションはすべて、使用時にユーザーから手数料を徴収し、それを BGT 委任者に分配します。FeeCollector というスマートコントラクトがネイティブ Dapps からこれらの手数料を集め、支払いトークンでオークションにかけ、その後 BGT 委任者に分配します。
開発者は、任意のトークンでの手数料を FeeCollector.sol に送ることで、BGT ステーカーとの手数料共有の背後にある複雑なロジックのアウトソーシングを容易に行うことができます。例えば、NFT プロジェクトであれば、ミント手数料の一定割合を FeeCollector に送り、これを利用してエコシステムの新規ユーザーをミントに参加させ、完全なミントに向けてエコシステムを動機付けることができます。
FeeCollector は効率的市場理論に基づいて機能します。トークンが FeeCollector にダンプされ、いつでも誰かが事前に決められた支払い額を支払えば、特定のトークンの供給量を獲得できます。通常、MEV 関係者が、利益が出るタイミングでトークンを購入するシステムを設定することが予想されます。FeeCollector.sol は、あらゆる種類のトークンをあらゆる量で受け入れ、コントラクトが指定された支払い額に達すると、オークションが発動され、トークンのバスケットが支払いトークン（この場合は HONEY）の支払い額で売却されます。
【Sunrise とは】
Sunrise は Proof of Liquidity(PoL)と Fee Abstraction（手数料抽象化）を備えたデータ可用性レイヤーです。 私たちは DA の体験を再構築し、多様なエコシステムからのモジュラー型流動性を活用してロールアップを立ち上げています。
【Social Links】
【お問合せ】
Sunrise へのお問い合わせはこちらから 👉 Google Form
