We’re Turning MYZ Into a Real Marketplace Settlement Layer — Here’s Where We Are
Building a token is one thing.
Building the infrastructure that can safely connect an internal community economy to real-world settlement is something very different.
Over the last development cycle, we have been working on one of the most important architectural pieces of the MyZubster ecosystem:
the MYZ Conversion Gateway.
The goal is simple to describe:
MYZ
↓
Conversion / Redemption Gateway
↓
External Settlement Provider
↓
EUR / stablecoin / supported crypto
↓
Seller
But implementing that responsibly required us to solve several problems before even thinking about a “Convert” button.
And we have now reached an important milestone.
First: What MYZ Actually Is Today
This distinction matters.
In the current MyZubster architecture, MYZ is an internal reward and accounting unit.
It is used to represent contributions, rewards and economic activity inside the ecosystem.
Our canonical ledger explicitly treats it as:
asset: MYZ
on_chain: false
That means we are not pretending MYZ is already a listed cryptocurrency, and we are not pretending that Coinbase, Kraken or another provider currently supports MYZ.
Historical experiments and roadmap ideas around blockchain integration are different from the software that exists today.
This distinction became the foundation of the new architecture.
The Architecture We Built
Instead of turning MyZubster itself into an exchange overnight, we designed the system around an external settlement boundary.
The model is:
MyZubster Marketplace
│
▼
MYZ Conversion Gateway
│
▼
Compliance / Provider Router
│
▼
Authorized External Provider
│
▼
External Settlement
MyZubster can coordinate the transaction without automatically becoming the custodian or counterparty for every conversion.
That separation is deliberate.
- The MYZ Conversion Gateway
The Marketplace now contains a dedicated conversion layer.
Its responsibilities include:
Quote Engine
↓
Provider Adapter
↓
Fee Engine
↓
Settlement
↓
Receipt
↓
Audit Log
The gateway supports the concept of settlement targets such as:
MYZ
EUR
USDC
XMR
But schema support does not mean that every route is currently executable.
A real external provider must explicitly support the requested settlement path before it can become live.
The system fails closed when that proof is missing.
- Exact Financial Arithmetic
One design decision was non-negotiable:
no JavaScript floating-point arithmetic for financial values.
The fee engine therefore uses fixed-point decimal normalization and BigInt.
For example:
100 MYZ
│
├─ provider fee
├─ MyZubster service fee
│
└─ recipient amount
Amounts can be represented with up to 18 decimal places without relying on ordinary floating-point calculations.
This becomes increasingly important once multiple systems have to agree on exactly the same transaction.
- A Canonical MYZ Ledger
We also built a canonical ledger API in the core MyZubster repository.
The Marketplace no longer needs to invent its own interpretation of a user's MYZ balance.
Instead:
Marketplace
│
▼
Canonical MYZ Ledger API
│
├─ balance
├─ debit
├─ idempotency
├─ transaction references
└─ reconciliation evidence
The ledger is append-oriented and designed around exact decimal arithmetic.
A Marketplace account can be represented as:
marketplace:user:
Before redemption, the Marketplace verifies the canonical balance and creates a local reservation.
Only after external settlement has been independently reconciled can the canonical MYZ debit be committed.
- Reserve First, Debit Later
This was one of the most important design choices.
Imagine Alice has:
100 MYZ
and wants to redeem:
25 MYZ
We do not immediately destroy or debit those 25 MYZ.
Instead:
100 MYZ
│
▼
reserve 25 MYZ
│
▼
request external settlement
│
▼
verify settlement
│
▼
reconcile
│
▼
commit canonical debit
│
▼
75 MYZ
If settlement cannot be proven, the system cannot simply assume that everything worked.
That leads to the next problem.
- What Happens When a Worker Crashes?
External financial operations have an uncomfortable property:
sometimes the network fails after the external provider received the request.
Suppose this happens:
MyZubster
│
├── execute settlement ──► Provider
│
X connection lost
Did the settlement happen?
Maybe.
Automatically retrying could therefore produce:
settlement #1
+
settlement #2
double payment
So we introduced a persistent worker-operation registry.
Operations can move through states such as:
queued
running
retrying
recovery_required
completed
failed
cancelled
Workers acquire leases before executing settlement.
And there is an important rule:
an expired worker lease does not automatically mean “retry the payment.”
- Ambiguous Settlement Goes Into Recovery
We added an expired-lease recovery sweeper.
But the sweeper does something intentionally boring.
It does not:
retry settlement
release MYZ
write the canonical ledger
change the redemption
Instead, an expired running operation becomes:
recovery_required
with an explicit reason similar to:
MYZ_SETTLEMENT_LEASE_EXPIRED_AMBIGUOUS
The system is effectively saying:
Something happened here, and we don't have enough evidence to safely decide what happened next.
That is much safer than silently replaying a financial operation.
- Evidence Before Repair
We then built a reconciliation and repair-preview system.
An operator can inspect a redemption using evidence from several independent sources:
Canonical Ledger
+
External Provider
+
Worker Registry
↓
Trusted Evidence Aggregator
↓
Repair Preview
The preview engine can return decisions such as:
WOULD_ALLOW_NO_ACTION
WOULD_ALLOW_REVIEW
WOULD_BLOCK
But there is another important property:
mutatesState = false
automatedRepairAllowed = false
A repair preview is exactly that:
a preview.
It does not silently modify balances or replay payments.
- The Worker Registry Is Persistent
Worker state is stored persistently rather than only existing in process memory.
The registry records information such as:
operationId
operationType
redemptionId
reservationId
quoteId
providerTransactionId
attempt
maxAttempts
leaseOwner
leaseExpiresAt
nextRetryAt
lastErrorCode
That gives us something extremely useful after a crash:
evidence.
Instead of asking:
“What do we think the worker probably did?”
we can ask:
“What immutable references and external evidence do we actually have?”
- Cross-Repository Testing
The architecture crosses two repositories.
The core repository owns the canonical MYZ ledger.
The Marketplace owns the conversion, reservation, settlement-worker and reconciliation logic.
So we created a cross-repository contract test.
The intended test flow is:
Create canonical balance
↓
100 MYZ
↓
Marketplace reservation
↓
Redeem 25 MYZ
↓
Mock reviewed external provider
↓
Settlement
↓
Reconciliation
↓
Canonical debit -25 MYZ
↓
Final balance = 75 MYZ
↓
Replay same redemption
↓
NO second payment
NO second debit
That last part matters just as much as the successful transaction.
Financial infrastructure must test idempotency, not merely the happy path.
Where We Are Now
Two major pieces have already reached the main branches.
The Marketplace conversion/redemption architecture has been merged.
The canonical MYZ ledger API has also been merged into the core MyZubster repository.
We then added dedicated post-merge CI infrastructure for the canonical ledger and prepared a Marketplace staging vertical-slice pipeline.
The intended validation chain is now:
Canonical Ledger Verification
↓
Core Ledger Tests
↓
Marketplace MYZ Tests
↓
Settlement Worker Tests
↓
Reconciliation Tests
↓
Lease Recovery Tests
↓
Cross-Repository Contract
↓
Staging Safety Assertions
There is currently an infrastructure blocker unrelated to the MYZ implementation itself: the GitHub account used to trigger the workflows has been flagged by GitHub, and GitHub Actions is refusing to queue runs for that user.
GitHub reports:
Actions has been disabled for this user.
A support review has been opened.
That means we are not calling the new CI pipeline green yet.
The workflows exist.
The architecture exists.
The tests exist.
But until they execute successfully in the CI environment, the correct status is:
implemented, awaiting CI validation.
What We Have NOT Done
This is equally important.
We have not launched a MyZubster exchange.
We have not claimed that MYZ is supported by Coinbase, Kraken or another external trading venue.
We have not enabled production MYZ → EUR conversion.
We have not enabled custody.
And we have not connected a live settlement provider.
The current external settlement path used by the integration architecture remains mocked/test-oriented until a real provider and the appropriate operational/compliance model are selected.
The Next Milestone
Once GitHub Actions becomes available again, the next sequence is straightforward:
Run canonical ledger CI
↓
Fix anything that fails
↓
Validate core
↓
Run Marketplace staging E2E
↓
Validate cross-repo vertical slice
↓
Test failure/recovery scenarios
↓
Select real settlement provider
↓
Compliance + operational review
↓
Controlled integration
Only after those boundaries are satisfied does it make sense to expose the final Marketplace experience.
Eventually, the UX could become as simple as:
Receive payment in:
○ MYZ
○ EUR
○ USDC
○ supported crypto
100 MYZ
→ conversion quote
→ provider fee
→ MyZubster service fee
→ amount received
The simplicity of that screen would hide a lot of infrastructure underneath it.
And that's exactly the point.
Why We’re Building It This Way
It would have been much easier to create a button called:
“Convert MYZ.”
But a button isn't financial infrastructure.
The difficult part is everything underneath:
identity
+
ledger
+
exact arithmetic
+
reservations
+
idempotency
+
external settlement
+
worker leases
+
crash recovery
+
reconciliation
+
evidence
+
auditability
+
compliance boundaries
We're trying to build those foundations first.
MyZubster started with community contributions, open-source experiments, bounties and MYZ rewards.
The next challenge is connecting that internal economy to a settlement architecture without pretending the difficult parts don't exist.
We're getting closer.
But we're documenting every boundary along the way.
MyZubster is open source.
Developers interested in distributed systems, ledgers, reconciliation, marketplace infrastructure, privacy, robotics, IoT or decentralized communities can follow the development and contribute through MyZubster-Ecosystem on GitHub.
Top comments (0)