# Using Clusters for ETH->SOL Airdrops

### Overview

Crosschain airdrops (like airdropping a Solana SPL-20 coin to holders of an Ethereum or EVM-based NFT) are tricky because Solana addresses are different than Ethereum addresses. Users have to link, or cluster, their authenticated EVM and SOL addresses together to ensure the airdrop goes to the right place.

For example, with the Pudgy Penguin $PENGU airdrop, users held Ethereum NFTs and were eligible to claim a Solana SPL-20. They linked their wallets together, with an option for full privacy, using Clusters. Clusters powered over 1.3 million unique claim events and over $1 billion of value.

Using Clusters is better than building your own bespoke internal system because:

* Faster time to ship, we've already built this infra and run several top airdrops through it, like $PENGU and $ANIME
* Users can preregister ahead of time, reducing first-hour load on launch servers and improving both uptime & throughput
* Easy compatibility with delegate.xyz claims, which are critical for smart contract wallets like Gnosis Safe and 4337 wallets that cannot make an EIP-712 signature
* Battle-tested across literal billions of dollars worth of value already
* Reusable composable state, so your community becomes legible and can make even more money from third-party airdrops (or future first-party airdrops)

### How Clusters Works

Clusters are bundles of wallets, for example here is a cluster of one ETH address, one SOL address, and one BTC address:

```
[
    0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045, 
    HWEoBxYs7ssKuudEjzjmpfJVX7Dvi7wescFsVx2L5yoY, 
    1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa
]
```

A verified wallet can only be apart of one wallet at a time.

Any verified wallet in a bundle can publicly or privately add wallets to a bundle.

Clusters uses a bundling framework. Where a wallet creates a “bundle” they then can publicly or privately add wallets to the bundle.

1. **Authentication**

Clusters protocol authentication works via offline wallets based signatures via EVM or Solana wallets.

```tsx
// 1. Get signing message
POST /v1/auth/message

// 2. Get auth token from signed item
POST /v1/auth/token
body={ signature, signginDate, type, wallet }
```

<figure><img src="/files/UYHxqoDC9dkKS4ULDgzn" alt=""><figcaption></figcaption></figure>

2. **Creating a bundle**

`POST /v1/bundle`

The connected wallet will create a bundle.

*(Alternatively, a user can skip this step and go straight to adding wallets to a bundle. If no bundle exists, it will create one beforehand)*

<figure><img src="/files/X02FLTl2SnumanfTXA2U" alt=""><figcaption><p>The initial created bundle</p></figcaption></figure>

The initial created bundle

3. **Adding wallets privately OR publicly**

`POST /v1/bundle/wallets`

The authenticated wallet can add wallets of any type to the bundle they are in. These wallets can be public to everyone OR can be completely private and hidden to the outside world.

\**When privately adding wallets, no events will be emitted to our Data Availability Layer, completely shielding the identity of the wallet and their associated bundle connections.*

<figure><img src="/files/a1ZTzbolNCAUefMKnbR8" alt=""><figcaption><p>A sample address bundle</p></figcaption></figure>

4. **Claiming airdrops**

`GET /v1/airdrop/claim/doodles`

Any wallet that is apart of a bundle can authenticate themselves and privately call the associated airdrop endpoint. The clusters backend will determine what wallets are eligible by traversing all bundles they are associated with.

Return objects can be associated merkle roots, transaction call data, etc.

In the below example, solana wallet Gg1..fwz tries to claim an airdrop. The system determines it’s associated with EVM wallet 0x000…123. If this EVM wallet is eligible for a claim, we can process it accordingly.

<figure><img src="/files/L8YxW3FWvrQwAq9cNY6s" alt=""><figcaption></figcaption></figure>

5. **Post claim**

* Register the user a new community name `doodles/foobar`
* Assign the above bundle to the community name (`POST /bundles/assign`)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.clusters.xyz/resources/using-clusters-for-eth-greater-than-sol-airdrops.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.