Building Zorgax Monetization: From Non-Custodial Bitcoin Verification to Persistent Payment Intents
Over the last few development cycles, Zorgax has been moving from an AI assistant experiment toward something that can eventually sustain itself economically.
That creates an interesting engineering problem:
How do you monetize an application with cryptocurrency without turning the application itself into a custodial wallet?
Our answer is increasingly based on one principle:
The application coordinates payments and verifies economic events. It does not need to own the user's private keys.
This post is an update on how that architecture is evolving inside MyZubster.
The Zorgax plans
The current monetization foundation defines three levels:
Zorgax Free
Zorgax Pro — €9.90 monthly equivalent
Zorgax Developer — €29.90 monthly equivalent
Paid plans are designed to support settlement through multiple crypto assets, currently including:
BTC, ETH, XMR and TARI.
But defining prices is the easy part.
The difficult part is proving that a payment actually happened before granting access.
Never trust “I paid”
A browser should never be able to tell the backend:
{
"plan": "developer",
"amount": "29.90",
"paid": true
}
and receive premium access.
Likewise, even a transaction ID supplied by a user isn't enough by itself.
The backend needs its own source of truth.
Our architecture is therefore evolving toward:
Authenticated User
|
v
Checkout
|
v
Server-side Quote
|
v
Persistent Payment Intent
|
v
External Crypto Payment
|
v
Trusted Chain Verifier
|
v
Payment Verification
|
v
Subscription ACTIVE
The important change is the Persistent Payment Intent.
Making payment intents persistent
Previously, Zorgax could create checkout information, but the next step was to make that information durable and tied to the authenticated user.
A payment intent now records server-side information such as:
intentId
owner
plan
asset
destination
quoted crypto amount
EUR price
quote timestamp
expiration
settlement status
The browser doesn't get to redefine those values during payment verification.
When verification happens, the backend retrieves the original payment intent and asks the appropriate trusted verifier to validate the transaction against it.
Conceptually:
verifySettlement({
asset: intent.asset,
paymentReference,
destination: intent.destination,
cryptoAmount: intent.quote.cryptoAmount
});
Notice what's missing.
The client isn't supplying the destination or expected amount.
Those values already belong to the payment intent.
Payment intents also expire
Crypto prices move.
A quote shouldn't remain valid forever.
Zorgax therefore currently gives checkout intents a limited lifetime of 15 minutes.
The lifecycle can look like:
QUOTED
|
v
PENDING
|
+----> EXPIRED
|
v
VERIFIED
|
v
CONSUMED
A stale checkout cannot simply be reused indefinitely.
Bitcoin: testing against real Electrum behavior
Another important lesson came from the BTC verifier.
Our first implementation expected Electrum's gettransaction command to return a decoded transaction object.
Testing against Electrum 4.8.1 showed something different.
It returned the serialized Bitcoin transaction.
So the verifier architecture was corrected to explicitly perform:
gettransaction
|
v
serialized transaction
|
v
deserialize
|
v
outputs[].address
outputs[].value_sats
Confirmation status is retrieved separately:
get_tx_status
|
v
confirmations
That distinction matters.
Stop guessing BTC units
The decoded Electrum output gives us something especially useful:
{
"address": "",
"value_sats": 7212
}
value_sats means we can reason about Bitcoin payments using integer satoshis.
No guessing whether a number represents BTC or satoshis.
No floating-point comparison for the critical verification decision.
Internally, the verifier can use integer arithmetic:
paidSats >= expectedSats
For payment infrastructure, explicit units are much safer than heuristics.
Confirmations are part of verification
Finding the correct destination and amount doesn't necessarily mean a payment should immediately activate a subscription.
The chain verifier also reports confirmations.
For example:
{
"confirmations": 0
}
A payment policy requiring at least one confirmation should therefore keep access inactive.
The trusted verification layer is responsible for enforcing that policy.
Preventing transaction replay
Another problem is payment-reference reuse.
One blockchain transaction shouldn't activate multiple independent subscriptions.
The persistent payment-intent model therefore introduces replay protection around settlement references.
Once a payment has been successfully consumed, the same reference shouldn't simply be reusable for another activation.
This sounds obvious, but it is an important property to enforce at the persistence layer rather than relying only on application logic.
From VERIFIED to ACTIVE
The new architecture connects a successful trusted verification with the existing Zorgax subscription lifecycle.
Conceptually:
Payment Intent
|
v
Trusted verification
|
v
VERIFIED payment
|
v
recordVerifiedPayment()
|
v
ACTIVE subscription
|
v
Zorgax Pro / Developer access
This is the bridge between blockchain settlement and application authorization.
Still non-custodial
None of this requires Zorgax to sign a Bitcoin transaction.
The verifier does not need to expose:
seed phrases
private keys
wallet passwords
spend keys
Signing stays outside the application.
That's an architectural boundary we're deliberately trying to preserve as the system grows.
For Bitcoin, we're also exploring progressively stronger operational isolation, including watch-only infrastructure and reducing privileges around the verifier process.
And this isn't only about Bitcoin
Bitcoin is currently giving us a useful reference implementation.
The broader architecture is multichain:
Payment Intent
|
+-----------+-----------+
| | |
BTC ETH TARI
| | |
verifier verifier verifier
|
Electrum
+ XMR
|
privacy-aware
verification
Monero requires a different verification strategy because its privacy model makes public-explorer-style verification inappropriate for this use case.
That is exactly why we want a common verification interface, rather than embedding chain-specific assumptions throughout the Zorgax application.
The Marketplace connection
This work also connects with the broader MyZubster Marketplace experiment.
The Marketplace is being designed around several possible economic interaction modes:
BTC
ETH
XMR
TARI
MYZ
barter
free exchange
The same principle applies there:
Economic coordination doesn't require custody of users' private keys.
Zorgax monetization is becoming one practical test of that idea.
What isn't finished yet
This is important.
The existence of a verifier, persistent payment intents and subscription lifecycle does not mean the payment system should already be described as production-ready.
We still need live end-to-end deployment testing, production provider configuration, further concurrency/replay hardening, operational isolation of verification services, and equivalent trusted verification paths for the other supported chains.
Open source development makes this evolution visible.
Instead of presenting a finished black box, we can show where assumptions failed, how the architecture changed, and why.
Recent development
The Bitcoin/Electrum verifier was introduced and subsequently hardened after testing against the actual Electrum 4.8.1 CLI behavior.
The latest work adds the persistent payment-intent layer connecting checkout data with trusted verification and subscription activation.
Relevant work:
BTC/Electrum verifier
MyZubster PR #815
Trusted payment verification
MyZubster PR #814
Electrum 4.8.1 hardening
MyZubster PR #817
Persistent payment intents + trusted activation
MyZubster PR #818
MyZubster Marketplace
MyZubster Marketplace repository
MyZubster core
MyZubster core repository
The bigger lesson
The interesting part of crypto payments isn't generating an address.
It's building a trustworthy boundary between an external economic event and an internal application permission.
For Zorgax, we're trying to make that boundary:
non-custodial, auditable, replay-resistant, server-authoritative and chain-independent.
There is still work ahead.
But we're getting closer to a complete path:
quote
↓
payment intent
↓
blockchain settlement
↓
independent verification
↓
subscription
↓
access
And we're building that path in the open.
Per DEV.to, metterei come cover una grafica 1000×420 con:
ZORGAX MONETIZATION
Checkout → Payment Intent → BTC → Electrum → Verification → ACTIVE
Non-custodial • No private keys • Open source
