<100 subscribers
Share Dialog
Share Dialog


Generalized wrapper-token factory (任意のラッパートークンコントラクトとそれを生成するためのコントラクト)の有用性について考えます。
Eng ver.:
https://mirror.xyz/kyoro.eth/4wHrYiOr7QlVOFdK4jMSEMz6yOdWD53QFazEn_acfFQ
Lidoの stETHをはじめとする Liquid Staking Derivatives (LSDs)が台頭してきましたが、それらのDEXでの取り扱いは一工夫必要な課題です。
また、いろいろなものがトークン化されるにあたって、(ほぼ)同じ価値のものでも単位の違いによってそれらの Stableswap AMMでの取り扱いに不都合が生じてくる事例が出てくるでしょう。例えばゴールドに関して、グラムなのかオンスなのか。グラムなのかキログラムなのかさえ違っても問題です。
これらに対し、Generalized wrapper-token factoryはある程度役に立つでしょう。
1000枚の1グラムゴールドトークンを1枚の1キログラムゴールドトークンにしてくれるのがラッパートークンコントラクトです。このようなコントラクトを任意に生成できるようにするのが Generalized wrapper-token factoryです。
あるラッパートークンコントラクトは
ラップ前のトークンアドレス
何対何の比率でラップするのか
を指定することでfactoryから生成されます。
*注: 設計の話をしているだけです。私はコーディングしていません。
Curve v1や Velodromeといった Stableswap AMMは取り扱うトークン同士がほぼ 1:1で交換できることを仮定しています。 1:1000のような取り扱いはできません。つまり会社Aのグラムゴールドトークンと会社Bのキログラムゴールドトークンは単位が違うだけでStableswap AMMで取り扱えなくなってしまいます。
LSDsについてはリベースに対応しているDEXは stETH-ETHの流動性をもつことが可能です。しかしそうではない場合、リベースしないwrapped-stETH (wstETH)を取り扱う必要があります。wstETHは約1 ETHの価値から始まりましたが、ステーキング報酬で単価が上昇していくので、wstETH:ETHは1:1の関係からはずれてきています。執筆時現在ではおおよそ 1:1.11です。

Velodromeの wstETH-ETH系のStapleプールはそのずれを特に気にせず作られているので、在庫を見れば価格の低い WETH (sETH)がwstETHよりも極端に多くなっています。このバランスが崩れた状態はスリッページ耐性も低く非効率です。今後さらにこの状況は悪化していくでしょう。

(しかしある程度はStableプールとして機能しているので、一年おきくらいで ETHと1:1になるような “w”wstETHを作れればいいですよね、というのがこの記事の意図です。)
浮動ペッグステーブルコインのRAIは額面としては 2.77ドル程度ですが、実質ドルステーブルコインです。その長期的な価格トレンドは市場価格(market price)と償還価格(redemption price)の関係性によって変化しますが、昨年中の対ドル価格変化率は8%程度でした。


RAIはStableswap AMMへの統合に関して、「単位の違い」と「LSDsのような利率の影響」の両方が合わさった課題を持っているといえます。
現状の正攻法な対応は1:1に相当するバランス点の解釈をAMM側で随時変更していくことです。
Curve v2は内部で取引実績から価格オラクルを作り、そこへバランス点を徐々に寄せていきます。
https://classic.curve.fi/files/crypto-pools-paper.pdf
BalancerのMetaStable Pool、Gamma (Uniswap v3 manager)、RAI用の改造Curve v1はどれも外部からバランス点の情報を得ます。
https://dev.balancer.fi/resources/deploy-pools-from-factory/creation/metastable-pool
https://docs.gamma.xyz/gamma/features/strategies#pegged-price-pegged
https://github.com/curvefi/curve-contract/pull/144
現状の対応の全てはAMM側でのリバランスを行います。リバランスとは impermanent lossを都度確定させてしまうことを意味します。そのコストは経路依存となり、事前想定ができません。
https://twitter.com/danrobinson/status/1623126635334762496?s=20&t=IIXIvEAiXdqkhmtGtP3Keg
Curve v2のように、獲得した手数料収入の範囲内で(AMMの不変量が成長していくことを担保しながら)少しずつリバランスする、といったルールを策定するのは合理的です。しかし一般ユーザーにこれを理解してもらうのはとても難しいでしょう。
ラッパートークンによる対応はシンプルです。ある時点で1:1が成り立つようにラッパートークンを作り、有効な限りそれを使うというものです。この方法ではAMMによるリバランスがないので、流動性提供者たちは「価格がxxx%変われば impermanent lossが yyy%発生する」といった見通しを得ることができます。
LSDsや RAIは利率が年10%以下であれば、半年から1年くらいは100倍増幅のStableswap AMMを効率的に活用できるでしょう。USD, EURO, JPYといった主要通貨間の Forexにも数ヶ月くらいは活用できそうです。
ことRAIに関しては、1ドルくらいにラップしてあげることで、RAIとはどのような通貨なのかというのを説明するコストが大幅に下がると思います。
ラッパートークンが様々なタイミングで生成されることで流動性は多少断片的になるかもしれませんが、factory contractで indexingをしっかりできるようにしておけば、DEX aggregatorsに「wrapper swap」をうまく統合してもらってなんとかなる気がします。
ラッパートークンはシンプルですが使い所は多いと思うので、それを誰でも簡単に作れるようにする factoryコントラクトはなかなか価値があるのではないかと思います。
1 WBTCから1 WSATとか作れますね。
YFIとWOOFYとかありましたね。
decimalsの処理のケアがちょっと大変でしょうか?
「リベース対応自体もラッパーコントラクトでしてしまえば良いし、他に最新機能も追加できるよね」という指摘がありました。
https://twitter.com/danrobinson/status/1561558549058166785?s=20&t=WiGRAbd71VW09xJl9qnBtw
Generalized wrapper-token factory (任意のラッパートークンコントラクトとそれを生成するためのコントラクト)の有用性について考えます。
Eng ver.:
https://mirror.xyz/kyoro.eth/4wHrYiOr7QlVOFdK4jMSEMz6yOdWD53QFazEn_acfFQ
Lidoの stETHをはじめとする Liquid Staking Derivatives (LSDs)が台頭してきましたが、それらのDEXでの取り扱いは一工夫必要な課題です。
また、いろいろなものがトークン化されるにあたって、(ほぼ)同じ価値のものでも単位の違いによってそれらの Stableswap AMMでの取り扱いに不都合が生じてくる事例が出てくるでしょう。例えばゴールドに関して、グラムなのかオンスなのか。グラムなのかキログラムなのかさえ違っても問題です。
これらに対し、Generalized wrapper-token factoryはある程度役に立つでしょう。
1000枚の1グラムゴールドトークンを1枚の1キログラムゴールドトークンにしてくれるのがラッパートークンコントラクトです。このようなコントラクトを任意に生成できるようにするのが Generalized wrapper-token factoryです。
あるラッパートークンコントラクトは
ラップ前のトークンアドレス
何対何の比率でラップするのか
を指定することでfactoryから生成されます。
*注: 設計の話をしているだけです。私はコーディングしていません。
Curve v1や Velodromeといった Stableswap AMMは取り扱うトークン同士がほぼ 1:1で交換できることを仮定しています。 1:1000のような取り扱いはできません。つまり会社Aのグラムゴールドトークンと会社Bのキログラムゴールドトークンは単位が違うだけでStableswap AMMで取り扱えなくなってしまいます。
LSDsについてはリベースに対応しているDEXは stETH-ETHの流動性をもつことが可能です。しかしそうではない場合、リベースしないwrapped-stETH (wstETH)を取り扱う必要があります。wstETHは約1 ETHの価値から始まりましたが、ステーキング報酬で単価が上昇していくので、wstETH:ETHは1:1の関係からはずれてきています。執筆時現在ではおおよそ 1:1.11です。

Velodromeの wstETH-ETH系のStapleプールはそのずれを特に気にせず作られているので、在庫を見れば価格の低い WETH (sETH)がwstETHよりも極端に多くなっています。このバランスが崩れた状態はスリッページ耐性も低く非効率です。今後さらにこの状況は悪化していくでしょう。

(しかしある程度はStableプールとして機能しているので、一年おきくらいで ETHと1:1になるような “w”wstETHを作れればいいですよね、というのがこの記事の意図です。)
浮動ペッグステーブルコインのRAIは額面としては 2.77ドル程度ですが、実質ドルステーブルコインです。その長期的な価格トレンドは市場価格(market price)と償還価格(redemption price)の関係性によって変化しますが、昨年中の対ドル価格変化率は8%程度でした。


RAIはStableswap AMMへの統合に関して、「単位の違い」と「LSDsのような利率の影響」の両方が合わさった課題を持っているといえます。
現状の正攻法な対応は1:1に相当するバランス点の解釈をAMM側で随時変更していくことです。
Curve v2は内部で取引実績から価格オラクルを作り、そこへバランス点を徐々に寄せていきます。
https://classic.curve.fi/files/crypto-pools-paper.pdf
BalancerのMetaStable Pool、Gamma (Uniswap v3 manager)、RAI用の改造Curve v1はどれも外部からバランス点の情報を得ます。
https://dev.balancer.fi/resources/deploy-pools-from-factory/creation/metastable-pool
https://docs.gamma.xyz/gamma/features/strategies#pegged-price-pegged
https://github.com/curvefi/curve-contract/pull/144
現状の対応の全てはAMM側でのリバランスを行います。リバランスとは impermanent lossを都度確定させてしまうことを意味します。そのコストは経路依存となり、事前想定ができません。
https://twitter.com/danrobinson/status/1623126635334762496?s=20&t=IIXIvEAiXdqkhmtGtP3Keg
Curve v2のように、獲得した手数料収入の範囲内で(AMMの不変量が成長していくことを担保しながら)少しずつリバランスする、といったルールを策定するのは合理的です。しかし一般ユーザーにこれを理解してもらうのはとても難しいでしょう。
ラッパートークンによる対応はシンプルです。ある時点で1:1が成り立つようにラッパートークンを作り、有効な限りそれを使うというものです。この方法ではAMMによるリバランスがないので、流動性提供者たちは「価格がxxx%変われば impermanent lossが yyy%発生する」といった見通しを得ることができます。
LSDsや RAIは利率が年10%以下であれば、半年から1年くらいは100倍増幅のStableswap AMMを効率的に活用できるでしょう。USD, EURO, JPYといった主要通貨間の Forexにも数ヶ月くらいは活用できそうです。
ことRAIに関しては、1ドルくらいにラップしてあげることで、RAIとはどのような通貨なのかというのを説明するコストが大幅に下がると思います。
ラッパートークンが様々なタイミングで生成されることで流動性は多少断片的になるかもしれませんが、factory contractで indexingをしっかりできるようにしておけば、DEX aggregatorsに「wrapper swap」をうまく統合してもらってなんとかなる気がします。
ラッパートークンはシンプルですが使い所は多いと思うので、それを誰でも簡単に作れるようにする factoryコントラクトはなかなか価値があるのではないかと思います。
1 WBTCから1 WSATとか作れますね。
YFIとWOOFYとかありましたね。
decimalsの処理のケアがちょっと大変でしょうか?
「リベース対応自体もラッパーコントラクトでしてしまえば良いし、他に最新機能も追加できるよね」という指摘がありました。
https://twitter.com/danrobinson/status/1561558549058166785?s=20&t=WiGRAbd71VW09xJl9qnBtw
No comments yet