Fase 0: diseñar una pila de pagos no custodial

20 de abril de 2026: antes de escribir una sola línea de Solidity, congelamos la especificación. La Fase 0 es la fase de diseño y aprobación de la hoja de ruta no custodial: qué pasa a on-chain y qué no, qué cadena se lanza primero, quién audita los contratos y quién guarda las claves de despliegue.

En resumen

• El reparto de comisiones queda congelado en cuatro conceptos: comercio, plataforma, referido/afiliado y comisión de puente. Todo lo que hace el divisor on-chain se expresa en puntos básicos; sin ajustes off-chain.
• Base es la cadena de lanzamiento de la Fase 1. Barata, rápida, ya incluida en la lista de cadenas del servicio de wallets y con USDC nativo.
• Las suscripciones adoptan approve + pull de ERC-20 (EVM) y delegación SPL (Solana). Se descartaron los diseños de escrow y de session keys; consulta la matriz de decisión más abajo.
• Los contratos los despliega una multisig Safe 3 de 5 (EVM) y una multisig Squads 3 de 5 (Solana). Los receptores por enlace son inmutables. Las factorías y SubscriptionHub están detrás de un pequeño proxy con un timelock de 48 horas.

Qué cambia en esta fase

Nada en producción. La Fase 0 es una especificación escrita, tres propuestas de auditoría, una ceremonia de claves de despliegue y un par de ADR fusionados.

La especificación del reparto de comisiones (congelada)

Hoy, SmartAccountWalletService.drainSmartAccountWallet en api/src/withdrawals/services/smart-account-wallet.service.ts compone transferencias en una UserOperation con tres destinatarios: el comercio (toAddress), la wallet de soporte (supportWalletAddress) y la wallet de comisiones. La versión en contrato replica esto exactamente:

struct Split {
    address merchant;   // main receiver
    address platform;   // support / platform fee
    address referral;   // commission / affiliate (optional, zero = skip)
    address bridgeFee;  // Relay bridge fee carrier (optional, zero = skip)
    uint16 platformBps;
    uint16 referralBps;
    uint16 bridgeFeeBps;
}

Todo lo que el keeper hace hoy en TypeScript se puede calcular a partir de esta struct y del importe del pago. Lo que el keeper actual no puede expresar (por ejemplo, impuestos dinámicos o retenciones a nivel de comercio) queda fuera del alcance de la Fase 1; lo añadiremos en una fase posterior si hace falta.

Selección de cadena

La cadena de lanzamiento de la Fase 1 es Base:

• Ya está en nuestro mapa de chainId (8453 → base, 84532 → baseSepolia) en api/src/payments/wallet.service.ts.
• El gas es lo bastante barato como para que desplegar PaymentLinkReceiver + repartir en el primer pago cueste céntimos por transacción.
• La política de paymaster de Alchemy ya la admite, lo que nos da una vía de escape si queremos patrocinar el keeper en SubscriptionHub.charge().
• USDC nativo (no puenteado), algo importante para los allowances de las suscripciones.

Ethereum mainnet, Arbitrum, Optimism y Polygon llegan en la Fase 3. Solana es un programa aparte, que se sigue en la Fase 4.

Modelo de suscripciones: la matriz de decisión

Evaluamos tres diseños. Solo uno nos sirve.

Modelo	Custodia	Experiencia del pagador	Compatibilidad de wallets	Requisito de keeper	Veredicto
Approve + pull de ERC-20 (elegido)	Ninguna	Un único approve	MetaMask, Phantom, Ledger, Safe: nativa	Cualquiera; el keeper es opcional	Publicar este
Depósito en escrow	Ninguna	Depositar N meses	Todas las wallets	Cualquiera	Peor experiencia; fondos bloqueados
Smart wallet + session keys	Ninguna	Alta en 4337	Solo wallets 4337	Firmante de session keys	Compatibilidad demasiado limitada

Approve + pull es el único que funciona con las wallets que los pagadores ya usan (MetaMask, Phantom, hardware wallets, Safes). También es el diseño que ya publicamos en Cobro automático, que documenta approve(spender, amount) y la delegación SPL. La Fase 2 sustituye el lado del cobro por un smart contract y deja sin cambios el lado del pagador.

El argumento completo está en Por qué el cobro por allowance supera al escrow y a las session keys.

Custodia de las claves de despliegue

• EVM: Safe (antes Gnosis Safe) en Base con umbral 3 de 5. Firmantes: dos fundadores, un responsable de operaciones, un asesor y una copia de seguridad en frío. Cada firmante usa una hardware wallet; ninguna clave en un servidor.
• Solana: multisig Squads con la misma configuración 3 de 5 y los mismos firmantes.
• Rotación: cada firmante rota anualmente o al marcharse; cualquier rotación individual es una transacción de Safe/Squads.
• Ningún keeper en caliente puede desplegar. La EOA del keeper en NestJS (usada para llamar a charge() en la Fase 2) no tiene autoridad de despliegue, ni de actualización, ni dirección de comisiones.

Política de actualizaciones

• PaymentLinkReceiver por enlace: inmutable. Sin actualizaciones. Es una ganancia de confianza para los pagadores: el código al que pagan no puede cambiar después.
• PaymentLinkFactory: pequeño proxy UUPS propiedad de la multisig, con timelock de 48 horas en upgradeTo. Las actualizaciones no pueden cambiar los receptores ya desplegados.
• SubscriptionHub: el mismo patrón. La semántica de charge() y cancel() es estable entre versiones; si alguna vez necesitamos un cambio incompatible, desplegamos SubscriptionHubV2 y migramos en lugar de actualizar.
• Semántica de reembolsos y disputas: refund(txId) on-chain, invocable por el firmante del comercio (mediante su clave de API → EOA del keeper) o por la multisig de despliegue. El pagador no puede reembolsarse a sí mismo (igual que en el producto actual).

Estrategia de proveedores de auditoría

Preseleccionaremos tres empresas y haremos una auditoría principal + una revisión competitiva:

• Candidatos principales (EVM): Spearbit, Trail of Bits, Zellic.
• Candidatos secundarios (Solana): OtterSec, Neodyme.
• Alcance: PaymentLinkFactory, PaymentLinkReceiver, FeeSplitter, SubscriptionHub. Los programas Anchor tienen su propia auditoría en la Fase 4.
• Presupuesto: la auditoría es un requisito previo obligatorio para el lanzamiento en Base mainnet. Nada de mainnet antes del informe con todo corregido.
• Divulgación pública: los informes de auditoría se suben al repositorio y se enlazan desde /docs/non-custodial/security-model.

Riesgos y mitigaciones

• Ampliación descontrolada de la especificación. Mitigación: todo lo que no se pueda expresar como reparto en puntos básicos se aplaza a una fase posterior. La Fase 1 no se bloquea por impuestos dinámicos ni por ajustes por comercio.
• Disponibilidad de los firmantes de la multisig. Mitigación: 3 de 5, no 2 de 3, para que dos firmantes cualesquiera puedan no estar disponibles sin congelar los despliegues.
• Plazos de la auditoría. Mitigación: empezar ya las conversaciones con proveedores; publicar los contratos en testnet durante la auditoría; el despliegue en mainnet queda condicionado.
• Un caso de comisión olvidado. Mitigación: reproducir cada camino actual de drainSmartAccountWallet (nativo + ERC-20, con/sin soporte, con/sin comisión) como test de invariantes de Foundry antes de la auditoría.

Lista de estado

• Struct del reparto de comisiones aprobada y etiquetada
• Base seleccionada como cadena de lanzamiento de la Fase 1
• Tres proveedores de auditoría preseleccionados
• Multisigs de despliegue Safe (Base) y Squads (Solana) creadas y probadas
• ADR fusionado sobre la política de actualizaciones y el timelock
• ADR fusionado sobre la decisión del modelo de suscripciones
• Semántica de reembolsos / disputas documentada

Qué sigue

La Fase 1 implementa la especificación: Enlaces de pago basados en contratos en EVM.

---

Documentación de referencia: Estado de la Fase 0 · Modelo de seguridad · Arquitectura