Blinks
Convierte Solana Actions en enlaces compartibles e incrustables en toda la web social.
Receta
https://your-blink-proxy.example/?action=https://actions.example.com/vote
Cuándo usar esto:
- Distribución en X, Discord y plataformas compatibles con Blink.
- Bucles de crecimiento donde los usuarios comparten enlaces accionables.
- Campañas que necesitan tarjetas de vista previa con iconos.
Ejemplo de funcionamiento
<!-- Los sitios asociados se incrustan a través de la URL del proveedor de Blink + tu endpoint de action -->
<a href="https://dial.to/?action=https://actions.example.com/swap">
Swap en MyProtocol
</a>// Tu endpoint de action sigue implementando metadatos GET + transacción POST
// Ver actions-the-specLo que esto demuestra:
- La URL de la action debe implementar la especificación GET/POST.
- El proveedor de Blink despliega los metadatos GET en una interfaz de usuario interactiva.
- Los requisitos de HTTPS y CORS siguen aplicándose.
Análisis Profundo
Cómo funciona
- El cliente Blink obtiene los metadatos de la action para una tarjeta enriquecida.
- El usuario conecta su billetera en el contexto de la aplicación social o el portal.
- El flujo POST de la transacción es idéntico al de las Actions.
- El registro de proveedores de Blink evoluciona: prueba las plataformas de destino.
Errores comunes
- URLs de action no verificadas: los usuarios firman transacciones maliciosas. Solución: listas de dominios permitidos en los clientes; educar a los usuarios.
- Caché de unfurl obsoleto: título incorrecto después del despliegue. Solución: parámetro de consulta de versión en la URL del icono.
- HTTPS de icono roto: la tarjeta no se renderiza. Solución: CDN con certificado TLS válido.
- Action de Mainnet en billetera de Devnet: fallos. Solución: clúster en los metadatos cuando sea compatible.
- Transacciones con privilegios excesivos: riesgo de drenaje. Solución: instrucciones de mínimo privilegio por action.
Alternativas
| Alternativa | Usar cuando | No usar cuando |
|---|---|---|
| QR Solana Pay | En persona | Bucles virales sociales |
| Enlace de dApp nativa | Producto completo | CTA ligero |
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 de RPC.
¿kit 7.0.0?
Todos los ejemplos usan @solana/kit, no web3.js v1.
¿Wallet?
Firma solo en componentes de cliente.
¿Caché?
Revalida las lecturas on-chain con cuidado: la cadena es la fuente de verdad.
¿Actions?
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
- Actions (la especificación) - forma del endpoint
- Seguridad y Verificación - confianza
- Conceptos básicos de Solana Pay - pagos
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.