The Bitcoin Quorum
Autonomous Multisig Treasury — An AI Agent Council for Enterprise Bitcoin Payments
What Is This
The Bitcoin Quorum is an autonomous, AI-powered Bitcoin treasury management system built for enterprises. Instead of a single person or a single private key controlling company funds, a council of four specialized AI agents collectively deliberate, vote, and cryptographically sign Bitcoin transactions — like a board of directors that runs continuously, never sleeps, and cannot be bribed.
The central insight is simple but important: if you give an AI agent unilateral control over a Bitcoin wallet, you have introduced a catastrophic single point of failure. Bitcoin transactions are irreversible. There are no chargebacks. A clever prompt injection, a hallucination, or a compromised model can drain a treasury in seconds with no recourse.
The Bitcoin Quorum solves this by making unilateral action cryptographically impossible. Every payment requires genuine consensus across multiple independent agents, enforced not by software policy but by Bitcoin's multisig protocol at the transaction level.
The Problem It Solves
Corporate accounts payable is slow, expensive, and fraud-prone. Invoice fraud costs businesses over $26 billion annually. Human approvers are susceptible to social engineering, urgency manipulation, and duplicate billing. Existing automation tools either require full human oversight (defeating the point) or offer no cryptographic enforcement of policy (making them trivially bypassable).
The Bitcoin Quorum replaces the human approval chain with an AI council that cannot be socially engineered, operates in milliseconds, checks more fraud signals than any human reviewer, and still requires a real cryptographic quorum before funds move.
How It Works — The Full Pipeline
When an invoice arrives, it passes through the following stages in order.
Stage 1: Ingestion and Pre-Processing
The invoice is uploaded to the dashboard as a PDF, image, or plain text. Before any AI agent sees it, a local middleware layer strips all Personally Identifiable Information from the document. Names, addresses, phone numbers, and private contact details are redacted. The agents make financial decisions without ever processing personal data, providing a GDPR-aligned privacy layer without any external service calls.
After redaction, the invoice text is enriched with relevant corporate policy context retrieved from a ChromaDB vector database seeded with the company's treasury guidelines. The agents deliberate with knowledge of actual company policy, not general LLM assumptions.
Stage 2: The Visionary — Strategic Approver
The Visionary is the growth-oriented agent. It evaluates the invoice for business value and executes three checks before voting. It calls the Mempool Sniper tool to fetch live Bitcoin network fees from mempool.space and determines whether current fee conditions are optimal for execution. It calls the Fiat Oracle to get the live BTC/USD exchange rate from CoinGecko and converts the invoice amount to the exact satoshi value required at that moment. It verifies that the arithmetic in the invoice is internally consistent.
If the business case is sound, fees are reasonable, and math checks out, the Visionary votes to approve.
Stage 3: The Auditor — Risk and Fraud Detector
The Auditor is the skeptic. It runs five independent checks in parallel using a ThreadPoolExecutor for speed, and any single failure is sufficient to trigger a rejection.
Policy Lookup queries the ChromaDB vector database for the relevant corporate rule for the invoice category and vendor. Duplicate Invoice Check cross-references the payment log to detect if the same vendor and amount combination has appeared within 30 days. Vendor Reputation Search uses the Tavily web search API to look for fraud complaints, scam reports, or legitimacy concerns about the vendor. Address Screening submits the recipient Bitcoin address to the Bitcoin Abuse community blacklist database. Domain Age Check performs a WHOIS lookup on the vendor's domain — domains registered within the past six months are flagged as high risk.
Additionally, the Auditor checks the Blockstream Esplora API to review activity at the recipient Bitcoin address for unusual transaction patterns.
Stage 4: The Executor — Consensus Enforcer and Transaction Builder
The Executor tallies the Visionary and Auditor votes. If both agree, it proceeds. If there is a deadlock, it escalates to the human founder via the dashboard.
On consensus, the Executor checks the invoice amount against the software spending threshold. If the amount exceeds the configured limit, the transaction is automatically blocked before any signing occurs. If within the limit, the Executor selects UTXOs using a privacy-aware coin selection strategy based on the payment type, constructs the Partially Signed Bitcoin Transaction (PSBT) using the BIP 174 standard, and routes it to the human confirmation modal.
Stage 5: Human Confirmation
Before any key touches the PSBT, the human founder is shown a summary modal on the dashboard containing the vendor name, amount in USD and satoshis, both agents' reasoning, the selected coin strategy, and a policy summary. The founder must explicitly click to authorize. This is not a UI checkbox — it is a required step before the threshold of 3-of-4 signatures can be met. Clicking reject cancels the transaction entirely and logs the decision.
Stage 6: Nunchuk Signing and Broadcast
Once the human confirms, the Nunchuk CLI co-signs the PSBT with the three agent keys (Visionary, Auditor, Executor). The fully signed transaction is broadcast to the Bitcoin testnet via the Esplora API. The dashboard displays the confirmed transaction ID and a direct link to mempool.space where the transaction can be independently verified.
The Red Team Agent
The Red Team Agent is an adversarial AI that runs in parallel to the main council when Red Team Mode is enabled on the dashboard. It reads the uploaded invoice and attempts to manipulate it before it reaches the deliberation stage — inflating amounts, inserting urgency language, substituting suspicious Bitcoin addresses, and crafting arguments designed to fool the Visionary into approving a fraudulent payment.
The council should reject the manipulated invoice. The Red Team exists to demonstrate that the system's fraud detection is robust enough to withstand deliberate, policy-aware attacks. Every Red Team run is saved as a full report including the manipulation applied, the arguments used, and the council's response. You can also manually inject custom attack prompts through the dashboard to test specific scenarios.
The Supervisor Agent
The Supervisor is the central orchestration layer that sits above the council. It is accessible via a text chat overlay on the dashboard and via inbound phone calls through Vapi, a voice AI platform.
By voice or text, the Supervisor can answer questions about wallet balance, current Bitcoin network fees, recent payment decisions, and company policy. It can set the treasury spending limit and signing delay, which are applied both at the software layer and via Nunchuk's Platform Key for cryptographic enforcement. It can trigger a full payment review by describing an invoice in natural language, which convenes the council and displays the pipeline on the dashboard in real time.
The voice interface requires the caller to state an authorization phrase before any commands are accepted. The phrase is configured in the environment and is checked case-insensitively. Policy questions are answered directly from the Supervisor's embedded context, not via external tool calls, making voice responses fast and reliable.
Bitcoin Architecture
3-of-4 Multisig with Miniscript
The wallet is a native SegWit P2WSH multisig wallet created with the Nunchuk CLI. Four cryptographic keys are held by four distinct parties: The Visionary, The Auditor, The Executor, and the Human Founder. Any transaction requires exactly three of these four keys to sign before the Bitcoin network will accept it.
The spending policy is expressed in Miniscript and compiled into Bitcoin Script embedded in every transaction output:
thresh(3, pk(visionary), pk(auditor), pk(executor), pk(founder))
This means the enforcement is not a database rule or a software check. It is mathematics baked into Bitcoin's transaction validation. No server, no API, and no compromised agent can override it.
PSBTs — Partially Signed Bitcoin Transactions (BIP 174)
The transaction is constructed as a PSBT and passed sequentially for signing. The Visionary key signs first (1 of 3 required), then the Auditor (2 of 3), then the Executor (3 of 3). Once the threshold is met and the human has confirmed, the PSBT is finalized and broadcast. The signing chain is visualized live on the dashboard's key distribution panel.
Nunchuk Platform Key Policies
Beyond the base multisig, the Supervisor can activate Nunchuk's Platform Key feature, which adds a fifth cryptographic enforcement layer. A spending limit configured here means that Nunchuk's servers will refuse to co-sign any transaction above that amount regardless of what the agents decided. A signing delay adds a mandatory waiting period after consensus, giving humans a cancellation window even after all agent keys have signed. These settings can be adjusted by voice during a call and are reflected on the dashboard immediately via WebSocket.
UTXO Coin Selection
Bitcoin wallets hold funds as individual Unspent Transaction Outputs rather than a single balance. The Executor applies a privacy-aware selection strategy based on the nature of the payment. Public commercial payments use standard coin selection. Sensitive or internal transfers use single-UTXO selection to minimize the on-chain footprint. Consolidation payments merge small UTXOs to keep the wallet efficient. This prevents blockchain analysts from linking unrelated company payments together.
BIP21 QR Code Parsing
Invoice images containing a Bitcoin payment QR code are decoded automatically. The system extracts the recipient address, amount, and label from the BIP21 URI embedded in the code, eliminating manual address entry and the transcription errors that have cost companies millions in misdirected Bitcoin payments.
Security Model
The system provides layered security at five distinct levels.
At the protocol level, the 3-of-4 multisig enforced by Miniscript makes unilateral spending mathematically impossible. No single compromised agent or key can move funds.
At the cryptographic policy level, the Nunchuk Platform Key enforces a spending cap and signing delay independently of the agent software. Even if the entire agent system were compromised, transfers above the configured limit would be blocked at the Bitcoin transaction validation layer.
At the consensus level, multi-agent deliberation with independent tools means that a single manipulated or hallucinating agent cannot carry a vote alone. Both the Visionary and Auditor must agree before the Executor will act.
At the application level, the software spending threshold provides an additional check before any signing begins. Payments above this limit are auto-rejected before the PSBT is even constructed.
At the human level, the mandatory confirmation modal means a human sees and approves every payment before funds move, regardless of agent consensus. The human founder's explicit action is required to complete the signature threshold.
The Dashboard
The dashboard is a real-time command center built with Next.js. It streams agent deliberations via WebSocket as they happen, with no polling or page refreshes required.
The agent pipeline is visualized as an interactive flow graph powered by React Flow, showing the invoice traveling through pre-processing, each agent node, the consensus check, and the execution stage. Nodes change color based on vote outcome.
The live debate panel streams each agent's reasoning in real time, including which tools were called and what they returned. Agents are prompted to disagree with each other and justify their positions, making the deliberation visible and auditable.
The Nunchuk failsafe panel displays a credit card style wallet status widget, the current state of all four keys as glowing buttons that illuminate green on signature, the pending transaction details, the signature progress bar, and the Platform Key policy settings.
The analytics page provides charts and graphs built from historical pipeline data, including approval rates, fee trends, vendor breakdowns, and the agent workflow graph.
Running the Project
Backend
cd backend
pip install -r requirements.txt
python main.py
Frontend
cd frontend
npm install
npm run dev
Generate demo invoices
python generate_demo_invoices.py
Environment variables
Copy .env.example to .env and fill in:
GROQ_API_KEYfrom console.groq.comTAVILY_API_KEYfrom app.tavily.comNUNCHUK_API_KEYfrom developer.nunchuk.ioVAPI_AUTH_PHRASE— the passphrase callers must say to unlock the voice agentSPENDING_THRESHOLD_USD— the software-layer spending cap in USD
Tech Stack
| Layer | Technology |
|---|---|
| Agent Orchestration | Python, LangGraph, LangChain |
| LLM Provider | Groq (Llama 4 Scout) |
| Bitcoin Wallet | Nunchuk CLI, Bitcoin Miniscript, BIP 174 PSBTs |
| RAG Memory | ChromaDB, PyMuPDF |
| Web Search | Tavily |
| Bitcoin Data | Mempool.space Esplora API, CoinGecko, Bitcoin Abuse |
| Voice Interface | Vapi, ngrok, Server-Sent Events |
| Frontend | Next.js, React Flow, Recharts, Lucide React |
| Backend API | FastAPI, WebSockets |
| PDF Generation | fpdf2 |
| Privacy | Local PII redaction middleware |
License
MIT

Log in or sign up for Devpost to join the conversation.