Solana Actions & Blinks: transactions from a URL
Solana Actions turn any URL into a signable transaction; Blinks unfurl them into inline UI. The GET/POST flow, actions.json, CORS, and the security model.
devrels.xyz/a/32short linkA 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
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 → submitsThe 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:
// 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:
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
- solana.com — Actions & Blinks guide
- solana-developers/awesome-blinks
- Solana Pay — the QR/URL payment spec it overlaps with
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.
Keep reading
The pay.sh catalog is full of global APIs. None of them own Australia. Milypay wraps ABR, ASIC, G-NAF, ATO super, BOM weather, AusPost, and AusPayNet BSB as HTTP 402 endpoints agents can discover, pay, and call — in AUD stablecoins on Solana.
Sphere Labs sells SpherePay: one REST API for moving money between USD/EUR/BRL bank rails and USDC/USDT/EURC on Solana and other chains. The Solana-native bank API with PIX, Offloader Wallets, and Onramper virtual accounts. Integration model, code shapes, and honest caveats.
Most BaaS stories stop at virtual accounts. Lead Bank is the chartered, FDIC-insured bank that issues Bridge's stablecoin-linked Visa cards, settles USDC with Visa over Solana, and documents solana as a payment rail next to ACH in public partner docs. Here is the stack, the API, and what Solana builders can actually use.
Get new articles in your inbox
Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.
