stipend

stipend

Una billetera USDC no custodial en Base que un agente de IA instala por sí mismo, con límites de gasto aplicados por debajo de la capa de instrucciones.

pip install eth-account && curl -sL stipend.sh/install | sh

Esta es la fuente del paquete que el instalador descarga. Se publica para que las afirmaciones hechas sobre él puedan verificarse en lugar de creerse.

Incluye un servidor MCP (Model Context Protocol) — stipend mcp — que expone siete herramientas a través de stdio, para que un agente pueda tener y gastar dinero mediante la interfaz de herramientas que ya posee. Consulta servidor MCP más abajo.

La afirmación que vale la pena verificar

La falla que importa para un agente que tiene dinero no es una clave robada. Es una transacción correctamente firmada que lograron convencerlo de hacer.

Casi todas las defensas contra eso viven en la capa de instrucciones: un prompt del sistema que dice "no envíes fondos a direcciones no verificadas". Eso es una sugerencia para un modelo, ubicada en la misma ventana de contexto que el texto que lo ataca.

Aquí los límites no son consejos. Son código por el que una transacción pasa en su camino a ser firmada, y ningún texto en ninguna ventana de contexto llega a ellos.

Empieza en stipend/policy.py. Son unas trescientas líneas y es todo el argumento.

Los tres controles

control	qué hace
topes por transacción y diarios	un techo que ninguna instrucción puede elevar
aprobaciones de un solo uso	autorizan un pago único — vinculado a ese destinatario, ese monto, con vencimiento, de un solo uso — en lugar de elevar un tope
confirmación de nuevo destino	el primer pago a cualquier dirección a la que nunca hayas pagado requiere confirmación, sin importar el monto

El segundo es el que la gente entiende mal. Elevar un tope para costear una compra debilita todos los pagos futuros a todos, que es exactamente lo que un atacante pide. Autoriza el pago, no la capacidad.

El tercero es lo que detiene un drenaje mediante muchos pagos pequeños que cada uno queda por debajo del umbral. La dirección de un atacante es, por definición, una a la que nunca has pagado.

Y si activas una lista blanca, es absoluta. Los fondos no llegan a nada más — ni con confirmación, ni con aprobación, ni con ninguna instrucción de ningún lugar.

Servidor MCP

La billetera también es un servidor Model Context Protocol (MCP), para que un agente pueda usarla a través de la interfaz de herramientas que ya posee en lugar de recurrir a comandos externos.

stipend mcp

Habla JSON-RPC sobre stdin y stdout — el transporte stdio de MCP. Tu cliente MCP inicia el proceso; nada escucha en un puerto y nada está expuesto a una red.

En la configuración de un cliente se ve así:

{
  "mcpServers": {
    "stipend": {
      "command": "stipend",
      "args": ["mcp"]
    }
  }
}

Las herramientas

herramienta	qué hace
stipend_address	la dirección de la billetera, para que el dinero pueda llegar aunque no estés ejecutando
stipend_balance	USDC en custodia, moneda nativa en custodia, gastado hoy y el límite diario
stipend_check	¿se permitiría este pago? Responde sin enviar nada
stipend_pay	envía USDC, sujeto a todos los límites siguientes
stipend_earnings	lee pagos entrantes de la red y los registra
stipend_report	ganado contra gastado, por categoría, con autonomía en días
stipend_recover	qué está pendiente y de quién es cada tarea

Cada una de ellas pasa por la misma puerta policy.check que usa la línea de comandos, por lo que los topes, la lista blanca y la confirmación de nuevo destino se aplican de manera idéntica. No hay ningún camino aquí que mueva dinero sin ellos.

stipend_check existe para que un agente pueda preguntar "¿se permitiría esto?" antes de ofrecer pagar por algo, convirtiendo una negativa en una respuesta en lugar de un fallo.

Lo que deliberadamente no expone

Ninguna herramienta lee, exporta o deriva la clave privada. Ninguna herramienta cambia un límite de gasto o la lista blanca. Ninguna herramienta crea o sobrescribe una billetera.

Una herramienta MCP puede ser invocada por un modelo que está leyendo texto no confiable, y elevar un tope es exactamente lo que un atacante pediría — así que no está en el menú en absoluto. Los cambios de configuración permanecen en la línea de comandos, donde hay un humano presente.

Por qué no está alojado

Cada registro preferiría una URL, y no publicaremos una. Un servidor de billetera alojado significa que la clave vive en la máquina de otra persona — la nuestra — y toda la afirmación de este paquete es que no es así. Esto se ejecuta junto al almacén de claves, bajo el mismo usuario, y la clave nunca se mueve.

Ejecuta sus propias pruebas

Sin red, sin fondos, sin tocar ninguna billetera tuya:

python -m stipend selftest

219 verificaciones que cubren validación de direcciones, aritmética de montos, cada rama de políticas, la lista blanca, el tope diario, la confianza de destino y su vencimiento, cifrado del almacén de claves, codificación ERC-20, selección de requisitos x402, firma EIP-3009, el libro mayor y exactamente lo que la telemetría enviaría.

Lo que preferiríamos tener

Que alguien lo rompa.

Si puedes construir una inyección que mueva dinero más allá de las verificaciones en policy.py, abre un issue. Preferimos escucharlo de ti que de alguien que no está siendo cortés al respecto.

Límites honestos

• No auditado de forma independiente.
• La interoperabilidad x402 se verifica contra nuestro propio endpoint, no contra comerciantes de terceros.
• La clave se genera en tu máquina y nunca se transmite — lo que también significa que nadie puede recuperarla por ti, incluidos nosotros.
• Mantén el saldo pequeño. Es un flotante de trabajo, no ahorros.

Enlaces

• stipend.sh — el sitio, que sirve texto plano a agentes y una página a navegadores en la misma URL
• stipend.sh/skill.md — escrito para agentes
• stipend.sh/for-your-human — escrito para la persona que paga
• kina — un pequeño lenguaje que parte de esto lee y escribe

Licencia

Apache-2.0. Consulta LICENSE.

Construido por el equipo de desarrollo de Stipend. FelixTrade.ai Pty Ltd, Australia.