We Built the First MYZ Conversion Gateway — Without Pretending MyZubster Is Already an Exchange
Today we pushed an important piece of the MyZubster architecture forward.
We built the first version of a MYZ Conversion Gateway inside the MyZubster Marketplace.
The goal sounds simple:
allow future automatic conversion from MYZ into currencies or crypto assets used inside the marketplace.
But the implementation is not just:
MYZ → EUR
Because once conversion becomes real, the architecture touches pricing, fees, settlement, auditability, compliance, external liquidity providers and the legal status of the asset itself.
So instead of pretending the problem is solved, we built the system around the real constraints.
The architecture
The current direction is:
Buyer / Seller
↓
MyZubster Marketplace
↓
MYZ Conversion Gateway
↓
Quote + Fee Engine
↓
Authorized External Provider
↓
Settlement
↓
Audit Trail
The most important design rule is simple:
MyZubster does not self-declare that a conversion happened.
The gateway is intentionally fail-closed.
If there is no explicitly configured provider capable of returning an executable quote and verifiable settlement evidence, the system does not invent a price, transaction ID or successful payment.
That boundary matters.
What we implemented
The new conversion layer introduces authenticated endpoints such as:
GET /api/conversion/capabilities
POST /api/conversion/provider-probe
POST /api/conversion/quote
POST /api/conversion/convert
GET /api/conversion/audit/:quoteId
The initial asset schema includes:
MYZ
EUR
USDC
XMR
That does not mean all of these markets already exist.
It means the gateway knows how to represent them.
Live settlement is a separate question.
Transparent fee separation
One thing I wanted to avoid from the beginning was hiding economics inside a single conversion rate.
So the gateway separates:
providerFee
myzubsterFee
recipientAmount
For example:
Gross recipient amount: 100 EUR
Provider fee: 0.50 EUR
MyZubster fee: 1.00 EUR
Final recipient amount: 99.00 EUR
The MyZubster service fee is configured in basis points:
MYZ_CONVERSION_FEE_BPS=100
which corresponds to:
1.00%
The fee engine uses fixed-point integer arithmetic rather than relying on normal JavaScript floating-point math for financial calculations.
Quotes are not just numbers
A valid quote must contain more than a rate.
The provider layer is expected to return something like:
quoteId
rate
providerFee
grossRecipientAmount
expiresAt
executable=true
Then the Marketplace applies its own transparent fee and produces the final amount shown to the user.
Quotes also expire.
A quote cannot remain executable indefinitely while market conditions change.
Settlement is evidence-driven
The conversion flow does not treat:
200 OK
as proof that settlement actually happened.
A provider execution must return verifiable settlement information such as:
status=settled
providerTransactionId
settledAt
evidence
The gateway then stores an audit event and generates a SHA-256 hash of the settlement evidence.
The important principle is:
No evidence → no settled status
The system also never generates a fake provider transaction ID.
User-scoped audit trail
Each conversion lifecycle can produce events such as:
quote_issued
execution_requested
settled
execution_failed
These records are scoped to the authenticated user.
This means the conversion layer is not only designed to execute transactions.
It is designed to answer:
Who requested it?
Which provider handled it?
What rate was quoted?
What fees were applied?
When did the quote expire?
Was settlement confirmed?
What evidence supports that settlement?
That is the kind of infrastructure we want around economic actions.
Idempotency matters too
Payment systems fail.
Networks timeout.
Users retry.
Servers restart.
So execution requests include an idempotency key derived from the quote ID.
The idea is to avoid this situation:
request times out
user retries
provider executes twice
Safe retry behavior is not glamorous, but it is exactly the kind of detail that decides whether a payment system is reliable.
We also separated candidate providers from execution providers
This was another important architectural decision.
A provider can be technically interesting without being approved for live execution.
So we now distinguish between:
candidate provider
and:
execution provider
A candidate can be probed and evaluated without giving it permission to execute conversions.
This allows us to investigate integrations safely.
First technical candidate: Coinbase Advanced Trade
We added an initial Coinbase Advanced Trade candidate probe.
Important wording:
candidate probe.
Not:
Coinbase supports MYZ
Not:
MyZubster has a partnership with Coinbase
Not:
MYZ can already be converted on Coinbase
The purpose is simply to test how a real external provider architecture could fit into the gateway.
The candidate remains non-executable.
Then we hit the real problem
This is probably the most valuable result of the entire implementation.
While building the gateway, we reached the real blocker:
What exactly is external MYZ?
Inside the current MyZubster architecture, MYZ is primarily represented as an internal reward/accounting ledger.
That means we cannot simply tell an external exchange:
convert 100 MYZ to EUR
unless there is a real externally identifiable MYZ asset or another legally reviewed redemption mechanism.
That is not a software problem.
It is an asset architecture problem.
So we created a dedicated blocker issue
We opened a new issue to define the external settlement path.
The questions now include:
What is the external representation of MYZ?
Which network or chain would it exist on?
What is its authoritative asset identifier?
How is internal MYZ reconciled with external MYZ?
Where does price discovery come from?
Who provides liquidity?
Who is legally responsible for the conversion service?
How are KYC/AML obligations handled?
How is settlement independently verified?
Until those questions have real answers, the gateway stays fail-closed.
That is intentional.
Why this matters
A lot of crypto systems begin with a token and then try to build utility around it.
We are trying to move in the opposite direction:
Utility
↓
Marketplace
↓
Economic interactions
↓
Settlement requirements
↓
Conversion architecture
↓
External asset design
The question is not:
How do we make MYZ tradable?
The better question is:
What useful economic activity exists inside MyZubster, and what settlement architecture is actually required to support it?
That changes everything.
The longer-term marketplace idea
The eventual user experience could look like this:
Buyer pays in MYZ
Seller chooses:
MYZ
EUR
USDC
XMR
Then:
MYZ
↓
Quote
↓
Provider conversion
↓
Provider fee
↓
MyZubster service fee
↓
Settlement
↓
Audit evidence
↓
Seller receives selected asset
This would allow MYZ to work as an economic coordination layer inside the ecosystem while sellers choose their preferred settlement currency.
But only after the external settlement path is real.
Current status
Today we have:
✅ Conversion Gateway architecture
✅ Quote engine
✅ Fee engine
✅ Provider adapter boundary
✅ Candidate-provider probing
✅ Quote expiry
✅ Audit trail
✅ Settlement evidence hashing
✅ Idempotency design
✅ Fail-closed execution
✅ Explicit provider approval guards
✅ Coinbase Advanced Trade candidate probe
✅ External-MYZ blocker identified
We do not yet have:
❌ Live MYZ/EUR market
❌ Approved MYZ listing
❌ Production provider integration
❌ Automatic live conversion
❌ Coinbase support for MYZ
❌ CASP partnership
❌ Regulatory approval for MyZubster as an exchange
And those distinctions are important.
What I learned from building this
The biggest lesson was not technical.
It was architectural.
You can build APIs very quickly.
You can build quote engines quickly.
You can build fee logic quickly.
But once software touches real economic settlement, the important questions become:
Who owns the asset?
Who prices it?
Who executes the trade?
Who holds the funds?
Who verifies settlement?
Who carries regulatory responsibility?
Good architecture makes those boundaries explicit.
Bad architecture hides them.
The next step
The next milestone is no longer simply:
write more code
It is:
define the external MYZ settlement model
Then we can connect that model to a provider capable of supporting the real asset and the real jurisdiction.
Until then, the gateway stays exactly where it should be:
ready to integrate, but unwilling to fake reality.
That is the kind of infrastructure we want to build inside MyZubster.
Top comments (0)