Actions (a spec)
Endpoints HTTP padronizados que produzem transações Solana para wallets e Blinks.
Receita
GET /action-info → metadata (title, icon, description)
POST /action-execute → transaction para conta conectada
Quando usar:
- Botões interoperáveis entre wallets, Twitter e Discord.
- Interações on-chain descobríveis sem deep links customizados por wallet.
- Campanhas de marketing precisando de links compartilháveis.
Exemplo prático
import { NextResponse } from "next/server";
export async function GET() {
return NextResponse.json({
type: "action",
icon: "https://example.com/icon.png",
title: "Vote on Proposal 1",
description: "Cast your governance vote",
label: "Vote",
});
}
export async function POST(req: Request) {
const { account } = await req.json();
if (!account) return NextResponse.json({ error: "missing account" }, { status: 400 });
// construa e retorne { transaction: "<base64>" }
return NextResponse.json({ transaction: "BASE64_TX" });
}O que isso demonstra:
- GET anuncia metadata humana para unfurlers.
- POST recebe pubkey do usuário e retorna transação serializada.
- Siga diretrizes CORS e segurança de Solana Actions.
Aprofundamento
Como funciona
- Clientes Blink buscam GET para card de preview.
- Clique do usuário dispara POST com pubkey da wallet.
- Wallet assina transação retornada.
- URLs de callback opcionais reportam conclusão ao dApp.
Campos de Resposta
| Campo | Propósito |
|---|---|
| title | Título do card |
| icon | URL de imagem HTTPS |
| label | Texto do botão |
| transaction | Tx wire base64 |
Erros comuns
- HTTP não HTTPS - wallets recusam. Correção: TLS em todo lugar.
- CORS errado - wallet browser bloqueada. Correção: headers spec em OPTIONS/POST.
- URL de ícone maliciosa - phishing. Correção: hospede no seu domínio.
- Sem validação de account - verificação de formato apenas; ainda construa instruções seguras.
- GET muta estado - envenenamento de cache. Correção: GET é apenas metadata read-only.
Alternativas
| Alternativa | Use quando | Não use quando |
|---|---|---|
| Apenas deep link | Integração com wallet única | Blinks multiplataforma |
| dApp in-app browser | Controle total de UX | Campanhas virais de compartilhamento |
FAQs
App Router?
Providers em client layout.tsx; pages misturam server + client components.
Secrets?
Env de servidor apenas para keypairs; NEXT_PUBLIC_ para URLs RPC.
kit 7.0.0?
Todos os exemplos usam @solana/kit, não web3.js v1.
Wallet?
Assinatura apenas em client components.
Caching?
Revalide leituras on-chain com cuidado - chain é fonte da verdade.
Actions?
Endpoints HTTPS retornando JSON Solana Actions.
Mobile?
App React Native separado com MWA.
Testing?
Surfpool para integração; mock RPC em testes unitários.
Mainnet?
Arquivos env e program IDs separados.
Errors?
Decodifique logs de simulação para mensagens ao usuário.
Relacionados
- Construindo uma Action - implementação
- Blinks - links embutíveis
- Segurança e Verificação - segurança
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.