Cómo nos ganamos tu confianza

Confianza por construcción.
No por promesa.

La mayoría de los MM te pide que confíes en ellos. Makerless está construido para que no tengas que hacerlo.

Auth solo con passkey
Sin contraseñas. En ningún sitio.
Sin permiso de retiro
Rechazado en el registro.
Passthrough L4 SNI
El edge no puede leer el tráfico.
Informes firmados Ed25519
Anclaje on-chain opcional.

Claves que nunca entregas.

Inicias sesión con dos passkeys. No hay contraseñas en este sistema — ni tuyas, ni nuestras, ni en ningún sitio. Tu clave maestra de cifrado se deriva en tu navegador desde la extensión PRF del passkey y nunca sale del Secure Enclave o llave hardware de tu dispositivo.

Cuando pegas tus claves API de exchange al desplegar, se cifran en tu navegador antes de llegarnos. Nosotros guardamos ciphertext. No podemos descifrarlo. No hay ruta de reset por soporte — por diseño.

  1. 1Authenticator (Touch ID / Yubikey)
  2. 2Secreto PRF (32 bytes, nunca sale del dispositivo)
  3. 3Par de claves X25519 (derivado en el navegador)
  4. 4Sellado AES-256-GCM de los secretos
  5. 5Ciphertext → tu droplet

Solo el dueño puede desplegar.

Antes de poder desplegar un bot para un token, firmas un challenge con la dirección dueña del contrato. Familia EVM y Solana al lanzamiento. Aceptamos roles AccessControl para tokens con propiedad renunciada (MINTER, PAUSER, DEFAULT_ADMIN).

Esto significa que solo dueños verificables operan liquidez para su propio token. Sin despliegues anónimos. Sin bots de alquiler contra tokens que el operador no controla.

Dirección del contrato

0xA1b2…dEf9

Challenge

prove-ownership:0xA1b2…dEf9:1716000000

Firma verificada · rol propietario

Sin retiros. Nunca.

En el registro llamamos al endpoint describe-key del exchange y rechazamos avanzar si tu clave API permite retiros. Mismo control para IP allowlist ausente. Mismo control para alcance de futuros salvo que tu plan lo permita.

El ejecutor revalida estos alcances en cada reconexión. Si tú (o alguien con acceso a tu cuenta) amplía la clave tras el despliegue, el bot se pausa y te envía un email en segundos.

El peor ataque contra tu droplet pasa de «vaciar la cuenta del exchange» a «fastidiar al market maker». Tú lo notas. Rotas las claves. Sigues adelante.

Rechazada

  • read:
  • spot trade:
  • withdraw: ✕
  • ip allowlist: ausente

Aceptada

  • read:
  • spot trade:
  • withdraw: desactivado ✓
  • ip allowlist: definido ✓

Cada informe. Firmado. Anclado (opcional).

Cada orden que coloca el bot se registra en un log de auditoría encadenado por hash dentro del SQLite de tu droplet. A fin de mes, la tarea supervisora genera un informe JSON canónico cubriendo cada ejecución, cada cifra de PnL, cada cambio de parámetros.

El informe se firma con Ed25519. Opcionalmente, el hash se ancla en una cadena pública que tú elijas. El PDF que le das a tu CFO se renderiza desde el JSON canónico — así puede regenerarse y verificarse en cualquier momento futuro.

Esta es la diferencia entre confiar y probar.

Tu servidor. Tus datos. Tu decisión.

Tu droplet corre en tu cuenta de Hetzner o DigitalOcean, facturada a tu tarjeta. Ni siquiera nosotros podemos hacer SSH dentro. No hay canal de administración. No hay backdoor de soporte.

Las actualizaciones son explícitas: se publica una nueva imagen, recibes un email, haces clic para aplicar. Los parches de seguridad tienen un plazo duro de 72 horas antes de que el ejecutor se pause solo — ni siquiera nosotros podemos empujar código silenciosamente a un droplet en producción.

Si cancelas, el droplet sigue ahí. Los datos siguen ahí. Puedes auditar, archivar o destruir a tu propio ritmo.

Frontera de confianza

Tu cuenta (Hetzner / DigitalOcean)

  • · Droplet · sellado
  • · SQLite (log de auditoría)
  • · Claves de exchange (cifradas)
  • · Historial de conversación

↑ propiedad tuya ↑

Makerless (fuera del perímetro): DNS · distribución de imágenes · almacenamiento del ciphertext de backup

Entrégaselo a tu auditor.

No hacemos afirmaciones legales sobre MiCA, SEC ni ningún régimen específico. Te entregamos los artefactos que la mayoría de regímenes piden:

  • Un registro firmado y con marca de tiempo de cada acción sobre órdenes
  • Reconciliación independiente contra el historial de operaciones del exchange
  • Un anclaje on-chain por hash que prueba que el informe existía en un instante concreto
  • Un informe JSON canónico inspeccionable contra el historial del exchange

Lo que tú y tus asesores hagáis con eso en vuestra jurisdicción depende de vosotros. Hemos hecho los artefactos difíciles de falsificar y fáciles de comprobar.

Para tu contable

  • report-2026-04.json
  • report-2026-04.pdf
  • report-2026-04.sig