All articles
solanaactionsblinkspaymentsux

Solana Actions & Blinks: transactions from a URL

Actions are an HTTP spec that turns any URL into a signable Solana transaction; Blinks unfurl them into inline UI. Here's the GET/POST flow, actions.json, the CORS rules, and the security model.

A Blink (blockchain link) is a shareable URL that a compatible client unfurls into an inline, signable transaction UI. An Action is the spec-compliant HTTP API behind it (stewarded by the Solana Foundation and Dialect). The pitch: any link — in a webpage, a QR code, an X post — can become a one-tap mint, donate, or vote.

The flow: two endpoints

text
GET  /api/donate     → metadata: { icon, title, description, label, links }
                       (client renders buttons/inputs)

user clicks a button, client POSTs the user's pubkey:
POST /api/donate     { "account": "<base58 pubkey>" }
                   → { "transaction": "<base64 serialized tx>", "message": "..." }

wallet deserializes → shows the tx → user signs → submits

The GET response (ActionGetResponse) carries icon (absolute URL), title, description, label, and a links.actions[] array where each entry has an href and typed parameters[] (text, number, select, radio…). The POST returns a base64-serialized transaction the wallet signs.

actions.json: make a normal page a blink

A file at your domain root maps website paths to Action endpoints, so a human-friendly URL behaves as a blink:

json
// https://yoursite.com/actions.json
{
  "rules": [
    { "pathPattern": "/donate", "apiPath": "/api/donate" },
    { "pathPattern": "/x/**",   "apiPath": "/api/x/**" }
  ]
}

And the endpoint must send permissive CORS, or no client can read it:

typescript
headers: {
  "Access-Control-Allow-Origin": "*",
  "Access-Control-Allow-Methods": "GET,POST,PUT,OPTIONS",
  "Access-Control-Allow-Headers": "Content-Type, Authorization, Content-Encoding, Accept-Encoding",
}
// OPTIONS preflight must be handled too.

The security model

This is the crux: a blink turns an arbitrary URL into a one-tap signable transaction, so a malicious endpoint can serve a draining tx. Two mitigations: the wallet still shows the transaction before signing, and unfurling on X is gated by the Dialect Actions Registry — only registered actions unfurl (Phantom, Backpack, and Dialect co-run this). Critics counter that inline-signing trains risky habits and that a curated registry is a centralized trust point.

The honest read

Technically the spec is clean and genuinely useful for QR-code checkout, embedded donate buttons, and in-app transaction flows. As the "crypto on every tweet" growth lever it was hyped to be, it underdelivered: unfurling is registry-gated, wallet support is opt-in behind experimental settings, and it never became the default consumer surface. Treat it as a solid distribution primitive for controlled flows, not a viral mechanic — and never auto-sign; always show the decoded transaction.

References

Actions turned the transaction into something you can link to. Whether that's powerful or dangerous depends entirely on the wallet showing you what you're about to sign.

—————
Solana Actions & Blinks: transactions from a URL | devrels.xyz