Building the MyZubster Economic Layer: Payment Intents, Bitcoin, Credits and Zorgax Entitlements
Over the last development cycle, we completed an important architectural step for MyZubster: integrating a shared Economic Layer into main.
The goal was not simply to “add Bitcoin payments”.
We wanted a reusable economic primitive that can eventually serve AI agents, services, marketplaces, bounties, IoT infrastructure, robotics and environmental applications across the MyZubster ecosystem.
And we wanted Zorgax — our AI and knowledge layer — to consume that infrastructure rather than owning its own payment system.
The architecture
The direction is becoming increasingly clear:
Zorgax / AI Agents
↓
Applications & Services
↓
MyZubster Economic Layer
↓
Payment Intents
↓
Payment Rails
BTC / future rails
This separation matters.
Zorgax should understand products, credits, access and service usage.
It should not contain Bitcoin wallet logic.
The Economic Layer handles the common settlement primitives, while individual payment rails implement the asset-specific verification.
Payment Intent as a core primitive
At the center of the implementation is a new PaymentIntent.
Instead of treating a blockchain transaction as the business operation itself, MyZubster creates an intent describing what must be paid.
A simplified lifecycle looks like:
PENDING
↓
AWAITING_PAYMENT
↓
SUBMITTED
↓
CONFIRMED
With additional terminal/error states including:
EXPIRED
FAILED
CANCELLED
Each intent can bind together information such as:
- owner
- purpose
- asset
- network
- expected amount
- destination
- payment reference
- transaction ID
- expiration
- confirmation state
Amounts are represented using integer minor units — satoshis for Bitcoin — rather than floating-point values.
Bitcoin without putting private keys in the application
The Bitcoin rail was designed around an important constraint:
the MyZubster application does not need spending keys.
The architecture is intended for watch-only infrastructure, where addresses can eventually be allocated from an xpub-backed service and blockchain state verified independently.
The application works with:
Payment Intent
↓
Destination allocation
↓
BTC transaction
↓
Transaction verification
↓
Intent confirmation
The verifier checks the persisted server-side intent rather than trusting payment details sent back by the client.
We also introduced transaction replay protection: a transaction ID cannot simply be reused to satisfy multiple payment intents.
Confirmation of the same valid transaction against the same intent is designed to be idempotent.
Bitcoin remains disabled by default
This part is important.
Adding the architecture is not the same as activating production payments.
The BTC integration remains disabled by default.
We did not:
- activate mainnet payments
- configure production Electrum/xpub infrastructure
- execute a real BTC transaction
- deploy a production database migration
Before production activation, there is still additional hardening work around confirmation policy, concurrency, trusted verifier origins and operational infrastructure.
Zorgax credits
On top of the shared payment layer we built the first Zorgax economic model.
Zorgax now has server-authoritative products and pricing.
The browser cannot simply tell the backend:
“I bought 10,000 credits.”
Instead, the backend resolves the product and its price.
The flow becomes:
Zorgax Product
↓
Server-side Pricing
↓
Purchase Snapshot
↓
MyZubster Payment Intent
↓
Payment Verification
↓
Credit Grant
Credit balances are backed by a ledger.
The system tracks purchased and consumed credits, while purchase grants are protected against replay.
Metered usage also uses a unique usage reference so the same operation cannot accidentally consume credits twice.
FREE, PRO and DEVELOPER access
Credits are only part of the model.
We also added an entitlement layer for subscription-style access.
Zorgax can now reason about three access tiers:
FREE
PRO
DEVELOPER
FREE acts as the default fallback.
Paid purchases can grant PRO or DEVELOPER entitlements for a defined duration.
Entitlement grants are tied to purchases and designed to be idempotent.
Renewing the same tier extends the existing entitlement period instead of blindly creating unrelated access periods.
When multiple valid entitlements exist, the effective access level is resolved according to tier priority:
DEVELOPER > PRO > FREE
Authenticated monetization API
The integration also introduces authenticated endpoints for the economic layer.
Among them are APIs for:
/api/payments/intents
/api/zorgax/monetization/products
/api/zorgax/monetization/balance
/api/zorgax/monetization/ledger
/api/zorgax/monetization/checkout
/api/zorgax/monetization/access
/api/zorgax/monetization/entitlements
Ownership comes from authenticated server context rather than a client-provided user ID.
We intentionally did not expose a public endpoint that allows arbitrary credit minting or consumption.
Integrating with an evolving codebase
One of the more interesting engineering problems was not implementing the new services.
It was integrating them into an already evolving main.
MyZubster already had an earlier Zorgax checkout/subscription implementation.
Replacing it immediately would have introduced unnecessary regression risk.
So we introduced a temporary compatibility architecture:
zorgaxLegacyMonetizationService
↓
existing Zorgax flows
zorgaxMonetizationService
↓
shared Economic Layer
The canonical service also preserves the legacy public contract while existing callers are gradually migrated.
This is deliberately transitional.
A future cleanup can migrate the remaining legacy consumers and remove the compatibility layer once the shared primitives cover all existing behavior.
Testing the integration
The integration exposed another useful infrastructure issue.
The repository contains a Node/Jest test suite and a React frontend whose tests are designed to run through react-scripts.
Root Jest was discovering a frontend JSX test and trying to parse it without the React transformation pipeline.
The application test itself wasn't broken.
The wrong test runner was executing it.
We changed the root Jest configuration so /frontend/ remains the responsibility of the frontend test runner.
After the change:
Root Jest
67 test suites passed
283 tests passed
Frontend
4 test suites passed
10 tests passed
The Continuous Evidence Gate subsequently passed as well.
Security checks
The integration went through the repository's automated checks, including the Continuous Evidence Gate, npm security audit and secret scanning.
One external Vercel deployment check was rate-limited, which was an infrastructure quota condition rather than a code-test failure.
More importantly, the Economic Layer itself entered main without enabling production Bitcoin settlement.
Merged into main
The integration was completed through:
MyZubster PR #843 — feat(integration): merge Zorgax economic layer into main
The final merge commit is:
08d6e35
The integration brought the shared payment primitives, Bitcoin rail abstraction, Zorgax credits, ledger, purchases, entitlements and compatibility layer together with the current MyZubster codebase.
What comes next
Getting the architecture into main is not the finish line.
The next phase is hardening.
Some of the areas we want to address include:
- concurrent settlement race conditions
- server-controlled Bitcoin confirmation policies
- stronger verifier-origin restrictions
- rate limiting for AI and external search APIs
- explicit confirmation boundaries for AI-triggered write actions
- prompt-injection resistance
- privacy and data-retention transparency
- eventual removal of the legacy monetization compatibility layer
And later, additional settlement rails can use the same economic primitives rather than rebuilding the business logic for every asset.
Why this matters for MyZubster
The bigger idea is not a crypto checkout.
It is giving autonomous and human-operated systems a common way to express economic intent.
An AI agent may need to purchase a service.
A robot may eventually pay for infrastructure.
A bounty may need settlement.
An environmental project may distribute incentives.
An IoT device may consume a paid machine service.
Those systems should not each invent their own payment architecture.
The long-term direction is:
Intelligence
↓
Applications
↓
Economic Intent
↓
Verification & Settlement
↓
Physical and Digital Action
Zorgax provides intelligence and coordination.
The MyZubster Economic Layer provides reusable economic primitives.
Bitcoin is simply the first payment rail we are integrating into that architecture.
There is still a lot to build — but the foundation is now in main.
