Saltar al contenido principal

Fase 4: Solana (programas Anchor)

Estado: Planificada.

Programas Anchor payment_link y subscription. Una PDA por enlace; delegado SPL para las suscripciones. Deja obsoletas la derivación HD de SOL y el servicio de barrido de SOL para los enlaces marcados.

Alcance​

  • Workspace de Anchor en contracts/solana/ con ambos programas.
  • Indexador con webhooks de Helius (o streams de Triton) que emite los eventos de webhook existentes.
  • Rama SOL del keeper en subscription-auto-charge.processor.ts.
  • Auditoría de SOL (OtterSec o Neodyme).

Código afectado​

Impacto en ejecución / UX​

  • Los enlaces de pago en SOL muestran una dirección PDA; para el pagador no cambia nada.
  • Las suscripciones en SOL piden al pagador una firma Approve de SPL durante el alta.
  • La revocación se hace con spl-token revoke o la interfaz estándar de la wallet.

Limitaciones actuales​

  • SOL envuelto frente a SOL nativo se gestiona por enlace mediante expected_mint.
  • Los picos de la comisión de prioridad pueden retrasar charge(); los reintentos suben la prioridad.
  • No hay equivalente a Chainlink en Solana en el momento del despliegue; la redundancia secundaria es una segunda región de NestJS o Clockwork (si es aceptable).

Entrada del blog relacionada​

Fase 4: Solana no custodial con PDA de Anchor

Lista de comprobación del estado​

  • Workspace de Anchor creado
  • Programa payment_link con todas las instrucciones + tests
  • Programa subscription con todas las instrucciones + tests
  • Indexador con webhooks de Helius en producción
  • Rama SOL del keeper activa
  • Informe de auditoría recibido
  • Despliegue en mainnet desde el multisig de Squads
  • Grupo canary estable durante 14 días