見出し画像

他人がClaimしてるのに自分だけできてないとき

Aoi_captain

エアドロClaim時間が20:00なのに、もう利確してる気配がする。

そんな時の対処法をまとめました。

準備するもの

まず、以下を用意します。

1. ClaimしたいチェーンのExplorer

ClaimはGensyn Mainnetチェーンだと連絡があったのでGensyn用のExplorerを開きます。

Gensyn Mainnet Explorer


2. Claim対象トークンのコントラクトアドレス

次に、ClaimしたいトークンのCA(コントラクト)を用意します。

今回はGensyn (AI)というトークンでコントラクトは

0x4e742319f6b0FeC4afA504fC8ED3cEAB0fb751A2


3. 成功している他人のClaimトランザクション

一番ほしい材料はこれです。

すでにClaimに成功している他人のTX

1.で準備したExplorerに2.のCAを入れて検索します。
出てきたサイトの[Token transfers]から[Method]で[claim]と書かれているTXを見つけ出します。

たとえば、今回見たTXではこうなっていました。

Transaction details
0xb0ead06323aff922830af1af2728dd29505906930fc484d4f4e9821c9db2a09b

Status: Success
Method: claim
Interacted with contract: Distributor
Tokens transferred:
Distributor → Claimした人のウォレット
for 86,150.12575585386 AI

これが見えたら、

あ、このトランザクションはClaim成功の見本だ

と考えられます。

作り方

Step 1.エアドロをClaimするチェーンのExplorerを開く

Step 2. トークンCAを検索する

Step 3. Claimっぽいトランザクションを探す

Step 3. Explorerにトランザクションを張る

Step 5. Interacted with contractを見る

Claimトランザクション[0xb0ead06323af…]
ここで見るのは、

Interacted with contract

です。

今回の見つけたClaimトランザクション[0xb0ead06323af…]では、

Distributor

でした。

つまり、このClaimでは、ユーザーが直接トークンコントラクトを触ったのではなく、
Distributorコントラクトを叩いてトークンを受け取っている。


そしてDistributorにカーソルを合わせると

Proxy contract:
0x3Ef3D8bA38EBe18DB133cEc108f4D14CE00Dd9Ae

Implementation:
0x918261fa5Dd9C3b1358cA911792E9bDF3c5CCa35

となっていました。

なので、

Claimするときに触る入口:
0x3Ef3D8bA38EBe18DB133cEc108f4D14CE00Dd9Ae

claim関数の中身を確認する場所:
0x918261fa5Dd9C3b1358cA911792E9bDF3c5CCa35


つまりこのトークンCAからClaim関数は呼び出せず、DistributorコントラクトからClaim関数を呼び出す必要がある！

確かにトークンCAにはClaim関数が見つからなかったです。


Step 7. 一応Claim関数の中身・ロジックを見る

Distributor にマウスを乗せると、次のように表示されました。

Proxy contract:
0x3Ef3D8bA38EBe18DB133cEc108f4D14CE00Dd9Ae

Implementation:
0x918261fa5Dd9C3b1358cA911792E9bDF3c5CCa35

実際にユーザーがClaimするときはProxyに向かって操作します。
でも、Claimの仕組みを調べておきましょう。Implementation側を見ます。

下の Implementation です。

0x918261fa5Dd9C3b1358cA911792E9bDF3c5CCa35

このImplementationは、Claim関数の中身やルールが書かれている本体です。

Proxy = 受付カウンター
Implementation = 受付の裏にあるルールブック


ExplorerでImplementationを入力し検索すると

Distributor.sol が表示されていました。

ここが、Claimのレシピ本です。

この中を見ると、Claimに必要な材料や、proofのチェック方法が分かります。

たとえば今回のコードには、14行目[Merkle tree]について次のような説明がありました。

Merkle tree whose leaves are (address user, address token, uint amount)

これはつまり、Claim対象者の名簿が、

ウォレットアドレス
トークンアドレス
受け取れる数量

の3つをセットにして作られている、という意味です。これは後でProofsを作るときに使います。頭の片隅に置いておきます。


Step 8. Proxy側のRead/Write proxyでclaim関数を探す

さて実際にClaimで触る入口はProxyです。

Implementation側でClaimのルールを確認したら、いよいよ次は実際に操作するProxyへ移動します。

Step5.に戻ってClaimを成功した他人のトランザクションの[Distributor ]にマウスを乗せると、次のように表示されました。

Proxy contract:
0x3Ef3D8bA38EBe18DB133cEc108f4D14CE00Dd9Ae

Implementation:
0x918261fa5Dd9C3b1358cA911792E9bDF3c5CCa35


このProxy contractのアドレスをExplorerで検索し

Contract
Code
Read/Write contract
Read/Write proxy

ここで選ぶのは、

Read/Write proxy

です。

ここが、成功TXと同じ入口からコントラクトを操作する場所です。

4. Claim

つまりこの画面では、上から順に

users
tokens
amounts
proofs

を入れます。

ここで入れるもの

1. users (address[])

自分のウォレットアドレスです。

例：

0xYourWalletAddress

2. tokens (address[])

受け取るトークンのCAです。

今回の例なら AI トークンのアドレスを入れる形です。

3. amounts (uint256[])

自分が受け取れる数量です。
表示用の枚数ではなく、コントラクト用の整数 を入れます。

たとえば 18 decimals なら、
1 トークンでも 1000000000000000000 みたいな形になります。

Eligibleページで 「500枚Claimできます」 と出ていた場合でも、コントラクトに入れる amounts はたぶん 500 そのままではない です。

たとえばトークンが 18 decimals なら、

表示：500 AI
入力：500000000000000000000

になります。

つまり、

500 × 10^18
= 500000000000000000000

です。

ところで何decimalsなの？

そんな時はトークンCAです。
Decimal１８と書いてあります。


4. proofs (bytes32[][])

ここが一番大事です。
自分専用のproof を入れる場所です。

先ほど確認したDistributor側にこういう情報がありました。

Merkle tree whose leaves are (address user, address token, uint amount)

こんな感じかな？Claimの名簿がこのように書かれているということです。
想像だとこんな感じ↓


公式ClaimページのNetworkを見る

EligibleページやClaimページを開いて、右クリックし[検証]ChromeのDevToolsを開きます。

右クリック
↓
検証
↓
Network
↓
Fetch/XHR

その状態で、

ページを更新
ウォレット接続
Eligibleチェック
Claimボタン付近を触る

をします。

そしてNetwork内で検索します。

自分のウォレットアドレス
proof
amount
merkle
claim
eligible
eligibility
airdrop

JSONでこんな形で表示されるらしい

{
  "address": "0xYourWallet",
  "amount": "500000000000000000000",
  "proof": [
    "0xabc...",
    "0xdef...",
    "0x123..."
  ]
}

最終的に入力するproofsのコントラクトはこうします。

users:
["0xYourWallet"]

tokens:
["AIトークンCA"]

amounts:
["500000000000000000000"]

proofs:
[["0xabc...","0xdef...","0x123..."]]


そして[4. Claim]に書き込んでいきます。

ポイントは、APIで返ってくる proof が1重配列でも、コントラクトの入力は bytes32[ ] [ ]なので、

["0xabc","0xdef"]

ではなく、

[["0xabc","0xdef"]]

とカッコを二重にすることです。

今回エアドロの該当していなかったため検証できませんが、次回はこれでやってみたいです。






実際にユーザーがClaimするときはProxyに向かって操作します。
でも、Claimの仕組みを調べたいときは、Implementation側を見ます。

コントラクトとプロキシーの違い
たとえるなら、

Proxy contract      = 受付カウンター
Implementation      = 裏にいる担当者・実際の処理ルール






いいなと思ったら応援しよう！