Summary: Solana Actions are a standardized request/response layer for delivering signable blockchain interactions into arbitrary web surfaces. The useful cut is the decomposition: action APIs vend metadata and signable payloads, actions.json maps ordinary site URLs to those endpoints, blink URLs package them for clients, and wallets or registries decide what gets unfurled and trusted.
What it does:
Defines a standard API flow where clients fetch Action metadata with GET and obtain signable transactions or messages with POST
Turns those actions into shareable blockchain links (blinks) that action-aware wallets, bots, or clients can unfurl on arbitrary web surfaces
Uses domain-root actions.json files to map ordinary website URLs to their underlying Action API endpoints
Supports related actions, parameterized inputs, and chained next-step actions rather than only one-shot payment requests
Extends the older Solana Pay payment-oriented pattern into a broader action surface including voting, staking, minting, swapping, and other onchain interactions
Exposes a real client-governance and safety layer through wallet simulations, allowlists, and registry-based unfurl policies such as Dialect’s Actions Registry
Key claims:
The main reason Solana Actions belongs in the corpus is that it turns link-native onchain interaction into a comparison-ready protocol stack: action API, blink URL, domain mapping, client rendering, and wallet execution are all separate layers.
The developer docs are especially useful because they describe a clean lifecycle: GET for metadata, POST for the signable payload, then client-side wallet signing and submission. That is more structured than generic deep-link or embed systems.
The actions.json mechanism is a second important control surface. Ordinary site URLs can declare which backend action APIs they map to, which means discovery and trust sit partly at the domain level rather than only inside a wallet extension.
The published TypeScript spec adds another durable signal: this is not just marketing copy, but a typed interface with action types, parameter schemas, message-signing support, chained next actions, and explicit protocol identifiers.
The official materials also make registry and unfurl policy visible instead of hiding it. Dialect’s registry and wallet allowlist behavior show that even a permissionless action format still depends on client-side trust and distribution decisions.
Solana Actions cleared the bar because they expose a reusable social-distribution and transaction-vending layer that would be analytically flattened if filed only as Solana UX or wallet tooling.
Whitepaper: No canonical standalone Solana Actions whitepaper surfaced in this pass. The strongest primary materials were the official docs, the Solana solutions overview, the official repository, and the published type specification collected in ../../whitepapers/solana-actions-primary-sources-2026-05-13.md.