stipend

stipend.sh

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 (Protocolo de Contexto de Modelo) — stipend mcp — que expone siete herramientas a través de stdio, para que un agente pueda mantener y gastar dinero a través de la interfaz de herramientas que ya tiene. Ver servidor MCP a continuación.

La afirmación que vale la pena verificar

La falla que importa para un agente que mantiene dinero no es una clave robada. Es una transacción correctamente firmada que fue convencido 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 a un modelo, ubicada en el mismo 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 hacia la firma, y ninguna redacción en ningún contexto llega a ellos.

Comienza en stipend/policy.py. Son alrededor de trescientas líneas y es todo el argumento.

Los tres controles

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

El segundo es el que la gente entiende mal. Elevar un límite para permitir una compra debilita cada pago futuro 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 está por debajo del umbral. La dirección de un atacante es, por definición, una 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 de Protocolo de Contexto de Modelo (MCP), para que un agente pueda usarla a través de la interfaz de herramientas que ya tiene en lugar de invocar comandos externos.

stipend mcp

Habla JSON-RPC a través de 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, eso 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 mantenido, moneda nativa mantenida, 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 a continuación
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 límites, 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 límite es exactamente lo que un atacante pediría — por lo 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 tu billetera:

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 límite 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 qué 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 flujo 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. Ver LICENCIA.

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