Building Signed Wallet Requests for the MyZubster Marketplace
We have reached an important milestone in the MyZubster Marketplace: users can now create Marketplace requests using a verified EVM wallet and an off-chain cryptographic signature.
But there is an important distinction:
Signing a Marketplace request is not the same as making a blockchain transaction.
No payment is authorized.
No gas is spent.
No transaction is sent on-chain simply because someone wants to contact a seller or request a listing.
This separation is intentional.
Here is what we built, what is already implemented, what we tested, and what still needs to happen before calling the complete flow production-ready.
The problem we wanted to solve
A Marketplace request needs stronger evidence than a simple anonymous button click.
We wanted MyZubster to be able to answer questions such as:
- Which authenticated account created this request?
- Which wallet controlled by that user signed it?
- What listing was being requested?
- What were the economic conditions at the moment of signing?
- Has the same authorization already been used?
- Did the listing change between review and submission?
At the same time, we did not want every Marketplace interaction to become an on-chain transaction.
That would introduce unnecessary gas, wallet friction and blockchain state for an action that is fundamentally still a request between two people.
So we separated identity, intent, payment and blockchain evidence.
The architecture
The current flow is approximately:
MyZubster account
↓
Connect EVM wallet
↓
Wallet ownership challenge
↓
personal_sign
↓
WALLET_VERIFIED
↓
Open Marketplace listing
↓
Request challenge
↓
Review signed economic snapshot
↓
personal_sign
↓
Backend verifies signature
↓
Challenge consumed atomically
↓
MarketplaceOrder
status: REQUESTED
The important part is what does not happen:
Marketplace request
≠ payment
Marketplace signature
≠ blockchain transaction
Wallet verified
≠ seller paid
REQUESTED
≠ ACCEPTED
The browser uses an EIP-1193 wallet provider and personal_sign.
It does not need to call:
eth_sendTransaction
eth_sendRawTransaction
for the request flow.
1. EVM wallet verification
The first layer we implemented is wallet ownership verification.
The backend provides endpoints for the wallet lifecycle, including:
POST /api/wallet/challenge
POST /api/wallet/verify
GET /api/wallet/me
DELETE /api/wallet/disconnect
A user connects an EVM-compatible browser wallet.
MyZubster generates a challenge with a nonce and expiry.
The wallet signs that challenge.
The backend verifies the signature and associates the verified wallet with the authenticated MyZubster account.
The resulting states distinguish between concepts such as:
WALLET_NOT_CONNECTED
WALLET_CHALLENGE_PENDING
WALLET_VERIFIED
WALLET_DISCONNECTED
This matters because:
CONNECTED != VERIFIED
Simply seeing a wallet address in the browser is not evidence that the authenticated MyZubster user controls it.
2. Replay-resistant challenges
Signing something once should not create a reusable authorization.
Challenge consumption was therefore hardened against replay.
A challenge has a lifecycle and cannot simply be submitted repeatedly to generate multiple Marketplace requests.
This gives us another important rule:
signature + consumed challenge
≠ reusable authorization
Challenge expiration, previous consumption and invalid signatures are handled separately.
3. Signed Marketplace requests
After wallet verification, the user can request a real Marketplace listing.
Instead of directly creating an order, the frontend first requests a Marketplace challenge:
POST /api/marketplace/orders/challenge
The server creates a canonical payload.
The user reviews the request and signs the server-generated message.
Only then does the client submit the signed request to:
POST /api/marketplace/orders
The backend verifies the signature before creating the Marketplace order in the REQUESTED state.
4. Binding the signature to listing economics
This was an important hardening step.
A signature should not authorize a request based on one price while the backend silently processes another.
The V2 Marketplace request therefore includes a snapshot of the listing economics.
Conceptually:
{
"schema": "MYZUBSTER_MARKETPLACE_REQUEST_V2",
"listingSnapshot": {
"price": 10,
"currency": "EUR",
"exchangeMode": "payment"
}
}
If the listing economics change after the challenge is generated but before the request is submitted, the backend rejects the request with:
MARKETPLACE_LISTING_CHANGED
The user must review the new conditions and sign a new challenge.
That means the signature represents the conditions the user actually saw rather than merely identifying a listing ID.
5. Atomic request creation
There is another subtle problem.
Imagine this sequence:
consume challenge
↓
database error
↓
order never created
The user would lose a valid challenge without getting the Marketplace request it was supposed to authorize.
We therefore moved signed request creation into a database transaction.
Challenge consumption and order creation are handled together.
The goal is effectively:
consume authorization
+
create REQUESTED order
=
one transactional operation
Notifications happen after the transaction commits rather than determining whether the core request transaction succeeds.
6. The browser flow
The React Marketplace now connects the existing Request action to the signed-wallet flow.
When the user requests a listing, MyZubster can:
check authentication
↓
request wallet connection
↓
verify wallet if necessary
↓
request Marketplace challenge
↓
show conditions to the user
↓
ask for personal_sign
↓
submit signed request
Before signing, the UI explicitly explains:
This signature creates a Marketplace request.
It does not authorize a payment.
It does not send a blockchain transaction.
No gas.
This distinction is part of the product design, not just technical documentation.
7. What we tested
The wallet/Marketplace backend checkpoint currently passes:
Test Suites: 6 passed, 6 total
Tests: 25 passed, 25 total
The coverage includes the wallet signature service, challenge consumption, signed Marketplace request service, transactional creation, end-to-end wallet Marketplace flow and the existing Marketplace lifecycle migrated to signed requests.
We also added browser-side tests covering cases including:
- successful signed request;
- an already verified wallet;
- wallet verification before the first request;
- user rejecting the signature;
- missing EIP-1193 wallet provider;
- listing economics changing;
- ensuring the request flow does not invoke an Ethereum transaction.
The React production build also completes successfully.
8. What already exists on GitHub
The implementation is now collected in the branch:
feat/wallet-marketplace-mvp
The work consists of nine commits covering wallet verification, replay protection, signed requests, transactional creation, V2 economic snapshots, end-to-end tests and frontend integration.
It is currently under review in:
MyZubster PR #1207 — Signed Wallet Marketplace Requests
The branch deliberately does not include unrelated local verifier material.
9. Where blockchain enters the architecture
MyZubster already has a separate Marketplace evidence anchoring path targeting Base.
That is intentionally different from the buyer request signature.
The current architectural separation is:
User wallet
↓
off-chain signature
↓
Marketplace intent evidence
Marketplace lifecycle
↓
COMPLETED
↓
evidence generation
↓
optional blockchain anchoring
The existing Base anchoring mechanism uses a dedicated server-side wallet for evidence anchoring.
A user's private wallet key must never be exposed to the frontend or backend.
And even when an evidence hash is anchored on-chain, we maintain another important distinction:
CONFIRMED_ON_CHAIN
!=
PHYSICAL_EVENT_VERIFIED
A blockchain can provide evidence that a particular digital digest existed and was anchored.
It does not magically prove that a physical product existed, that 100 kg of material was recycled, that a service was actually performed, or that an environmental claim is true.
Those claims require their own evidence.
What is still missing?
Passing tests is not the same as being production-ready.
There are several remaining steps.
Production deployment and public E2E verification
The new branch still needs to move through the normal review/merge/deployment process.
After deployment we need a real public end-to-end verification using the production HTTPS environment and a compatible wallet.
Stronger domain binding
The wallet challenge can be strengthened further with SIWE-style domain and URI binding.
That would make the context in which a signature is requested even more explicit.
Rate limiting
Wallet challenge and verification endpoints should receive production-grade rate limiting and abuse controls.
More idempotency guarantees
The signed request architecture already has replay protection and transactional challenge consumption, but additional database-level uniqueness around evidence/challenge identifiers can provide another defensive layer.
Money canonicalization
Before real payments become part of this flow, monetary values should use a strict canonical representation, such as integer minor units where appropriate, instead of relying on ambiguous decimal representations.
Payments
The signed request system deliberately does not implement automatic payment.
MyZubster's Marketplace direction remains free-first:
Create account
↓
SELLER_FREE
↓
Publish
↓
Receive requests
↓
Build Marketplace activity
↓
Activate payments only when actually needed
Payment onboarding must remain a separate, explicit action.
No silent subscription and no automatic charge should happen because a user connected a wallet or reached a listing threshold.
Seller payment infrastructure
Later phases still need to define and implement the production payment lifecycle:
NOT_CONFIGURED
→ ONBOARDING
→ REVIEW
→ READY
→ RESTRICTED / DISABLED
This includes payment-provider onboarding, payouts, refunds, disputes, webhooks, compliance boundaries and transparent Marketplace fees.
Zorgax Listing Assistant
Another planned Marketplace layer is Zorgax-assisted listing creation.
The idea is:
Seller starts listing
↓
Zorgax asks structured questions
↓
draft generated
↓
seller reviews/edit
↓
explicit confirmation
↓
publish
Zorgax should assist with fields such as title, category, description, price or FREE/BARTER mode, location, availability, characteristics and other structured listing information.
But evidence-first rules remain important:
ZORGAX_DRAFT
!=
SELLER_CONFIRMED
!=
PUBLISHED
Zorgax should help structure information, not invent factual claims.
Why this architecture matters
The interesting part for us is not simply "adding a crypto wallet to a Marketplace."
The objective is to connect several independent layers without pretending they prove the same thing:
Account identity
↓
Wallet ownership
↓
Signed intent
↓
Marketplace state
↓
Payment state
↓
Digital evidence
↓
Optional blockchain anchor
Each transition should have its own evidence.
That gives us a much more useful architecture than putting every interaction on-chain.
Blockchain is used where immutable digital anchoring can add value.
Cryptographic signatures are used where user authorization and intent need evidence.
Traditional database transactions are used where application consistency matters.
Payments remain their own explicit financial operation.
And claims about the physical world remain separate from all of them.
Current status
At this milestone:
EVM wallet linking IMPLEMENTED
Wallet ownership verification IMPLEMENTED
Challenge replay protection IMPLEMENTED
Signed Marketplace requests IMPLEMENTED
V2 economic snapshot IMPLEMENTED
Transactional request creation IMPLEMENTED
React wallet request flow IMPLEMENTED
Backend checkpoint 25/25 PASS
React production build PASS
Public production deployment PENDING
Public wallet E2E PENDING
SIWE-style domain binding PENDING
Production rate limiting PENDING
Real payment onboarding FUTURE PHASE
Zorgax Listing Assistant NEXT MARKETPLACE PHASE
The goal is not to put everything on a blockchain.
The goal is to make it clear what was signed, what was paid, what was recorded, what was anchored, and what has actually been verified.
That is the direction we are building toward with MyZubster.
MyZubster is being developed openly.
PR #1207 contains the current signed-wallet Marketplace implementation and its test coverage.
Feedback on the architecture, especially around wallet UX, signature-domain binding, replay protection and evidence design, is welcome.
