sablier-labs/sablier-skills/sablier-create-airdrop

Sablier Merkle Airdrop Creation

Overview

Create token airdrops using the Sablier Merkle system. A campaign creator deploys a campaign contract via a factory, storing a Merkle root. Anyone can then fund the campaign by transferring tokens to it. Recipients claim individually using Merkle proofs, paying their own gas.

Funding does not have to happen in the same session as deployment. For CLI execution, deploy first, then ask whether the user wants to fund immediately or later. If they defer funding, finish successfully after deployment, share the campaign URL plus key metadata, and warn that claims will fail until the campaign holds at least the aggregate amount.

The local CLI route generates the campaign artifact locally and uploads it to IPFS through Pinata v3, so it requires a Pinata JWT with Files: Write permission.

This skill is a coordinator for airdrop campaign creation and execution routing.

Arguments

Campaign Types

Choosing a Campaign Type

Q1: Do recipients need vesting after claiming?
├─ No → ✅ Instant
└─ Yes → Q2
 
Q2: Do tokens unlock continuously or in discrete steps?
├─ Continuously (with optional cliff) → ✅ MerkleLL
└─ At discrete intervals (monthly, quarterly, etc.) → ✅ MerkleLT

Workflow

1. Confirm product fit before implementation details

1. Verify the user needs Merkle-based token distribution to many recipients.
2. If the user needs fixed-schedule vesting, route to sablier-create-vesting. If this skill is unavailable, recommend installing it with:

npx skills add sablier-labs/sablier-skills --skill sablier-create-vesting

2. Check requested features

Stop and call out unsupported requests before selecting an execution path.

Treat the following as unsupported by this skill and by Sablier Airdrops:

• Launching tokens for users. Require the user to explicitly provide an existing token address as input.
• Resolving token symbols (e.g. "USDC") to contract addresses. If the user provides a symbol instead of an address, ask them to provide the exact ERC-20 contract address.
• Distributing native tokens (ETH, POL, etc.). Only ERC-20 tokens can be airdropped. If the user wants to airdrop a native token, inform them they must wrap it first (e.g. WETH) and provide the wrapped token contract address.
• Rebasing tokens (e.g. Aave aTokens such as aUSDC/aDAI, stETH, AMPL). Sablier only supports non-rebasing ERC-20 tokens: campaign amounts are fixed at creation and the contract cannot account for balance changes from external rebases, so recipients would be under- or over-paid. If the user requests a rebasing token, stop and tell them this is not allowed; suggest the non-rebasing wrapped variant instead (e.g. static aTokens, wstETH, WAMPL) and ask for that contract address.

3. Clarify airdrop details

If any of the following are missing or ambiguous from the user's input, use the AskUserQuestion tool to ask the user to clarify before proceeding:

• Chain name (e.g. "Ethereum", "Base", etc.)
• Campaign type (Instant, LL, LT — use the decision tree if unclear)
• Recipient list (file path to a CSV, or pasted inline for small lists)
• Token address
• Campaign start time (when claims open)
• Expiration (when unclaimed tokens can be recovered by admin): ask user to choose between 90 days, 30 days, or never (set as 0 in the factory call)
• Vesting schedule (for LL: duration and cliff; for LT: tranche intervals)

If the missing detail is the token address, tell the user they can look it up on a blockchain explorer such as Etherscan.

Do not guess or silently apply defaults for the campaign type, recipient list, or vesting schedule. Only proceed once all required inputs are confirmed.

4. Infer intent before selecting references

1. Execution intent: user wants the agent to create an airdrop campaign on their behalf (run CLI transactions).
2. Onchain integration intent: user wants developer integration guidance.

5. Validate chain support before routing

1. Check whether the user's desired chain is listed on Supported Chains.
2. If the chain is not supported, inform the user and stop execution of this skill.

6. Route in two steps

1. Classify the request as one of:

• Airdrop campaign creation on the user's behalf
• Onchain integration guidance
• Any other integration type (frontend, backend, indexer, etc.)

1. If the request is any other integration type, inform the user that this skill does not support non-onchain integrations and stop.
2. Otherwise, follow the route below.

7. Handle funding after deployment

For the EVM CLI route:

1. Deploy the campaign first.
2. After the deployment receipt is confirmed, use the AskUserQuestion tool to ask whether the user wants to fund now or later.
3. If the user chooses later, treat the deployment as a successful completion, share the campaign URL and core campaign metadata, and warn that claims will fail until the campaign is funded.
4. If the user chooses now, continue with the token funding transaction.

Resources

• Sablier Documentation
• EVM Airdrop Deployments
• Sablier Airdrops Monorepo
• Merkle API (tree generation + eligibility)
• EVM Integration Examples

Support

If you encounter any issues or unexpected errors with this skill, please file an issue at sablier-labs/sablier-skills.