Acciones (la especificación)
Endpoints HTTP estandarizados que producen transacciones de Solana para wallets y Blinks.
Receta
GET /action-info → metadatos (título, icono, descripción)
POST /action-execute → transacción para cuenta conectada
Cuándo usar esto:
- Botones interoperables entre wallets, Twitter y Discord.
- Interacciones descubribles en la cadena sin deep links personalizados por wallet.
- Campañas de marketing que necesitan enlaces compartibles.
Ejemplo de funcionamiento
import { NextResponse } from "next/server";
export async function GET() {
return NextResponse.json({
type: "action",
icon: "https://example.com/icon.png",
title: "Votar en la Propuesta 1",
description: "Emite tu voto de gobernanza",
label: "Votar",
});
}
export async function POST(req: Request) {
const { account } = await req.json();
if (!account) return NextResponse.json({ error: "falta cuenta" }, { status: 400 });
// construye y devuelve { transaction: "<base64>" }
return NextResponse.json({ transaction: "BASE64_TX" });
}Lo que esto demuestra:
- GET anuncia metadatos humanos para los unfurlers.
- POST recibe la clave pública del usuario y devuelve la transacción serializada.
- Sigue las directrices de CORS y seguridad de Solana Actions.
Profundización
Cómo funciona
- Los clientes de Blink obtienen GET para la vista previa de la tarjeta.
- El clic del usuario activa POST con la clave pública de la wallet.
- La wallet firma la transacción devuelta.
- Las URLs de callback opcionales informan de la finalización a la dApp.
Campos de respuesta
| Campo | Propósito |
|---|---|
| title | Encabezado de la tarjeta |
| icon | URL de imagen HTTPS |
| label | Texto del botón |
| transaction | Transacción en formato wire (Base64) |
Errores comunes
- HTTP no HTTPS - las wallets lo rechazan. Solución: TLS en todas partes.
- CORS incorrecto - la wallet del navegador bloqueada. Solución: cabeceras spec en OPTIONS/POST.
- URL de icono maliciosa - phishing. Solución: alojar en tu dominio.
- Sin validación de cuenta - solo comprobación de formato; sigue construyendo instrucciones seguras.
- GET muta el estado - envenenamiento de caché. Solución: GET solo metadatos de solo lectura.
Alternativas
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| Solo deep link | Integración con una sola wallet | Blinks multiplataforma |
| dApp en navegador interno | Control total de la experiencia de usuario | Campañas virales compartibles |
Preguntas frecuentes
¿App Router?
Proveedores en layout.tsx del cliente; las páginas mezclan componentes de servidor y cliente.
¿Secretos?
Solo entorno de servidor para keypairs; NEXT_PUBLIC_ para URLs RPC.
¿kit 7.0.0?
Todos los ejemplos usan @solana/kit, no web3.js v1.
¿Wallet?
Firma solo en componentes cliente.
¿Caché?
Revalida las lecturas en cadena cuidadosamente - la cadena es la fuente de verdad.
¿Acciones?
Endpoints HTTPS que devuelven JSON de Solana Actions.
¿Móvil?
Aplicación React Native separada con MWA.
¿Pruebas?
Surfpool para integración; simula RPC en pruebas unitarias.
¿Mainnet?
Archivos de entorno y IDs de programa separados.
¿Errores?
Decodifica los logs de simulación para mensajes dirigidos al usuario.
Relacionado
- Construyendo una Acción - implementación
- Blinks - incrustar enlaces
- Seguridad y Verificación - seguridad
Versiones de Stack: Esta página fue 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, y LiteSVM 0.6.x.