Custodia y arquitectura

Quipu no deploya smart contracts propios. La frase corta:

Quipu es un motor de orquestación que opera, en tu nombre y con tu permiso, sobre venues third-party (Uniswap V3, HyperLiquid, HyperLend) usando wallets delegadas con policies que prohíben withdrawals desde el backend.

Esta página describe ese modelo con suficiente detalle como para que confíes pero sin revelar superficie de ataque.

Tres capas de keys, tres responsabilidades

El modelo de custodia está documentado internamente en ADR-009 (hedge venue + custody) y ADR-017 (security primitives). La síntesis para el usuario:

Key	Quién la controla	Qué puede hacer	Qué NO puede hacer
Master wallet	Vos (vía Privy embedded wallet)	Firmar el depósito inicial, autorizar el agent, retirar fondos desde la UI	—
Agent wallet	El motor (delegada con expiry)	Operar LP, abrir/cerrar hedge, mover entre venues acotados a lo configurado	Withdrawals, transfers fuera del scope
Auth key del backend	El backend de Quipu	Emitir las acciones permitidas por la policy	Withdrawals, SendAsset, cualquier op no allow-listada

La key del backend está sujeta a una policy explícita firmada off-chain que:

• DENY Withdraw
• DENY SendAsset (transfer a addresses arbitrarias)
• ALLOW operaciones específicas necesarias para el ciclo LP + hedge

Implicancia: un compromiso del backend de Quipu no permite mover fondos a una dirección de un atacante. Las únicas operaciones que el backend puede emitir son las que la policy enumera explícitamente — y los withdrawals no están en esa lista.

Cómo verificarlo vos mismo

Cuando autorizás el agent desde la UI, la transacción que firmás es público — la policy queda registrada. Podés verificar que la policy del agent excluye Withdraw y SendAsset antes de aprobar la delegación.

Por qué este modelo y no smart contracts propios

Hay dos razones, en orden:

1. Auditar superficie — un smart contract custom propio agrega una superficie de ataque nueva (bugs en la lógica, upgradeability, governance, etc.). Operar sobre venues que ya están auditados (Uniswap V3, HyperLiquid, HyperLend) traslada ese riesgo a equipos especializados que ya hicieron ese trabajo.
2. Liquidez y composability — vos sos el dueño nominal de tus posiciones en cada venue. Si Quipu deja de operar, tus LPs y tu hedge siguen siendo accesibles desde sus interfaces nativas.

El trade-off es real: un protocolo custom podría implementar lógica de coordinación más fina (ej. atomicity entre exit LP y close hedge en la misma tx). Quipu lo resuelve a nivel de orquestación off-chain, asumiendo el cost-of-coordination sin romper la portabilidad de las posiciones.

Venues third-party — cuál es el rol de cada uno

Venue	Rol	Auditorías
Uniswap V3 (Arbitrum)	Pool ETH/USDC 5bps donde vive el LP del usuario	Auditado por Trail of Bits, ABDK, SamCzSun (Uniswap Labs)
HyperLiquid	Venue del short hedge — perp ETH-USD, isolated margin	Auditorías Zellic, Zenity (HL team)
HyperLend (HyperEVM)	Money market donde vive el yield reserve USDC	Audit pendiente del equipo HyperLend; pre-validado on-chain en S2/S4 stress tests

HyperLend en early stage

HyperLend es un protocolo joven en HyperEVM. Para limitar exposure, el sizing del yield reserve está acotado por usuario y se aplica un cap absoluto por contraparte (ver Riesgos → Counterparty). El usuario que acepta yield en este venue acepta también este perfil de riesgo.

Ejecución on-chain

Las transacciones en Arbitrum (mint/burn LP, bridges) se ejecutan via Alchemy Smart Wallet (EIP-7702) con sendCalls y gas sponsorship por el equipo Quipu durante alpha — el usuario no paga gas. Esto NO cambia la propiedad de los fondos: la EOA sigue siendo la wallet delegada del usuario, EIP-7702 sólo le agrega una capa de execution sin transferir ownership.

Las acciones en HyperLiquid (orders, register agent, builder fee) son firmas EIP-712 off-chain — Privy firma el typed-data, que el client de HL envía al endpoint de HyperLiquid. No hay transacción EVM en esto, así que no pasa por Alchemy.

Lo que esta página deliberadamente no detalla

Por seguridad operativa, no publicamos:

• La policy exacta del auth key (qué operaciones específicas están en la allow-list).
• Los addresses internos del backend ni los rotation schedules de las agent keys.
• La implementación de los keepers (cadencia de monitoreo, criterios de retry, escalation a operadores humanos).

Si sos un security researcher con interés en revisar el modelo, podés abrir un issue o contactarnos para una revisión bajo NDA.

Resumen

• No hay smart contracts propios de Quipu — solo orquestación sobre Uniswap V3, HyperLiquid y HyperLend.
• El backend no puede retirar tus fondos — las policies del auth key lo prohíben explícitamente.
• Si Quipu deja de operar, tus posiciones siguen siendo tuyas y accesibles en sus venues nativos.
• La delegación del agent es revocable por vos en cualquier momento desde la UI.