BizFlow Pilot V2 — Architectural Trust Model
The autonomous AI finance agent that never holds the keys. Turning verified business activity into policy-approved USDC payments on Arc, with tamper-evident audit proofs.
Core Security Invariant
Non-bypassable boundary between reasoning and execution
The Large Language Model is strictly restricted to advisory output. It never holds private keys, never has access to wallet credentials, cannot alter spending policies, and cannot directly call the payment adapter. All invoice text is treated as hostile untrusted data with automated prompt-injection quarantine.
Activity-to-Payment Proof Chain
Procurement begins with an authorized PO specifying items, quantities, and agreed unit price in USDC.
Physical inventory delivery is inspected, logged, and signed by warehouse personnel before any payment is considered.
PO lines, Goods Receipts, and Invoices are matched mathematically. Quantities must match exactly; unit prices must stay within 1% policy tolerance.
Agent evaluates cash-flow liquidity, payment terms, and vendor history to propose payment timing via structured JSON.
Pure server-side engine tests active vendor, wallet authenticity, spending caps, liquidity floor, and global kill switch.
Direct EVM or Circle Wallets settles USDC on Arc. Once confirmed, AuditAnchor.sol records the cryptographic proof.
Arc Network Technical Implementation
Arc is Circle's stablecoin-native Layer 1 blockchain where USDC is the native gas token. BizFlow Pilot handles Arc's unique dual-decimal architecture with compiler-enforced branded types:
Returned by eth_getBalance. Measured in atomic 1e-18 gas units. Handled strictly via NativeGasAtomic.
Standard ERC-20 interface at 0x3600000000000000000000000000000000000000. Measured in 1e-6 units. Handled strictly via UsdcAtomic.
Single Deployment Runtime Network Switch & Physical Schema Isolation
BizFlow Pilot V2 runs as a single unified deployment that allows users to toggle between Arc Testnet (Chain 5042002) and Arc Mainnet (Chain 5042) at runtime:
Mainnet and Testnet data are strictly separated into two PostgreSQL schemas (v2_mainnet vs v2_testnet) accessed via dedicated Prisma clients (getDb(network)). Tests and sandbox runs are hard-blocked from ever writing to or reading from mainnet.
Network state is managed via an authenticated bizflow_network cookie synchronized across browser tabs via BroadcastChannel. Mutating API endpoints require a matching X-Bizflow-Network header, returning HTTP 409 Conflict if a tab attempts an operation on a stale network context.