Why XRPL Tokens Can't Be Airdropped

Every XRPL token model stores a holder's balance in an object that lives in that holder's owner directory — a RippleState for trustline tokens, an MPToken for Multi-Purpose Tokens, an NFTokenfor NFTs. Creating one raises the holder's reserve obligation, so the protocol requires the holder's own signature.

That produces a single invariant: the XRP Ledger never adds an object to your account without your signature. XRP is the one asset that can arrive unannounced, because a balance is a field on AccountRoot rather than an object.

Each asset type pushed at an account that had not opted in, on testnet, with a control that had.

The IOU rows matter most: the same transaction — a cross-currency swap routed through a live AMM pool — returned tesSUCCESS when the destination held a trustline and tecPATH_DRYwhen it did not. Only the destination changed. A swap alters how value reaches the final hop, never what happens at it: the last step must credit a RippleState, and with none the path is dry.

MPTs are the interesting case, because they discard trustlines entirely — no rippling, noDefaultRipple, one object per issuance. They kept the consent rule anyway. The issuer cannot even bootstrap it on a holder's behalf; rippled says so in a comment: "The holder must create the MPT before the issuer can authorize it" (MPTokenAuthorize.cpp:148). Issuer-submitted authorization returned tecNO_AUTHand left the recipient's OwnerCount untouched. When the holder opted in themselves, theirOwnerCount went 2 → 3 — they paid, so they signed.

If a stranger could create a trustline on your account, they could unilaterally freeze 0.2 XRP of your money, and do it repeatedly. Requiring a signature is what makes that impossible, and it is why the rule holds uniformly across every token type rather than being a per-model policy.

The forthcoming Sponsor amendment covers both RippleState and MPToken, letting a third party pay a holder's reserve. That removes the cost barrier. It does not remove the consent one — the holder still signs.

Solana is architecturally closer to XRPL than most comparisons suggest: it also needs a per-holder account before tokens can land. The difference is not whether an object is required — it is who is allowed to create it.

On Solana the payer and the owner can differ, so an airdropper creates your token account at their own cost and transfers in. The rent is refundable to you on close, so a stranger doing this hands you a small deposit rather than seizing one — a different collateral model, and therefore a different safe answer. Ethereum sidesteps the question: ERC-20 balances live in the token contract's own storage, sotransfer() just writes your slot.

• Airdrop XRP.The only zero-action delivery. It reaches any address and creates the account if it does not exist. Right choice when the goal is delivering value; wrong one if you need your token's branding or supply mechanics.
• Pre-fund the claim. Push roughly 0.25 XRP — no consent needed — covering the 0.2 reserve plus fee headroom, then let recipients sign one TrustSet and claim at zero cost to them. This is the lowest-friction real token airdrop on the XRPL. They still sign once; there is no version where they do not.
• Allocate off-ledger, mint on claim. Track entitlements off-chain and issue only when claimed. The most capital-efficient option — nothing stranded on recipients who never show up — and what most XRPL airdrops already do.

The cost is real. Opt-in makes token launches and marketing harder than on chains where you can spray balances at an address list.

What you buy is that token spam is structurally impossible. Ethereum and Solana wallets fill with scam tokens, phishing lures, and dust used to deanonymize holders; both ecosystems retrofitted spam filtering into wallets and explorers to cope. On the XRPL, every asset in your wallet is one you chose.