We Built a Safer Bitcoin Payment Layer for Zorgax — Here's What We Learned
Adding Bitcoin to an application sounds simple.
Generate an address, wait for a transaction, verify the amount, unlock the service.
In a prototype, that might be enough.
In a system designed around AI agents and autonomous infrastructure, it isn't.
We've been working on the Bitcoin payment layer for Zorgax, the AI and knowledge component of the MyZubster ecosystem.
The latest implementation milestone is now complete locally:
60 test suites. 208 tests. All passing.
But the more interesting part isn't the test count.
It's what we had to design around.
One Checkout, One Bitcoin Address
The first architectural decision was to avoid using a single Bitcoin address for every payment.
Each checkout intent receives a different address derived from an Electrum-compatible watch-only wallet.
Payment Intent #001
↓
Address A
Payment Intent #002
↓
Address B
Payment Intent #003
↓
Address C
This gives us a much cleaner relationship between an intent and its blockchain activity.
Instead of asking:
Which customer sent this transaction?
we already have a strong association between the destination address and the checkout.
It also avoids unnecessarily reusing the same public address across unrelated payments.
The Application Doesn't Need the Spending Keys
A payment service needs to observe money.
It doesn't necessarily need permission to spend it.
That's why the architecture uses a watch-only boundary.
ZORGAX
↓
Watch-Only Wallet
↓
XPUB
↓
Address Derivation
↓
Blockchain Monitoring
The application can derive and monitor addresses without holding the corresponding private spending keys.
That's an important security boundary.
If the web application doesn't need the capability to spend funds, we shouldn't give it that capability.
Bitcoin Amounts Are Integers
Another rule: don't make financial correctness depend on floating-point arithmetic.
Bitcoin gives us a convenient smallest unit:
1 BTC = 100,000,000 satoshis
So internally we verify integer satoshi values.
Instead of reasoning about:
0.00125000 BTC
the system can reason about:
125000 sats
Expected amount:
125000
Received amount:
125000
Comparison:
125000 == 125000
Boring?
Absolutely.
That's exactly what I want from payment arithmetic.
Distributed Systems Retry Everything
Then we reach one of the more important problems.
Imagine the blockchain watcher detects a transaction.
It sends the event to the application.
The application processes it successfully.
But the acknowledgement gets lost.
The watcher retries.
Without protection:
TX detected
↓
Payment processed
↓
Network problem
↓
Retry
↓
Payment processed AGAIN
That's unacceptable.
So transaction processing needs to be idempotent.
The TXID becomes part of that boundary.
Incoming TXID
↓
Already processed?
↙ ↘
YES NO
↓ ↓
Stop Verify
↓
Record
The same blockchain transaction should not create multiple economic effects because a distributed system retried a message.
Valid Doesn't Mean Valid Everywhere
There's another subtle distinction.
A real Bitcoin transaction can be perfectly valid on-chain and still be invalid for a particular checkout.
That's why we also need anti-replay protections.
Payment verification isn't simply:
Is this TX valid?
It is closer to:
Does this transaction
↓
belong to this payment intent
↓
for this derived address
↓
for this expected amount
↓
and has it already been consumed?
The transaction has context.
That's especially important once machines start consuming payment APIs automatically.
Database State Is Part of the Deployment
Payment systems don't live entirely inside application code.
Adding new payment behavior changes persisted state too.
For Zorgax, that means MongoDB migration needs to be treated as an explicit deployment operation.
Not:
git push
↓
hope
But:
Code
↓
Tests
↓
Review
↓
Migration Plan
↓
Infrastructure Check
↓
Database Migration
↓
Deployment
↓
Enable Rail
The migration should be controlled independently from writing the feature.
Feature Flags Are Security Features Too
The Bitcoin rail currently remains disabled.
Not because the implementation hasn't been tested.
Because the surrounding production infrastructure isn't ready yet.
The code still needs production dependencies such as the watch-only wallet XPUB and a reachable Electrum boundary through appropriately protected infrastructure.
This gives us an important rule:
CODE COMPLETE
≠
PRODUCTION READY
A payment feature shouldn't become active just because somebody merged the code.
Infrastructure readiness is part of feature readiness.
Where We Are Now
The current local milestone includes per-intent Electrum watch-only addresses, anti-replay protection, TXID idempotency, integer satoshi verification and a controlled MongoDB migration path.
The implementation currently passes:
60 test suites
208 tests
──────────────
ALL PASSING
The generated patch was also checked using:
git apply --check
But no production commit, push, deployment, real database migration or Bitcoin transaction was performed as part of this milestone.
That distinction matters.
Why Are We Doing This Inside an AI Project?
Because Zorgax isn't intended to remain only a chatbot.
We're exploring what happens when AI systems become capable of interacting with services and infrastructure.
Eventually an agent might need to purchase something.
Maybe compute.
Maybe an API request.
Maybe access to a specialized dataset.
Maybe a physical service.
The workflow starts looking like this:
AI Agent
↓
Needs Resource
↓
Requests Service
↓
Receives Payment Intent
↓
Payment
↓
Verification
↓
Resource Unlocked
Now the payment layer becomes part of agent architecture.
Machine Payments Change the Threat Model
Humans are relatively slow.
Agents aren't.
An automated agent could make hundreds of requests, retry failed operations and coordinate multiple services simultaneously.
That means payment infrastructure designed for agents has to assume automation from the beginning.
AI AGENT
↓
Payment Intent
↓
Per-Intent Address
↓
BTC
↓
Electrum
↓
Blockchain Detection
↓
Verification Layer
↙ ↓ ↘
Amount TXID Intent
↓ ↓ ↓
sats idempotent replay
↓
Payment State
↓
SERVICE
This is where payments stop being just a UI problem.
They become a distributed-systems problem.
The Bigger Experiment
Bitcoin checkout is useful by itself.
But we're interested in what comes after it.
Imagine autonomous software where:
Agent A
↓
discovers
↓
Service B
↓
requests price
↓
Payment Intent
↓
settlement
↓
verification
↓
service delivered
No shopping cart.
No human clicking "Pay Now."
Potentially no traditional account relationship between the two systems.
Just protocols.
That creates a much larger engineering question:
What does payment infrastructure look like when the customer is software?
We don't have the complete answer yet.
But building the boring pieces correctly — integer amounts, idempotency, replay protection, isolated payment intents, watch-only wallets and controlled migrations — is probably where it starts.
Because autonomous payments won't become reliable by making agents smarter.
They'll become reliable by making the infrastructure underneath them predictable.
If you were designing payments specifically for autonomous AI agents, what would you prioritize first: Bitcoin, Lightning, stablecoins, traditional APIs, or protocol-native payments?