Fase 1: contratos de enlaces de pago en EVM

Estado: Planificada.

Sustituir las wallets de depósito derivadas de HD por PaymentLinkFactory (CREATE2) + PaymentLinkReceiver (clon EIP-1167) + FeeSplitter en Base.

Alcance

• PaymentLinkFactory, PaymentLinkReceiver y FeeSplitter implementados y auditados.
• Dirección CREATE2 determinista mostrada al pagador antes de cualquier despliegue.
• El indexador del evento Paid emite los webhooks existentes sin cambios.
• Feature flag useOnChainReceiver por chain id.

Código afectado

• api/src/payments/wallet.service.ts: rama EVM de getOrCreateAddressForPaymentLink.
• api/src/withdrawals/services/smart-account-wallet.service.ts: se evita drainSmartAccountWallet en las cadenas marcadas.
• Nuevo: api/src/payments/indexer/evm-paid-event.service.ts.
• Nuevo: contracts/evm/ (Foundry).

Impacto en ejecución / UX

• La interfaz del pagador no cambia. Mismo formato de dirección (la dirección CREATE2 previa al despliegue).
• La forma de los webhooks del comercio no cambia; los eventos no custodiales añaden un flag opcional non_custodial: true.
• El panel añade una insignia «No custodial» por enlace.

Limitaciones actuales

• Los tokens con comisión en la transferencia recurren a la ruta heredada (controlado por la lista de permitidos).
• Los tokens fuera de la lista de permitidos recurren a la ruta heredada.
• El reembolso está restringido a la EOA keeper o al multisig (como hoy).

Entrada del blog relacionada

Fase 1: enlaces de pago basados en contratos en EVM

Lista de comprobación del estado

• Proyecto de Foundry creado
• Contratos implementados con tests de fuzzing e invariantes
• Tests con fork para USDT / ERC-20 no estándar en verde
• Feature flag useOnChainReceiver conectado
• Indexador evm-paid-event.service.ts en producción
• Auditoría completada con las correcciones aplicadas
• Despliegue en la mainnet de Base desde el multisig Safe
• Grupo canary sin incidencias durante 14 días