TipLink

• Name: TipLink
• URL: https://tiplink.io/
• Category: Solana wallet / link-based asset distribution / onboarding and payments infrastructure
• Tags: solana-ecosystem
• Summary: TipLink at the project layer is still the link-wallet mechanic: a URL becomes the asset handoff. Keep this note on the Solana-native product surface — URL-derived wallet semantics, claim flow, and the public API primitives for creating and resolving TipLinks. The broader operator boundary now lives in tiplink, which is the cleaner place to reason about TipLink Pro campaign tooling, dispenser controls, Email TipLinks access, wallet-adapter client IDs, Google-sign-in onboarding packaging, and the company-run distribution shell above the product.
• What it does:
  • Lets a sender create a TipLink that can hold SOL, SPL tokens, NFTs, and SFTs
  • Uses a shareable URL as the handoff mechanism for receiving and claiming assets
  • Allows recipients to take control of the linked assets through Gmail or a Solana wallet according to the docs
  • Exposes a public JavaScript API package for creating TipLinks programmatically and deriving TipLinks from URLs
  • Frames TipLinks as infrastructure for digital collectible distribution, giveaways, onboarding, and peer-to-peer payment flows via Solana Pay
• Key claims:
  • The official docs call TipLink a lightweight wallet designed to make transferring digital assets as easy as sending a link
  • The docs describe TipLink as non-custodial and explicitly say the link is the wallet
  • Official materials say TipLinks can hold SOL, SPL tokens, NFTs, and SFTs
  • The getting-started docs position TipLink as a way to onboard new users without seed phrases, browser extensions, or complex key management
  • The docs explicitly state TipLink is currently only available on the Solana network
  • The public API README shows developer primitives for TipLink.create() and TipLink.fromLink(...), which confirms there is a real programmatic integration surface beyond the consumer UI
• Whitepaper: No classic standalone whitepaper or litepaper was found during this pass. The strongest primary materials for the product surface remain TipLink’s getting-started docs and the public API repository README; the company-boundary source bundle now lives in ../whitepapers/tiplink-company-boundary-primary-sources-2026-08-12.md.
• Sources:
  • https://tiplink.io/
  • https://docs.tiplink.io/docs/getting-started/overview
  • https://github.com/TipLink
  • https://raw.githubusercontent.com/TipLink/tiplink-api/master/README.md
  • https://docs.tiplink.io/docs/products/tiplink

Internal linkages

• Company / operator boundary for TipLink Pro, Email TipLinks, wallet-adapter credential issuance, and the broader distribution shell: tiplink.
• Best comparison points: solana-pay, solana-actions, and backpack.

Protocol / company boundary

• Keep this note on the product mechanism: URL-as-wallet semantics, Solana-only scope, claim flow, public API primitives, and the user-facing onboarding path.
• Use tiplink when the sharper question is who controls campaign tooling, dispenser policy, Email TipLinks access, wallet-adapter client IDs, embedded rollout, and the broader company-run distribution shell.
• That split matters because how does a TipLink behave? and which named operator controls scaled distribution and embedded onboarding around TipLink? are related but not identical questions.

Control surface

• At the product layer, authority sits in the link format, claim mechanics, Gmail-versus-wallet claim path, Solana-only chain scope, and the public API primitives developers build against.

• The broader operator dependency points upward to tiplink, because that is where campaign and dispenser tooling, access issuance, email delivery, and embedded-wallet rollout become company-shaped rather than purely product-shaped concerns.

• Read TipLink as a compact onboarding and asset-distribution product, not as a generic multichain wallet stack.

• Last reviewed: 2026-08-12 UTC