🏭 Urban Lab: Building a Sustainable Mobility Ecosystem with
Hi everyone! 👋
I'm Daniel Ioni, an independent developer and founder of Urban Lab, an experimental project combining smart electric scooters, AI-powered services, open-source software and privacy-focused payments.
Over the past few weeks, we've been working on several components of the ecosystem:
This article is a technical overview of what we're building, what we've tested and what still needs to be done.
⚠️
Important:The system is still experimental. Testing uses simulated data and/or Monero Stagenet. Any MYZ → XMR conversion examples shown below are application-level simulations unless explicitly stated otherwise. We are not presenting the system as a production financial service.
Urban Lab started with a simple idea:
What if a smart mobility service could combine physical vehicles, AI, open-source software and privacy-focused payments?
The scooter concept includes features such as:
But adding a payment system introduces an important question:
How can a customer and service provider reduce the amount of trust required between them?
That's where escrow becomes interesting.
Our experimental escrow architecture uses a 2-of-3 multisig model.
The three participants can be:
Two authorized participants are required for operations governed by the multisig scheme.
A simplified workflow looks like this:
Customer
│
▼
Create Escrow
│
▼
┌──────────────────────┐
│ 2-of-3 │
│ Multisig Escrow │
├──────────────────────┤
│ Buyer │
│ Seller │
│ Admin / Arbitrator │
└──────────┬───────────┘
│
▼
Release Workflow
│
▼
Monero
The application layer tracks the escrow state, while the actual wallet and multisig implementation is responsible for the corresponding Monero transaction workflow.
This distinction is important.
A database record saying:
status = RELEASED
does not by itself prove that a Monero transaction has settled on the network.
The current escrow backend is I-ECO-01, a Node.js and Express REST API.
The application exposes operations such as:
create
sign
release
cancel
status
list
The backend is responsible for application-level escrow management, including:
During development, we use Monero Stagenet and simulated application data.
A simplified example:
A customer requests a smart scooter rental.
{
"service": "Smart Scooter Rental",
"amount": 25,
"currency": "XMR"
}
The backend creates a unique escrow ID.
In a real deployment, the appropriate Monero wallet and multisig workflow would handle the funds.
During development, we distinguish between simulated balances and actual Stagenet transactions.
The buyer and service provider participate in the authorization workflow.
Buyer → authorization
Seller → authorization
Admin → optional authorization
Once the configured threshold has been reached, the application can update the escrow state.
SIGNED
The release workflow is then executed according to the actual wallet and multisig implementation.
For simulated tests, this can simply update the application state.
For Stagenet testing, the corresponding blockchain transaction can be independently verified.
Another part of the ecosystem is the experimental GitHub bounty system.
The idea is simple:
A GitHub issue can contain a bounty declaration such as:
💰 Reward: 5 MYZ
When the configured conditions are satisfied, the application can record the reward in the contributor's MYZ balance.
This creates a bridge between:
Open-source contribution → automated reward → ecosystem balance
| Endpoint | Method | Purpose |
|---|---|---|
/api/bounties |
||
| POST | Create a bounty | |
/api/bounties |
||
| GET | List bounties | |
/api/bounty-history |
||
| GET | View bounty history | |
/api/user-balance/:username |
||
| GET | Check MYZ balance |
The system is intended to automate accounting, not to replace GitHub's own security model.
Webhook authentication and authorization are important before exposing this functionality to production users.
We are also experimenting with a conversion layer between MYZ rewards and XMR-denominated values.
For development purposes, the API can expose functionality such as:
GET /api/exchange-rate
POST /api/convert-myz-to-xmr
GET /api/conversion-history
Example:
curl -X POST http://localhost:5003/api/convert-myz-to-xmr \
-H "Content-Type: application/json" \
-d '{
"githubUsername": "DanielIoni-creator",
"amountMYZ": 10
}'
A simulated response could look like:
{
"success": true,
"message": "[SIMULATED] Converted 10 MYZ to 0.01 XMR",
"txHash": "sim-tx-1742345678",
"newBalance": 90
}
The important word here is SIMULATED.
An application-level exchange rate does not automatically create a real market, redeemable asset or blockchain transaction.
Before any real conversion system could be deployed, additional work would be required around custody, liquidity, pricing, security and applicable regulations.
Urban Lab is also experimenting with connecting the escrow infrastructure to autonomous software and physical systems.
Current components include:
AI-based planning and interaction with the escrow infrastructure.
A physical mobility service concept with GPS and remote-control functionality.
A bot-oriented component for community, bounty and reward workflows.
A planning assistant for projects and resources.
The broader architecture looks like:
CUSTOMER
│
▼
AI / ROBOT
│
▼
ESCROW API
│
┌─────────┼─────────┐
▼ ▼ ▼
BUYER SELLER ADMIN
│ │ │
└─────────┼─────────┘
▼
2-of-3 FLOW
│
▼
MONERO
We're interested in exploring how autonomous agents can interact with structured payment workflows without giving a software agent unrestricted control over funds.
We also built a lightweight dashboard for monitoring the development environment.
It can display:
The dashboard is designed primarily for development and operational monitoring.
A production deployment would require authentication, HTTPS, access control and careful handling of sensitive information.
Urban Lab is being integrated with the wider MyZubster ecosystem.
The architecture is intended to connect:
MyZubsterWeb
│
▼
MyZubster API
│
▼
I-ECO-01
│
▼
Escrow Layer
│
▼
Monero Wallet
Potential functionality includes:
The project is being developed openly.
https://github.com/DanielIoni-creator/urban-lab
https://github.com/MyZubster-Ecosystem/myzubster
https://github.com/DanielIoni-creator/I-ECO-01
https://github.com/DanielIoni-creator/MyZubsterWeb
https://github.com/DanielIoni-creator/MyZubster-Social
The current development environment includes:
We have also performed more than 25 simulated escrow tests covering creation, authorization, release, cancellation and error handling.
Before considering real-money production use, we need to address:
Moving from Stagenet to mainnet is not simply changing an endpoint.
It requires confidence in the complete wallet, transaction, security and operational architecture.
Our next steps include:
Continue testing actual wallet and multisig workflows without exposing real funds.
Make escrow functionality accessible directly from the web interface.
Connect the software platform with GPS and vehicle-management systems.
Explore a mobile interface for rentals and payments.
Build reputation mechanisms for customers, contributors and service providers.
Review the architecture before considering mainnet.
Only after sufficient testing and security validation will we evaluate production deployment.
The project is open source and we welcome technical feedback.
You can contribute by:
The GitHub repositories are the best place to start.
Urban Lab started with a simple question:
Can smart mobility services combine AI, open-source software and privacy-focused payments in a practical architecture?
We're experimenting with one possible answer:
🛴 Smart mobility
🤖 AI and autonomous services
🔐 Multisig escrow
💰 Monero
🐛 Open-source bounties
🌐 MyZubster
We're still building.
We're still testing.
And we're deliberately using Stagenet and simulated data before considering real-money production workflows.
That's the point of building in public: share what works, document what doesn't, and let other developers challenge the architecture.
Urban Lab — Mobility, AI, Privacy & Open Source. 🚀🌿🔐
Daniel Ioni — Urban Lab