DEV Community

Daniel Ioni
Daniel Ioni

Posted on

🏭 Urban Lab: Building a Sustainable Mobility Ecosystem with

🏭 Urban Lab: Building a Sustainable Mobility Ecosystem with

🏭 Urban Lab: Building a Sustainable Mobility Ecosystem with Monero, Multisig Escrow and Automated Bounties

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:

  • πŸ” Monero 2-of-3 multisig escrow
  • πŸ€– AI and robot integrations
  • πŸ› Automated GitHub bounties
  • πŸ’° MYZ reward accounting
  • πŸ’± Experimental MYZ β†’ XMR conversion logic
  • πŸ“Š Real-time monitoring
  • 🌐 MyZubster integration

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.


πŸ›΄ The Urban Lab Concept

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:

  • GPS tracking
  • remote locking
  • AI integration
  • digital payments
  • automated service workflows

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.


πŸ” Monero Multisig Escrow

Our experimental escrow architecture uses a 2-of-3 multisig model.

The three participants can be:

  1. Buyer β€” the customer
  2. Seller β€” the service provider
  3. Admin / Arbitrator β€” an optional third participant

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

does not by itself prove that a Monero transaction has settled on the network.


βš™οΈ I-ECO-01

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
Enter fullscreen mode Exit fullscreen mode

The backend is responsible for application-level escrow management, including:

  • unique escrow IDs;
  • transaction state;
  • participant information;
  • authorization tracking;
  • cancellation;
  • expiration;
  • monitoring.

Technology stack

  • Node.js
  • Express
  • MongoDB
  • Monero Wallet RPC
  • WebSocket
  • HTML / JavaScript dashboard

During development, we use Monero Stagenet and simulated application data.


πŸ”„ Example Escrow Workflow

A simplified example:

Step 1 β€” Create

A customer requests a smart scooter rental.

{
  "service": "Smart Scooter Rental",
  "amount": 25,
  "currency": "XMR"
}
Enter fullscreen mode Exit fullscreen mode

The backend creates a unique escrow ID.

Step 2 β€” Fund

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.

Step 3 β€” Authorize

The buyer and service provider participate in the authorization workflow.

Buyer       β†’ authorization
Seller      β†’ authorization
Admin       β†’ optional authorization
Enter fullscreen mode Exit fullscreen mode

Step 4 β€” Threshold

Once the configured threshold has been reached, the application can update the escrow state.

SIGNED
Enter fullscreen mode Exit fullscreen mode

Step 5 β€” Release

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.


πŸ› Automated GitHub Bounties

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
Enter fullscreen mode Exit fullscreen mode

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

Example API

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.


πŸ’± MYZ β†’ XMR Conversion

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
Enter fullscreen mode Exit fullscreen mode

Example:

curl -X POST http://localhost:5003/api/convert-myz-to-xmr \
  -H "Content-Type: application/json" \
  -d '{
    "githubUsername": "DanielIoni-creator",
    "amountMYZ": 10
  }'
Enter fullscreen mode Exit fullscreen mode

A simulated response could look like:

{
  "success": true,
  "message": "[SIMULATED] Converted 10 MYZ to 0.01 XMR",
  "txHash": "sim-tx-1742345678",
  "newBalance": 90
}
Enter fullscreen mode Exit fullscreen mode

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.


πŸ€– AI and Robot Integration

Urban Lab is also experimenting with connecting the escrow infrastructure to autonomous software and physical systems.

Current components include:

Pytho AI

AI-based planning and interaction with the escrow infrastructure.

Smart Scooter

A physical mobility service concept with GPS and remote-control functionality.

MyZubster Robot

A bot-oriented component for community, bounty and reward workflows.

MIGHTY Planner

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
Enter fullscreen mode Exit fullscreen mode

We're interested in exploring how autonomous agents can interact with structured payment workflows without giving a software agent unrestricted control over funds.


πŸ“Š Monitoring Dashboard

We also built a lightweight dashboard for monitoring the development environment.

It can display:

  • total escrow operations;
  • pending transactions;
  • completed operations;
  • simulated XMR volume;
  • escrow IDs;
  • amounts;
  • current status.

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.


🌐 MyZubster Integration

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
Enter fullscreen mode Exit fullscreen mode

Potential functionality includes:

  • marketplace listings;
  • scooter rentals;
  • repair services;
  • bounties;
  • contributor rewards;
  • escrow creation;
  • transaction monitoring;
  • notifications.

πŸ“¦ Open Source Repositories

The project is being developed openly.

Urban Lab

https://github.com/DanielIoni-creator/urban-lab

MyZubster

https://github.com/MyZubster-Ecosystem/myzubster

I-ECO-01

https://github.com/DanielIoni-creator/I-ECO-01

MyZubsterWeb

https://github.com/DanielIoni-creator/MyZubsterWeb

MyZubster-Social

https://github.com/DanielIoni-creator/MyZubster-Social


πŸ§ͺ Current Status

The current development environment includes:

  • βœ… Escrow application layer
  • βœ… 2-of-3 escrow workflow testing
  • βœ… GitHub bounty API
  • βœ… MYZ reward accounting
  • βœ… Experimental MYZ β†’ XMR conversion logic
  • βœ… Monitoring dashboard
  • βœ… Robot / AI integrations
  • βœ… MyZubster integration work
  • πŸ§ͺ Monero Stagenet testing
  • 🚧 Production security hardening
  • 🚧 Mainnet preparation

We have also performed more than 25 simulated escrow tests covering creation, authorization, release, cancellation and error handling.


πŸ” What Still Needs to Be Done

Before considering real-money production use, we need to address:

  • secure key management;
  • wallet isolation;
  • API authentication;
  • authorization;
  • HTTPS;
  • rate limiting;
  • audit logging;
  • multisig recovery;
  • transaction verification;
  • dispute resolution;
  • monitoring;
  • backups;
  • security review.

Moving from Stagenet to mainnet is not simply changing an endpoint.

It requires confidence in the complete wallet, transaction, security and operational architecture.


πŸ”œ Roadmap

Our next steps include:

1. Stagenet

Continue testing actual wallet and multisig workflows without exposing real funds.

2. MyZubster Frontend

Make escrow functionality accessible directly from the web interface.

3. Smart Scooter Integration

Connect the software platform with GPS and vehicle-management systems.

4. Mobile Application

Explore a mobile interface for rentals and payments.

5. Reputation System

Build reputation mechanisms for customers, contributors and service providers.

6. Security Review

Review the architecture before considering mainnet.

7. Production

Only after sufficient testing and security validation will we evaluate production deployment.


πŸ™ How to Contribute

The project is open source and we welcome technical feedback.

You can contribute by:

  • πŸ› Reporting bugs
  • πŸ’» Opening pull requests
  • πŸ§ͺ Testing on Stagenet
  • πŸ“– Improving documentation
  • πŸ” Reviewing the architecture
  • πŸ’‘ Suggesting new integrations

The GitHub repositories are the best place to start.


🏁 Conclusion

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

Top comments (0)