Tutorial de Bot de Polymarket · Capítulo 6 de 32

Autenticación del bot de Polymarket y configuración de la wallet: wallets proxy vs EOA, generación de API key vía SDK, sigType 2 para Gnosis Safe, mejores prácticas de almacenamiento de claves y la migración de Magic a Privy.

Por Harley Young, redactora principal en Polymarkets.co.il. Última revisión: mayo de 2026.

Qué cubre este capítulo

El modelo de wallet de Polymarket tiene tres partes móviles: una cuenta de propiedad externa (EOA) que firma órdenes, un proxy de smart contract que mantiene los fondos y la API key de Polymarket CLOB que autentica las solicitudes HTTP. Lograr que las tres estén conectadas correctamente es, por lejos, el fallo más común del primer día para quienes construyen por primera vez, y se volvió más confuso después de la migración de Magic Labs a Privy en agosto de 2025. Este capítulo recorre cada pieza en orden de configuración, con las variables de entorno específicas y el flag de tipo de firma que necesita el código de producción.

  • Wallet proxy vs EOA: cuál usar para botear
  • Generar una API key (pasos del SDK)
  • sigType 2 y POLY_FUNDER_ADDRESS (Gnosis Safe)
  • Almacenamiento de claves: .env, vault, KMS
  • La migración de Magic Labs a Privy
  • Aprobar gasto de USDC/pUSD
  • Recuperación y respaldo de la wallet

Wallet proxy vs EOA: cuál usar para botear

Polymarket usa un patrón de wallet proxy de smart contract. Tu EOA - la dirección vinculada a tu clave privada - firma transacciones y órdenes. Un Gnosis Safe desplegado en una dirección determinística mantiene el pUSD y las shares de resultados reales. La dirección proxy es la que aparece en el panel de "wallet" de la UI de Polymarket; la EOA es la que firma.

Para bots, siempre firmas con la EOA (PRIVATE_KEY en env) y referencias la dirección proxy como POLY_FUNDER_ADDRESS en la configuración del cliente CLOB. Enviar órdenes usando la EOA como funder produce errores de "insufficient balance" incluso cuando el proxy está fondeado.

No puedes botear solo con la EOA: el flujo web de Polymarket siempre crea un proxy al registrarte. Confirma ambas direcciones con polymarket wallet show desde la CLI, o lee la dirección proxy desde la configuración de la UI de Polymarket.

Generar una API key (pasos del SDK)

La API de CLOB requiere tres credenciales: key, secret, passphrase. Estas no son la clave privada de tu wallet - son un conjunto de credenciales estilo HMAC vinculadas a tu wallet, usadas solo para autenticación de solicitudes HTTP.

Genéralas una sola vez con el SDK:

# Python
from py_clob_client.client import ClobClient
c = ClobClient(host="https://clob.polymarket.com", chain_id=137,
               key="<PRIVATE_KEY>", signature_type=2,
               funder="<PROXY_ADDRESS>")
creds = c.create_or_derive_api_creds()
print(creds.api_key, creds.api_secret, creds.api_passphrase)

Guarda la salida en un archivo JSON y cárgalo en cada arranque del bot; no lo regeneres por sesión - el servidor de la API cachea el conjunto de credenciales, y rotarlas con frecuencia puede activar la lógica de rate-limit. Las credenciales no vencen automáticamente. Rótalas solo si sospechas una filtración.

sigType 2 y POLY_FUNDER_ADDRESS (Gnosis Safe)

El argumento signature_type controla cómo CLOB valida las firmas de tus órdenes. Existen tres valores; dos son reales:

  • 0 / EOA: la EOA es tanto la firmante como la funder. Se usa para configuraciones poco comunes donde los usuarios importaron una clave privada directamente.
  • 1 / POLY_PROXY: contrato proxy heredado de Magic Labs. La mayoría de las cuentas pre-2025.
  • 2 / POLY_GNOSIS_SAFE: estándar actual. Los fondos están en un Gnosis Safe, la EOA firma.

Usa signature_type=2 para cualquier cuenta creada después de agosto de 2025 (la migración a Privy) o para cualquier cuenta en la que veas una dirección Gnosis Safe en la UI de Polymarket. La variable de entorno POLY_FUNDER_ADDRESS debe ser la dirección del Safe, no la EOA. Un signature_type que no coincide con el tipo de funder produce rechazos de órdenes que parecen "insufficient allowance" o "balance: 0" - el mensaje de error es engañoso.

Almacenamiento de claves: .env, vault, KMS

Tres niveles razonables de almacenamiento para la clave privada de la EOA.

  1. Archivo .env (desarrollo en una sola máquina). El archivo vive en el VPS, el bot lo lee al iniciar, la clave nunca sale del host. Adecuado para wallets de <$1k. Usa chmod 600 .env y asegúrate de que el .gitignore del repo lo excluya.
  2. Vault autohospedado (HashiCorp Vault, archivo cifrado con age o systemd-creds). Agrega un paso de desbloqueo al iniciar el bot. Vale la pena para wallets en el rango de $1k-$10k.
  3. KMS en la nube (AWS KMS, GCP KMS). El bot llama a KMS para descifrar la clave en memoria; la clave nunca toca el disco. Solo vale la complejidad operativa por encima de $10k o para flotas de múltiples bots.

Lo que nunca debes hacer: commitear una clave privada a git, pegarla en un chat, guardarla en un gestor de contraseñas que sincronice a servicios en la nube sin modo local-only. El radio de explosión on-chain de una filtración de la EOA de Polymarket es todo tu saldo de pUSD y tu inventario de shares de resultados.

La migración de Magic Labs a Privy

En agosto de 2025 Polymarket migró su proveedor principal de embedded wallet de Magic Labs a Privy. El efecto de cara al bot es pequeño pero específico.

Las cuentas pre-migración (creadas vía Magic) normalmente usan signature_type=1 (POLY_PROXY). Las cuentas post-migración usan signature_type=2 (POLY_GNOSIS_SAFE). Algunos usuarios migraron su cuenta vieja; otros conservaron la original. No hay forma de saber desde la API pública qué tipo usa tu cuenta - lo verificas intentando firmar una orden y observando el rechazo.

La migración también cambió cómo la UI expone la dirección funder. Los flujos viejos de la UI de Polymarket mostraban la dirección proxy en el dashboard; el flujo actual la oculta dentro de la configuración de la cuenta. El comando de CLI polymarket wallet show es la forma más limpia de confirmar ambos valores, sin importar cuándo se creó la cuenta.

Aprobar gasto de USDC/pUSD

Para que CLOB mueva tu pUSD al ejecutarse una orden, el proxy debe haber aprobado a los contratos del exchange de Polymarket como spenders. La UI de Polymarket configura estas aprobaciones durante el primer depósito. Para bots que fondean el proxy directamente, debes configurarlas manualmente.

Tres aprobaciones para configurar, una sola vez por wallet:

  1. pUSD (ERC-20) → contrato del exchange
  2. Conditional Tokens (ERC-1155) → contrato del exchange (para vender shares)
  3. Conditional Tokens (ERC-1155) → contrato de exchange NegRisk (para vender shares NegRisk)

Ejecuta polymarket approve desde la CLI en la configuración inicial. La transacción cuesta unos pocos centavos en gas de MATIC. Verifica con polymarket approve check - las tres deberían devolver "approved." El bug silencioso más común para quienes construyen por primera vez es la aprobación faltante de NegRisk, que falla solo al vender shares de mercados multioutcome y parece un error de saldo.

Recuperación y respaldo de la wallet

La wallet del bot tiene dos elementos recuperables: la clave privada de la EOA y la contraseña de la cuenta de Polymarket (que controla el acceso a través de la UI web, pero no por medio del SDK).

La clave privada de la EOA es lo único que importa para el bot. Pérdida = pérdida de todo lo que está en el proxy. Respaldo en frío: escríbela en papel, sella el papel en un sobre, guárdalo fuera del sitio. Respaldo en caliente: memoria USB cifrada. Nunca te la envíes por email; nunca la guardes sin cifrar en almacenamiento en la nube.

La contraseña de la cuenta de Polymarket se puede recuperar vía Magic Labs / Privy email recovery siempre que aún controles el email original de registro. No controla el acceso del bot - el bot usa directamente la clave privada de la EOA.

Si sospechas de una filtración de la clave: de inmediato retira pUSD y los tokens de resultados a una wallet nueva, genera una nueva EOA, y vuelve a desplegar el bot con la nueva clave. La clave filtrada no se puede revocar; solo se puede vaciar.

Preguntas frecuentes

¿Necesito una wallet separada para mi bot?
Sí, fuertemente recomendado. Usa una EOA nueva o un proxy wallet derivado de una cuenta de email nueva que solo tenga el capital que asignaste al bot. Si se filtra la clave del bot, solo están en riesgo los fondos del bot; tus posiciones principales siguen seguras.
¿Qué es sigType 2 en la API de Polymarket?
sigType 2 indica una firma de Gnosis Safe (wallet proxy), usada cuando inicias sesión con email/Google y Polymarket crea el proxy por ti. Para sigType 2, la variable de entorno POLY_FUNDER_ADDRESS debe ser la dirección PROXY (la que se muestra en la UI de Polymarket), no la EOA subyacente. Este es un bug de configuración muy común.
¿Cómo genero una API key de Polymarket?
Usa el SDK. En Python: ApiCreds devueltos por client.create_api_key() una vez que te hayas autenticado con tu wallet. En Node.js: similar vía @polymarket/clob-client-v2 client.createApiKey(). Guarda la key/secret/passphrase devuelta en tu .env (nunca la commitees a git).
¿Las API keys de Polymarket se pueden revocar?
Sí. Puedes derivar nuevas keys en cualquier momento vía el SDK; las keys viejas siguen siendo válidas hasta que se revoquen explícitamente con client.deleteApiKey(creds). La mejor práctica es rotar las keys periódicamente y revocar cualquier key que haya tocado una máquina comprometida.
¿Qué cambió cuando Polymarket migró de Magic Labs a Privy?
Los códigos OTP de login pasaron de 3 dígitos (vulnerables a fuerza bruta, explotados en el hack de diciembre de 2025) a códigos más largos más device binding vía Privy. Para bots, el cambio práctico es la ceremonia de auth - el SDK abstrae casi todo. Si tu bot estaba hardcodeado a endpoints de API de Magic Labs (raro), actualízalo al flujo de Privy.
¿Debería guardar las claves en un archivo .env?
Para un bot en un solo VPS: sí, con permisos correctos de archivo (chmod 600 .env, propiedad del usuario del bot). Para configuraciones multi-máquina o operación de nivel producción: muévelo a un secrets manager (AWS Secrets Manager, Vault, doppler.com). Nunca commitees .env a git, jamás.