Building a Multi-Asset Marketplace: MYZ, ETH, BTC and XMR in MyZubster

Building a Multi-Asset Marketplace: MYZ, ETH, BTC and XMR in MyZubster

MyZubster started with a simple idea: people should be able to exchange resources, knowledge and skills while preserving evidence of what actually happened.

Now we're extending that model to payments.

The goal is to make the marketplace flexible enough that a participant doesn't necessarily need to receive the same asset another participant wants to spend.

The architecture we're building looks like this:

Marketplace
│
├── MYZ
├── BTC
├── ETH
└── XMR
│
▼
Payment Intent
│
▼
Quote
│
▼
Payment Confirmation
│
▼
Conversion
│
▼
Settlement

The important part is that payment, conversion, settlement and marketplace activity remain separate events.

A simple example

Imagine Daniel publishes a calisthenics lesson on MyZubster.

Nicola wants to book it.

Daniel may prefer settlement in XMR, while Nicola may prefer another supported asset.

Conceptually:

Daniel
│
└── Calisthenics lesson
│
▼
MyZubster Marketplace
│
▼
Nicola books lesson
│
▼
Payment intent
│
▼
Nicola pays BTC
│
▼
BTC confirmed
│
▼
BTC → XMR
│
▼
XMR settlement
│
▼
Daniel

The opposite direction is part of the model too.

Someone receiving or holding XMR could request settlement in another supported asset:

XMR → BTC
XMR → ETH
XMR → EUR
XMR → USD

Our current prototype conversion model recognizes XMR, BTC, ETH, EUR and USD.

Where MYZ fits

MYZ is already used in the experimental MyZubster marketplace as its internal marketplace currency representation.

The existing marketplace prototype creates products, orders and transaction records denominated in MYZ.

The broader architecture we're moving toward is therefore:

             MYZ
              │

BTC ──┐ │
ETH ──┼── Marketplace ── Conversion / Settlement
XMR ──┘ │
▼
Seller preference

There is an important implementation distinction here.

MYZ currently exists in the marketplace prototype, while real MYZ↔crypto conversion has not yet been implemented.

We don't want documentation to imply liquidity or exchange functionality that doesn't exist.

Why XMR is interesting for the architecture

Rather than forcing every marketplace participant into one settlement asset, we're designing conversion as a separate layer.

For example:

Buyer asset Seller settlement

BTC ──────────────────→ XMR
ETH ──────────────────→ XMR

XMR ──────────────────→ BTC
XMR ──────────────────→ ETH

Future adapters could potentially support additional currencies without rewriting the marketplace itself.

The marketplace asks for a conversion.

A conversion provider performs it.

The settlement layer verifies the result.

This separation also means MyZubster shouldn't pretend to be an exchange simply because it can request a conversion from an external provider.

The conversion state machine

We have now implemented the first service model for this process.

A conversion moves through explicit states:

CREATED
↓
QUOTED
↓
SOURCE_PAYMENT_PENDING
↓
SOURCE_PAYMENT_CONFIRMED
↓
CONVERSION_PENDING
↓
CONVERTED
↓
SETTLEMENT_PENDING
↓
SETTLED

There are also states for failures, expiration and refunds.

Why so many states?

Because:

payment detected ≠ payment confirmed

payment confirmed ≠ conversion completed

conversion completed ≠ settlement confirmed

Collapsing those events into a single PAID flag would destroy useful provenance.

Quotes are separate too

Before converting an asset, MyZubster needs a quote.

Conceptually:

{
sourceAsset: "BTC",
sourceAmount: 0.01,
targetAsset: "XMR"
}

A future conversion provider would return something equivalent to:

{
provider: "...",
quoteId: "...",
targetAmount: "...",
feeAmount: "...",
expiresAt: "..."
}

The quote has an expiration because crypto prices move.

The current code models this information, but does not yet fetch real market quotes.

Never invent a transaction

This is one of the principles we're carrying over from the MyZubster Knowledge Protocol.

MyZubster shouldn't say:

PAYMENT_CONFIRMED

unless evidence exists.

For blockchain payments our service requires information equivalent to:

{
network: "MONERO",
transactionId: "...",
confirmed: true
}

The same principle applies to settlement.

Without the required transaction evidence, the state cannot become confirmed.

Conversion needs its own provenance

A source transaction doesn't prove that a conversion happened.

So we keep conversion evidence separate:

SOURCE TRANSACTION
│
▼
sourceTxId
│
▼
CONVERSION
│
▼
provider + conversion reference
│
▼
SETTLEMENT
│
▼
settlementTxId

This produces a much more useful audit trail.

Payment is not proof of service

This becomes especially interesting when payments are connected to the new MyZubster Skill Marketplace.

We're building marketplace categories for things such as:

Calisthenics
Thai Boxing
Art / Comics
Music
Sound Systems
Programming
Mentoring
Workshops

Suppose Nicola pays Daniel for a calisthenics lesson.

We deliberately maintain two independent chains.

Financial chain
Nicola
↓
Booking
↓
BTC payment
↓
BTC confirmed
↓
BTC → XMR
↓
XMR settlement
↓
Daniel
Knowledge chain
Daniel
↓
Calisthenics session
↓
Nicola participates
↓
Nicola attempts the movement
↓
Observable result
↓
Evidence

A successful payment does not prove that the lesson happened.

And a documented lesson does not prove that payment happened.

They can reference each other, but one does not replace the other.

The same applies to blockchain records

We're using another strict distinction throughout MyZubster:

RECORDED

means MyZubster has recorded an event.

ONCHAIN_RECORDED

should only be used when a real blockchain operation exists and we have the information required to verify it.

Putting a declaration on-chain proves that a particular commitment was recorded.

It doesn't automatically prove:

the lesson was good
the learner mastered the skill
the seller delivered everything promised
the participant is professionally qualified

Those require separate evidence.

What exists in code today

The experimental MyZubster Marketplace already contains the original marketplace service for products, orders and MYZ-denominated transaction objects.

We've now added a separate asset-conversion service.

Its current supported asset model is:

[
"XMR",
"BTC",
"ETH",
"EUR",
"USD"
]

It supports modeling both:

BTC / ETH → XMR

and:

XMR → BTC / ETH / EUR / USD

We also added tests for inbound and outbound XMR conversion flows and for preventing a conversion from being marked as settled without the required evidence.

What does NOT exist yet

This is just as important as what we've built.

The repository is still an experimental prototype.

We do not yet have production crypto payment processing.

We still need to implement:

real wallet/address handling
+
payment detection
+
confirmation policies
+
live quote provider
+
swap/conversion provider
+
fees and slippage handling
+
quote expiration
+
refund handling
+
persistent database
+
reconciliation
+
authentication/authorization
+
production API
+
marketplace UI
+
security review

And MYZ needs its own clearly specified economic and technical model before claiming real MYZ↔BTC/ETH/XMR convertibility.

The architecture we're aiming for

Eventually the MyZubster Marketplace could look like:

               MYZ
                │
    ┌───────────┼───────────┐
    │           │           │
   BTC         ETH         XMR
    │           │           │
    └──────┬────┴────┬──────┘
           │
           ▼
     PAYMENT INTENT
           │
           ▼
         QUOTE
           │
           ▼
  SOURCE CONFIRMATION
           │
           ▼
      CONVERSION
           │
           ▼
      SETTLEMENT
           │
           ▼
  MARKETPLACE RECORD
           │
   ┌───────┴────────┐
   ▼                ▼

Payment Evidence Service Evidence

This separation is becoming one of the central ideas behind MyZubster:

Don't just record that something happened. Record which event happened, what evidence supports it, and what it does not prove.

The marketplace can then connect money, resources, skills and knowledge without collapsing all of them into a single unverifiable transaction.

We're building it incrementally and keeping the boundary between working prototype code and future production infrastructure explicit.

MyZubster Marketplace — codice marketplace, Skills e conversion layer
https://github.com/DanielIoni-creator/MyZubster-Marketplace

MyZubster Knowledge & Evidence — Knowledge Cards, evidence, provenance e protocolli
https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir

MyZubster Knowledge Explorer — demo live
https://myzubster-knowledge.vercel.app/knowledge.html

Sito MyZubster
https://www.myzubster.com/

Nel post puoi chiudere direttamente così:

🔗 MyZubster
https://www.myzubster.com/

🛒 MyZubster Marketplace
https://github.com/DanielIoni-creator/MyZubster-Marketplace

🧠 MyZubster Knowledge & Evidence
https://github.com/DanielIoni-creator/Myzubster-fermentation-kefir

🔬 Live Knowledge Explorer
https://myzubster-knowledge.vercel.app/knowledge.html