Liquifi airdrops can use bulk transfers or issuer-enabled recipient claims

Who initiates bulk transfers and recipient claims?

Issuers initiate bulk transfers, while recipients start claims only when their organization has enabled that option for their grants. The bulk-distribution feature handles airdrops and post-token-sale transfers. The platform's batched transaction engine supports bulk distributions to 10 000+ stakeholders. The issuer determines the recipients and allocations for each distribution. A recipient claim requests the tokens available through that recipient's grants. It doesn't initiate the issuer's bulk distribution to other stakeholders.

Recipients don't choose whether an issuer uses Token Manager for its distributions. The issuer sets release arrangements and supplies the tokens. Some organizations send tokens directly, so recipients won't need to trigger a claim. Others enable self-service claims.

Funding sources and destination wallets

The account's funding setup determines where distribution tokens come from and whether Token Manager can coordinate their movement. Custody accounts connect a custodian through API access and its transfer policies. Smart contract accounts use an on-chain escrow that the issuer funds. Token Manager orchestrates these arrangements without itself custodying the tokens. The connected custody account or escrow must hold enough tokens for the amount due. Transfer policies and approvals also apply to custody-based payouts, so an available balance alone doesn't establish that a transfer can proceed.

Tracking-only accounts record allocations, schedules, and balances while transfers happen outside Token Manager. Their administrators execute distributions through treasury wallets, custodians, or external tooling.

The registered destination can be a custodial or non-custodial address. Recipients may connect a wallet or submit an address manually, depending on the setup. Custody-based payouts can also require destination allowlisting. The administrator must complete any required custodian setup before publishing the affected grant. Registering an address and configuring permission to send to it are separate requirements in those arrangements.

View image file

When can a recipient claim an allocation?

A recipient claim requires tokens that have both vested and unlocked under the applicable grant schedules. The issuer must also activate the grant, enable claims, and fund the source for delivery. A vesting date alone doesn't establish availability when an applicable lockup continues. The grant's claimable amount reflects its vesting and lockup schedules. An administrator-driven payout may deliver that amount without a recipient starting a claim, depending on the organization's distribution setup.

Wallet access adds a separate requirement. Recipients using an external wallet must sign in with their registered grant wallet or, for Safe-based setups, a Safe-connected signer wallet. The wallet must use the company's distribution network. Otherwise, a correct address can still show an empty dashboard. An available claim presents the amount and destination for review before the recipient authorizes the transaction. Email-only viewing access generally doesn't provide the same claiming ability; an issuer-configured generated wallet can change that access arrangement.

Custodial and generated wallet access

A recipient's custodial wallet may accept a payout even when it can't connect for a claim. The issuer can arrange a transfer to the registered custody address in that case. Another supported route uses a suitable non-custodial wallet, with the grant configured for direct claiming. The grant's release conditions continue to govern token availability through either route. Fireblocks supports on-chain escrow claims through WalletConnect when its allowlist and transaction policies permit them.

An issuer may create a non-custodial wallet for a recipient, with access tied to email. In that configuration, clicking Claim may credit the generated wallet's internal balance. External withdrawal is a later action where the feature is available. A balance in that wallet therefore differs from tokens delivered to a separately supplied external address. The issuer should identify whether this arrangement applies before the recipient interprets Claim as an external withdrawal.

A sign-in method alone doesn't establish the account's transfer options. The organization's wallet configuration determines which actions accompany access to the grant dashboard.

Why hasn't an expected airdrop arrived?

An expected airdrop can remain undelivered because the issuer hasn't released it, the source lacks tokens, or the claim transaction hasn't completed. Ask the grant administrator whether the grant is active, whether its release conditions have been met, and whether a payout has actually started.

An insufficient-balance error during claiming usually indicates too few distribution tokens in the company's escrow or custody source. That differs from a wallet lacking the native token needed to pay the claim's gas. The company must supply distribution tokens; adding gas funds to a recipient's wallet won't fill the issuer's escrow.

A pending transaction also differs from an executed transfer. The relevant network's block explorer can show transaction status using its hash. Ask the administrator for the correct explorer or transaction details. Check whether the transfer succeeded before treating a submitted claim as delivered. Signing or approving an action doesn't establish that its transfer has completed.

View image file

The grant administrator remains the first contact for missing tokens. Token Manager and Coinbase support can't send the issuer's tokens on that administrator's behalf. When claims are disabled, recipients must rely on the issuer's payout arrangements.