Enterprise financial infrastructure, without enterprise complexity.
Pakta convierte el flujo financiero real de una PyME —Excel, PDFs, email, apps contables— en un proceso agentic verificable: entiende la evidencia, resuelve excepciones y solo permite que el dinero se mueva cuando la obligación es realmente válida.
Una PyME puede tener una factura, orden de compra y aprobación aparentemente válidas, pero todavía pagar dos veces, pagar un monto equivocado o enviar fondos a una wallet de proveedor que cambió sin verificar. Pakta reúne esas evidencias, bloquea obligaciones con excepciones concretas y solo autoriza el pago cuando el payable está listo.
El contrato Soroban PayableGate controla el settlement en Stellar. Un issuer firma el Proof-of-Payable; register_payable comprueba la firma y fija en cadena el destinatario, activo, monto, vencimiento y hash del proof. Luego, el executor llama settle(payable_id): esa función no acepta un destinatario ni un monto nuevos y transfiere exactamente lo registrado desde un vault con límites. La API enlaza la transacción y los eventos con la factura para reconciliación. El activo de esta demostración es USDC de prueba emitido por Pakta, no USDC de Circle ni dinero real.
- GitHub: github.com/devmondoss/pakta
- Licencia: MIT, visible en la raíz del repositorio.
- Contrato PayableGate v4:
CBTQDZBJYL2JFQAT64OZYFK4PFOA3EG7CMVZ44FCBSAPDE5EXMTACS6S - Inicialización de v4:
e895036e…cad7c1408 - Actualización a v4:
67867c2f…d65b531220 - Fondeo del vault:
74f1eba3…22ec9cb - Manifiesto público:
deployments/testnet.json, con ID, red, hash WASM y hashes de transacciones; no contiene claves privadas.
Verificación directa realizada el 25 de septiembre de 2026: el contrato responde contract_version() = 4, su hash WASM es c598ec442ca216581a71b61f3e89eb02644613280e3f5aa24d65b471e92f0948, y reporta 61 000 USDC de prueba disponibles y 0 comprometidos. Las tres transacciones de v4 enlazadas arriba figuran como exitosas en Horizon. Las cinco wallets del demo tienen XLM de testnet y trustline del activo; eso no implica que las cinco hayan recibido pagos.
El manifiesto también conserva una transacción de settlement funcional del 24 de septiembre de 2026, anterior al despliegue de v4 del día 25. Es evidencia de una versión previa; aún no se presenta como un settlement de v4. Stellar reinicia testnet periódicamente, por lo que el estado y los enlaces deben comprobarse de nuevo al presentar la entrega.
Una PyME sufre los mismos problemas de Accounts Payable, control y reconciliación que una gran empresa, pero no tiene el stack de SAP/AWS/Bitwave para resolverlos.
El payment rail responde "¿podemos mover el dinero?". El agent wallet responde "¿el agente está autorizado a actuar?". Pakta responde la pregunta que nadie más responde:
"¿esta obligación empresarial específica está realmente lista para pagarse, a este destinatario, por este monto, ahora?"
Cuando las condiciones se cumplen, Pakta emite un Proof-of-Payable y habilita el settlement en Stellar (USDC). Cuando no se cumplen, no devuelve un error genérico: crea una excepción tipada con causa, dueño y acción requerida — y revalida automáticamente en cuanto se resuelve.
flowchart TD
A["Fuentes de evidencia<br/>Excel · CSV · PDF · email · ERP"] --> B["Ingesta y normalización<br/>Canonical Payable Model"]
B --> C["Análisis de Pakta<br/>extrae, clasifica y vincula evidencia"]
C --> D{"Verificación de política<br/>PO · invoice · receipt · wallet · approvals"}
D -->|"Falta evidencia o hay conflicto"| E["Excepción tipada<br/>causa · responsable · acción requerida"]
E --> F["Resolver y revalidar"]
F --> D
D -->|"Todo coincide"| G["Proof-of-Payable<br/>importe · destino · vigencia · hash"]
G --> H["PayableGate / Soroban<br/>registro y límites en cadena"]
H --> I["Settlement en Stellar testnet<br/>USDC de prueba"]
I --> J["Conciliación ERP y bitácora"]
classDef success fill:#dcecc6,stroke:#4d8120,color:#181713
classDef alert fill:#f3d6ce,stroke:#b54931,color:#181713
class G,H,I,J success
class E,F alert
La IA nunca es la autoridad final sobre el dinero: interpreta y propone, pero un kernel de verificación determinístico decide si el payable puede liquidarse. Esa es la distinción central de Pakta frente a "un LLM con acceso al treasury".
- En Cargar dataset, elegí una industria. Pakta ingesta un lote nuevo con IDs únicos para esa corrida y lo evalúa contra la política vigente.
- Las obligaciones con evidencia completa quedan en
READY; las que no cumplen muestran una excepción concreta, su responsable y la acción necesaria para resolverla. - Cuando el settlement de testnet está habilitado, Pakta envía los payables
READYuno por uno aPayableGate. La secuencia evita colisiones de nonce de la cuenta ejecutora de Stellar. - Cada settlement exitoso se vincula con su
tx_hash, ledger yproof_hash; el conector de demo marca automáticamente el posteo ERP comoRECONCILED. - El diálogo de cierre aparece solo cuando ya no quedan payables
READYde esa corrida. Muestra la cantidad y el total acumulado de todos los pagos liquidados, no solo el último.
El lote puede contener de 5 a 10 facturas: las excepciones se mantienen visibles como casos de control y los payables READY recorren automáticamente settlement y reconciliación. La notificación de cierre es una simulación visual del demo; la transacción de Stellar y los registros de actividad sí quedan trazados.
sequenceDiagram
autonumber
actor U as Usuario
participant W as Control Room
participant A as Pakta API
participant P as Política y proof
participant G as PayableGate
participant S as Stellar testnet
participant E as ERP demo
U->>W: Carga un dataset
W->>A: POST /demo/reset
A-->>W: Lote evaluado: READY y BLOCKED
loop Por cada payable READY
W->>A: POST /payables/:id/settle
A->>P: Revalida evidencia y construye proof
P-->>A: Proof firmado y vigente
A->>G: Registra y liquida el payable
G->>S: Ejecuta settlement de USDC de prueba
S-->>A: tx_hash y ledger confirmados
A->>E: Registra conciliación automática del demo
E-->>W: Estado RECONCILED
end
W-->>U: Resumen del lote con total acumulado
Invoice, PO, receipt, monto, presupuesto y firma del agente pueden estar perfectos — pero si el proveedor cambió su wallet de destino, esa relación todavía no está probada. Pakta bloquea el pago, crea una excepción con owner (Vendor Master / Treasury) y acción requerida (Reverify wallet ownership), y revalida automáticamente en cuanto se confirma la nueva wallet.
flowchart LR
UI["Next.js<br/>Control Room"] <--> API["Fastify API<br/>orquestación y audit log"]
API <--> DB[("Neon / PostgreSQL<br/>evidencia, política y estados")]
API --> AI["NVIDIA NIM<br/>extracción de documentos"]
API --> K["Rules Kernel<br/>verificación versionada"]
API <--> G["Soroban PayableGate<br/>proof y settlement"]
G <--> ST["Stellar testnet<br/>activo USDC de prueba"]
API --> ERP["Adaptador ERP del demo<br/>reconciliación"]
classDef chain fill:#d5e7ed,stroke:#356d86,color:#181713
classDef core fill:#dcecc6,stroke:#4d8120,color:#181713
class API,K core
class G,ST chain
| Capa | Responsabilidad |
|---|---|
| Ingestion & Normalization | Convierte Excel/CSV/PDF/email a un Canonical Payable Model común (Zod) |
| Agentic Core (LangGraph) | Extrae, clasifica, matchea invoice↔PO↔receipt y explica/enruta excepciones |
| Pakta Control Engine | Motor de reglas determinístico y versionado: vendor/wallet check, PO match, receipt match, budget/approval check, duplicate check |
| Company Context | Vendor registry, approval rules y policies como fuente de verdad (Supabase/PostgreSQL) |
| Payable State | BLOCKED (con reason code) o READY (con Proof-of-Payable) |
| Stellar / Web3 | Soroban PayableGate (Rust) autoriza el transfer sobre el Stellar Asset Contract (USDC) hacia la wallet del proveedor |
| Reconciliation | Los eventos/tx hash de Stellar se ligan de vuelta al payable original y se exportan al dashboard/Excel |
Principio de diseño: la IA orquesta operaciones, el settlement queda sujeto a un deterministic gate. Documentos sensibles permanecen off-chain; en cadena solo viven hashes, estado y commitments mínimos.
| Frontend | Next.js 16 + React 19 · TypeScript · Tailwind |
| Backend | Node.js ≥22 + TypeScript · Fastify · Zod |
| Datos | PostgreSQL vía Neon |
| AI / Agentic | NVIDIA NIM (API compatible con OpenAI) detrás de una interfaz de extracción agnóstica de proveedor |
| Blockchain | Soroban (Rust) · Stellar SDK · USDC vía Stellar Asset Contract (SAC) · SEP-10/SEP-45 |
| Infra | Vercel · Fly.io/Railway → AWS ECS · GitHub Actions · Sentry |
En el MVP, Treasury conserva sus claves y prefondea un vault Soroban con custodia acotada del float. Treasury fija límites por payable y por ventana; el contrato transfiere de su propio saldo solo a destinatarios y montos vinculados al proof firmado. Una contract account sin custodia queda como evolución posterior.
Pakta es: ingestion adaptativa + orquestación con AI + controles determinísticos + resolución de excepciones + settlement verificable + puente de reconciliación.
Pakta no es: otro ERP, un LLM con acceso libre al treasury, un custodio de claves privadas, un reemplazo de x402/MPP, un ledger contable completo, ni un requisito de guardar documentos empresariales on-chain.
- Research/validación — entrevistas SME y payment/stablecoin providers
- MVP hackathon —
.xlsx→ ingestion → reglas → excepciones → Proof-of-Payable → settlement en Soroban/testnet → reconciliación - Piloto SME — conectores de email/QuickBooks/Odoo/Zoho, policy builder, verificación de wallet de proveedores
- Operación agentic — agentes autónomos de seguimiento, herramientas MCP/A2A, resolución multi-paso
- Plataforma/protocolo — schema público de Proof-of-Payable, reason codes estándar, adapters de settlement
- Expansión enterprise — conectores SAP/Oracle, RBAC avanzado, privacidad selectiva
pnpm install
cp .env.example .env
# completa DATABASE_URL en .env
pnpm --filter @pakta/api dev
pnpm --filter @pakta/web devLa API se inicia en http://localhost:4000 y el dashboard en
http://localhost:3000. DATABASE_URL es obligatoria; NVIDIA_API_KEY solo
es necesaria para la ingesta de PDFs. Para verificar el contrato Soroban:
pnpm contract:testPara validar el monorepo, pnpm test ejecuta las pruebas que no necesitan
servicios externos. pnpm test:integration carga DATABASE_URL desde .env y
ejecuta en secuencia las suites de PostgreSQL, API y MCP sobre el esquema
pakta_test. En GitHub Actions, la suite de integración corre cuando está
configurado el secreto PAKTA_TEST_DATABASE_URL.
Toda la documentación vive en docs/, organizada por categoría (product, implementation, assets) con sus tags — ver el índice completo.
docs/product/Pakta_Documento_Maestro.md— tesis de producto completa, arquitectura, modelo de excepciones, threat model y referenciasdocs/implementation/Pakta_Plan_Implementacion.md— stack técnico, arquitectura de servicios y plan de ejecución por fasesdocs/implementation/Pakta_Division_Trabajo.md— división de trabajo del equipo (Web3/Settlement vs Agentic/AI)docs/implementation/Pakta_Arquitectura_Flujo.md— arquitectura y estado actual de los módulosdocs/implementation/Pakta_Dev2_Checklist.md— estado de ingestion, extracción, API y dashboard
Evidence before execution. Exceptions before loss. Proof before settlement.