Por qué el cobro por allowance supera al escrow y a las session keys
20 de abril de 2026: todo producto de suscripciones cripto tiene que resolver el mismo problema: ¿cómo autoriza un pagador pagos futuros sin renunciar a la custodia? Hay tres respuestas realistas. Elegimos el cobro por allowance, y este artículo explica por qué.
Los tres modelos
1. Cobro por allowance (approve de ERC-20 + delegación SPL)
El pagador firma approve(spender, cap) una sola vez en el contrato del token. Después, el spender (nuestro SubscriptionHub o el programa de Solana) llama a transferFrom (EVM) o transfiere con autoridad delegada (SOL) cuando vence un periodo. El pagador conserva la custodia; el spender puede cobrar hasta cap durante la vida de la suscripción.
Cancelación: el pagador firma approve(spender, 0) o Revoke. A partir de ahí, ningún cobro puede salir bien.
Es lo que ya usa hoy el Cobro automático. La Fase 2 traslada el spender de una hot wallet controlada por la plataforma a un contrato on-chain, pero el lado del pagador no cambia.
2. Depósito en escrow
El pagador deposita los fondos de N periodos en un contrato de escrow por suscripción. El contrato los libera al comercio según el calendario. El pagador puede retirar el saldo no usado en cualquier momento (menos los periodos pagados).
3. Smart wallet con session keys
El pagador usa una smart wallet ERC-4337 y concede una session key con alcance limitado al contrato de suscripción. La session key solo puede hacer lo que permite su alcance (por ejemplo, «transferir hasta X USDC cada 30 días a esta dirección»). El pagador revoca eliminando la session key.
La puntuación
Evaluamos los tres en cinco ejes:
| Eje | Cobro por allowance | Escrow | Session keys |
|---|---|---|---|
| Custodia durante la suscripción activa | Pagador | Contrato de escrow | Pagador (mediante smart wallet) |
| Pasos de configuración para el pagador | 1 firma | 1 depósito (con gas) | 1 alta en una wallet 4337 |
| Compatibilidad de wallets del pagador | Todas las wallets | Todas las wallets | Solo wallets 4337 |
| Fondos bloqueados / capital de trabajo | Ninguno | N meses bloqueados | Ninguno |
| Experiencia de cancelación | Revocar el approve | Retirar + cancelar | Eliminar la session key |
| Riesgo de keeper | Cualquier llamante | Cualquier llamante | Cualquier llamante |
| Complejidad para el comercio | Mínima | Contabilidad de liberaciones | Configurar un bundler 4337 |
| Funciona con MetaMask / Phantom | Sí | Sí | No de forma nativa |
| Funciona con Ledger / hardware | Sí | Sí | Parcialmente |
| Claridad regulatoria | Alta | Menor (huele a escrow) | Alta |
Por qué no escrow
El escrow tiene el discurso más atractivo («los fondos del pagador están bloqueados en un contrato, no en una empresa»), pero la peor experiencia real:
- A los pagadores no les gusta bloquear N meses de fondos. Una suscripción de 20 $/mes con un escrow de 12 meses supone 240 $ bloqueados. Pone techo a la conversión.
- Los retiros se complican: el contrato tiene que llevar la cuenta de periodos pagados y no pagados, gestionar reembolsos parciales e impedir que el comercio toque fondos futuros.
- «Escrow que guarda fondos de clientes» tiene en varias jurisdicciones un tufo regulatorio que «allowance a un smart contract» no tiene.
Por qué no session keys
Las session keys en smart wallets 4337 son elegantes. Pero exigen que la wallet del pagador sea una smart wallet. En 2026 la mayoría de los pagadores siguen usando EOA (MetaMask, Rabby, hardware wallets, firmantes de Safe), y los pagadores de Solana usan wallets de keypair al estilo Phantom. Obligar a darse de alta en 4337 para una suscripción mata la conversión.
Hay un camino en el que 4337 se convierte en la wallet por defecto del pagador y las session keys pasan a ser triviales. Todavía no estamos ahí.
Por qué gana hoy el cobro por allowance
- Ningún cambio en la wallet del pagador. Funciona cualquier wallet que pueda firmar un
approvede ERC-20, es decir, todas. - Ningún fondo bloqueado. El pagador conserva la custodia; el cobro ocurre justo a tiempo.
- La revocación es universal.
approve(0)oRevokees una primitiva que ya muestra la interfaz de cualquier wallet. - El keeper es un commodity.
SubscriptionHub.charge(id)es público y sin permisos. NestJS, Chainlink, Gelato o un AVS de EigenLayer (consulta la Fase 6) pueden llamarlo. - El relato regulatorio es más simple. La plataforma nunca retiene fondos en tránsito.
Limitaciones conocidas y cómo las mitigamos
El cobro por allowance no es perfecto. Los inconvenientes, con honestidad:
1. Aprobaciones infinitas
Las wallets suelen proponer por defecto valores de approve infinitos. Los contratos maliciosos con allowances infinitos vacían wallets. Nuestra mitigación: la interfaz pide explícitamente una aprobación limitada (por ejemplo, 12 × monthly_amount para una suscripción anual), muestra la cifra en dólares y ofrece el texto «cancela cuando quieras». El contrato impone cap por separado del allowance de ERC-20.
2. Revocación entre ciclos
Un pagador puede revocar a mitad de la suscripción y el siguiente cobro fallará. Es el mismo modo de fallo que una tarjeta guardada que se cancela. Se gestiona con el webhook + email existentes: subscription-insufficient-allowance.hbs y subscription-past-due.hbs.
3. Allowance desactualizado tras un cambio de precio
Si el comercio sube el precio a mitad de la suscripción, el cap antiguo puede quedarse corto. Se gestiona con el invariante de cap, que revierte charge(), y con la interfaz del comercio pidiendo una nueva aprobación.
4. Cobro doble por reorganización
Un bot que aproveche una reorganización de bloques puede repetir charge(). Se gestiona con el lastChargedAt monótono de SubscriptionHub.
Qué cambia hoy para los pagadores
Nada. El flujo actual de Cobro automático ya pide approve(spender, amount) y SPL Approve: los mismos pasos. La Fase 2 traslada el spender a la dirección de un contrato no custodial. Tu wallet muestra la misma pantalla de permisos.
Qué cambia para los comercios
Nada en la forma de la respuesta de la API. El campo approval_spender_address del objeto auto_charge de la suscripción simplemente apunta al contrato SubscriptionHub en lugar de a una hot wallet de OrcaRail. Los webhooks se emiten en los mismos momentos.
Resumen
| Consideración | Ganador |
|---|---|
| Experiencia de alta del pagador | Cobro por allowance |
| Capital de trabajo | Cobro por allowance / session keys |
| Compatibilidad de wallets | Cobro por allowance |
| Claridad regulatoria | Cobro por allowance / session keys |
| Flexibilidad del keeper | Los tres |
| Simplicidad del contrato | Cobro por allowance |
El cobro por allowance gana claramente en compatibilidad de wallets y capital de trabajo, y empata o gana en todos los demás ejes. Por eso las suscripciones de OrcaRail se basan en él.
Relacionado: Fase 2: suscripciones por allowance · Documentación de cobro automático · Modelo de seguridad