Lo que hace ProwlFi
ProwlFi ofrece confidencialidad en las transacciones para agentes de IA basados en Solana. Combina direcciones sigilosas con pagos HTTP x402 para que cada pago llegue a una dirección nueva y no vinculable, mientras el operador conserva un registro de auditoría privado.
El problema es claro: un libro mayor público expone cada pago que hace un agente — a quién paga, cuánto y cuándo. Para los agentes autónomos que transaccionan constantemente, esto filtra estrategias, relaciones y flujos de efectivo.
ProwlFi lo soluciona permitiendo que los destinatarios publiquen una única meta-dirección de larga duración. Los remitentes derivan un nuevo destino de un solo uso para cada pago. Las direcciones resultantes son criptográficamente no vinculables. Una clave de visualización le permite al operador escanear la cadena y atribuir todos los pagos de forma privada. La confidencialidad es frente al público, no frente al operador.
El sistema funciona en Solana estándar con billeteras comunes y tokens SPL, sin necesidad de tokens especiales ni mezcladores.
Primeros pasos
Instala el SDK desde npm:
npm install @prowlfi/sdk
El SDK está basado en TypeScript y se ejecuta en Node.js. Crea una instancia de Prowl con una sola opción:
import { createProwl } from "@prowlfi/sdk"; const agent = createProwl({ chain: "solana" });
El parámetro chain inicializa el motor de derivación, el material de claves y el estado interno.
No se necesitan variables de entorno ni archivos de configuración adicionales.
El formato de la meta-dirección es prowl:<spend>.<view>, que codifica las claves públicas de gasto y visualización del destinatario.
El SDK expone tres interfaces — SDK de TypeScript, servidor MCP y una API REST — aunque los detalles de configuración de las dos últimas aún no están documentados.
Realizar un pago x402
Usa agent.payX402() para pagar a un endpoint de agente identificado por una meta-dirección Prowl.
Especificas el endpoint HTTP, el monto y el token:
const { receipt } = await agent.payX402({ url: "https://api.vendor.xyz/infer", to: "prowl:vendor-7", amount: 0.02, token: "USDC", });
Bajo el capó, esto resuelve la meta-dirección del destinatario, genera un par de claves efímero, deriva una dirección sigilosa de un solo uso, envía una solicitud HTTP, liquida el pago en la cadena y emite un anuncio que contiene la clave pública efímera más una etiqueta de vista de 1 byte.
El código de estado HTTP inactivo 402 Payment Required se convierte en una capa de liquidación funcional: los agentes se pagan entre sí directamente mediante HTTP, y los fondos llegan a direcciones recién derivadas.
Escaneo y barrido
Del lado del destinatario, escanea los pagos entrantes usando la clave de visualización:
const incoming = await agent.scan(agent.viewingKey());
El método scan obtiene los anuncios en la cadena y los filtra usando la etiqueta de vista de 1 byte, descartando de inmediato aproximadamente el 99.6 % de los datos irrelevantes.
Con el resto, intenta la derivación con la clave de visualización para recuperar claves gastables, devolviendo una lista de direcciones y montos.
El SDK también admite barridos sin gas — mover fondos desde direcciones sigilosas sin requerir SOL en el destino. El protocolo puede agrupar transacciones de barrido o patrocinar las tarifas de gas, aunque los mecanismos exactos no se detallan en la documentación actual.
Restricciones y limitaciones
Se aplican varias restricciones importantes:
- Sin auditar — El esquema de sigilo y el programa en la cadena están en desarrollo activo y aún no han sido auditados. El uso en la red principal es bajo tu propio riesgo.
- Montos visibles — Aunque la identidad del destinatario está oculta, los montos de los pagos permanecen en la cadena. Los montos confidenciales (usando BN-254) están en la hoja de ruta.
- Solo Solana — Actualmente solo admite la red principal de Solana. Se planea cobertura entre cadenas SVM.
- Confidencialidad, no anonimato — El operador con la clave de visualización puede atribuir todos los pagos. Esto no es un mezclador.
- Sin pasos de migración — No se proporciona información sobre actualizaciones de contratos, versionado o migración de datos.
Best Practices
- Asegure la clave de visualización — Es el único vínculo entre direcciones no vinculables y la identidad del agente, lo que permite una pista de auditoría completa.
- Diseño no custodio — Las claves de gasto se derivan de su semilla y nunca abandonan su proceso. Nunca comparta la semilla ni la clave de gasto.
- Utilice las abstracciones del SDK — La lógica de pago, el escaneo de anuncios y el barrido se gestionan por usted. No derive manualmente direcciones ocultas a menos que comprenda completamente la criptografía.
- Monitoree el progreso de la auditoría — Limite la exposición hasta que se complete una auditoría independiente. Siga las actualizaciones del proyecto para cuándo se alcance ese hito.
Para informes de vulnerabilidades de seguridad, consulte el archivo SECURITY.md en lugar de los problemas públicos.
