Modelo de seguridad
Esta página indica exactamente quién controla qué, qué se puede actualizar y dónde están los límites de confianza, antes y después de la transición no custodial.
Supuestos de confianza
Antes (modelo custodial de barrido)
| Quién | Controla |
|---|---|
| Servidor de la API de OrcaRail | WALLET_ENCRYPTION_KEY, hd_wallet_seed cifrado |
| Keeper de OrcaRail | Autoridad de firma unilateral sobre cada dirección de depósito |
| Pagador | Su propia wallet externa |
| Comercio | Configuración del destino de retiro; sin control de los fondos en tránsito |
Implicación: un compromiso de OrcaRail pone en riesgo los fondos en tránsito.
Después (modelo de contratos no custodial)
| Quién | Controla |
|---|---|
| Safe 3 de 5 (EVM) | Actualización del proxy de la factory (con timelock), reembolso de emergencia, ceremonia de despliegue |
| Squads 3 de 5 (Solana) | Autoridad de actualización de los programas Anchor |
| EOA keeper de OrcaRail por cadena | Wallet solo para gas; puede llamar a charge() pública y nada más |
| Pagador | Firma approve(SubscriptionHub, cap) o Approve de SPL; puede revocarlo en cualquier momento |
| Comercio | Destinos de retiro; firmante del multisig BTC por enlace |
Implicación: un compromiso de OrcaRail no puede mover los fondos en tránsito de EVM/Solana. El peor caso es una caída temporal del keeper (cobros retrasados), que el respaldo de Chainlink/Gelato mitiga.
Custodia de claves
Multisig de despliegue
- Safe de EVM (Base, Ethereum, Arbitrum, Optimism, Polygon): 3 de 5. Los firmantes usan hardware wallets (Ledger + HSM opcional). Ninguna clave de firmante en servidores.
- Squads de Solana: 3 de 5 con el mismo conjunto de firmantes.
- Rotación de firmantes: anual o cuando alguien se marcha; cada rotación es una transacción del multisig.
- Ceremonia: cada despliegue y cada actualización se hace como una ceremonia del multisig anunciada; las PSBT firmadas (para BTC) y las transacciones del Safe se registran para auditoría.
EOA keeper
- Una EOA caliente por cadena para las llamadas a
charge()y al ejecutor de Relay. - Solo gas: sin destino de comisiones, sin autoridad de reembolso, sin propiedad de contratos.
- El material de claves vive en un gestor de secretos (Doppler / AWS Secrets Manager); la rotación se registra mediante el pipeline de infraestructura estándar.
- Alarmas cuando el saldo baja de
gasPrice × gasLimit × 100.
Claves BTC (Fase 5)
- Clave del comercio: la guarda el comercio (extensión de navegador, móvil, hardware wallet). OrcaRail nunca ve el material privado.
- Clave de la plataforma: la guarda un HSM o un servicio MPC (candidatos: Lit Protocol, Turnkey o un HSM propio). El servidor de la API no guarda la clave en bruto.
- PSBT de reembolso prefirmadas: cifradas en reposo con una clave KMS distinta.
Inmutabilidad de los contratos y política de actualizaciones
| Componente | ¿Actualizable? | Controlado por | Timelock |
|---|---|---|---|
PaymentLinkFactory | Sí (UUPS) | Safe 3 de 5 | 48 horas |
PaymentLinkReceiver (por enlace) | No | — | — |
FeeSplitter | No | — | — |
SubscriptionHub | Sí (UUPS) | Safe 3 de 5 | 48 horas |
payment_link (Anchor en Solana) | Sí | Squads 3 de 5 | (a nivel de programa) |
subscription (Anchor en Solana) | Sí | Squads 3 de 5 | (a nivel de programa) |
Los cambios semánticos incompatibles se publican como versiones nuevas (V2) y se migran, no se actualizan in situ. El timelock de 48 horas en los proxies da tiempo a la comunidad para ver las propuestas de actualización on-chain y reaccionar.
Postura de auditoría
- Auditoría principal de los contratos EVM iniciales (
PaymentLinkFactory,PaymentLinkReceiver,FeeSplitter,SubscriptionHub) antes del lanzamiento en la mainnet de Base. Proveedores preseleccionados entre Spearbit / Trail of Bits / Zellic. - Auditoría de Solana de ambos programas Anchor antes del lanzamiento en la mainnet de SOL. Proveedores entre OtterSec / Neodyme.
- Revisión competitiva o bug bounty junto a la auditoría principal.
- Informes de auditoría publicados en abierto y enlazados desde la Referencia de contratos.
- Auditorías delta para los cambios relevantes posteriores (por ejemplo, nueva lógica de comisiones o nuevos estándares de token).
Respuesta a incidentes
- Guardias rotativas en PagerDuty para caídas del keeper, retrasos del indexador y saldo de la EOA keeper.
- Controles de pausa: las factories y
SubscriptionHubtienen unpause()que puede invocar el multisig; los receptores por enlace no se pueden pausar (una ventaja de confianza para los pagadores). - Bug bounty: programa público centrado en los contratos y en la lógica del indexador; los pagos salen de la tesorería de la plataforma.
- Divulgación: los incidentes relevantes tienen un postmortem publicado en un plazo de 30 días, firmado por los firmantes del multisig.
Aspectos destacados del modelo de amenazas
| Amenaza | Mitigación |
|---|---|
Doble cobro por reorg en SubscriptionHub | Invariante monótono de lastChargedAt |
| ERC-20 no estándar al estilo de USDT | SafeERC20 en todas partes; tests de invariantes |
| Tokens con comisión en la transferencia | Lista de tokens permitidos controlada por el multisig |
| Sabotaje del predespliegue CREATE2 (alguien envía antes del despliegue) | deployAndPay de la factory es idempotente; el saldo que espera en la dirección prevista sigue siendo recuperable mediante un despliegue dirigido por la factory |
| Compromiso del keeper | EOA solo para gas; sin autoridad sobre los contratos |
| Compromiso de un firmante del multisig | Umbral 3 de 5; solo hardware; rotación anual |
| Delegado de Solana revocado a mitad de una suscripción | charge() emite ChargeSkipped(DelegateRevoked); email + webhook estándar |
| Pérdida de la clave BTC del comercio | Opción de clave de respaldo durante el alta; recuperación mediante ceremonia del multisig documentada |
| Caída del indexador | Alchemy como principal + RPC público de respaldo; conciliación cada hora |
| Agotamiento de la política del paymaster | Alerta al 70 % de la cuota; el keeper paga su propio gas como respaldo |
Transparencia de custodia
Tras la Fase 7, podemos afirmar con hechos:
- OrcaRail guarda cero material semilla de EVM.
- OrcaRail guarda cero material semilla de Solana.
- OrcaRail guarda una clave de firma del lado de la plataforma para Bitcoin; esta clave por sí sola no puede mover fondos: requiere la cofirma del comercio.
Esta postura se refleja en la actualización de los Términos del servicio que acompaña a la Fase 7.