🔐 Smart Scooter Rentals with Monero: Building a 2-of-3 Multisig Escrow
Hi everyone! 👋
I'm Daniel Ioni, an independent developer and the founder of Urban Lab, an experimental sustainable mobility project combining smart electric scooters, AI-powered services and privacy-focused payments using Monero (XMR).
In this article, I want to share what we are building around a 2-of-3 multisig escrow workflow for Monero, and how we are integrating it with the MyZubster ecosystem.
⚠️ Important: This project is still under development. Testing is being performed on Monero Stagenet and with simulated application data. Real-money production use requires additional security, wallet and operational testing.
🛴 The Urban Lab Concept
Imagine renting a smart electric scooter with:
- GPS tracking
- remote locking
- AI-powered services
- privacy-focused payments
- automated transaction management
The technology is interesting, but it immediately raises a practical question:
How do the customer and the service provider trust each other?
The customer doesn't want to pay and discover that the scooter or service is unavailable.
The provider doesn't want to deliver the service without knowing whether the payment is committed.
This is where an escrow workflow can help.
🔐 Why Multisig Escrow?
Our experimental architecture uses a 2-of-3 multisig model.
The three participants can be:
- Buyer — the customer
- Seller — the service provider
- Admin / Arbitrator — an optional third party for dispute resolution
Two of the three authorized participants are required for operations governed by the multisig scheme.
This provides a useful separation of responsibilities.
For example:
┌─────────────┐
│ BUYER │
└──────┬──────┘
│
│ authorization
▼
┌─────────────┐
│ ESCROW │
│ 2-of-3 │
└──────┬──────┘
│
┌─────────┼─────────┐
│ │ │
▼ ▼ ▼
BUYER SELLER ADMIN
│
▼
MONERO WALLET
The important principle is that a single participant should not be able to unilaterally perform an operation requiring the configured threshold.
⚙️ The I-ECO-01 Backend
The current backend component is I-ECO-01, a Node.js REST API responsible for managing the application-level escrow workflow.
It currently handles operations such as:
- creating escrow records;
- generating unique escrow IDs;
- recording authorizations;
- tracking escrow status;
- release workflows;
- cancellation;
- expiration;
- monitoring;
- listing escrow transactions.
Technology stack
- Node.js
- Express
- MongoDB
- Monero Wallet RPC
- WebSocket
- HTML + JavaScript dashboard
During development, Monero Stagenet is used for testing.
🔄 Escrow Transaction Flow
A simplified transaction can look like this:
1. Create the escrow
The customer and provider agree on a service and amount.
For example:
{
"service": "Smart Scooter Rental",
"amount": 25,
"currency": "XMR"
}
The backend creates an escrow ID and records the transaction.
2. Fund the escrow
In a real transaction, the appropriate Monero wallet and multisig workflow would be responsible for handling the funds.
During development, we distinguish between:
- simulated application balances;
- actual Stagenet transactions.
This distinction is important.
A database entry containing 25 XMR does not automatically mean that 25 XMR has moved on the Monero blockchain.
3. Authorization
The participants provide their authorization according to the escrow rules.
Buyer → authorization
Seller → authorization
Admin → optional authorization
4. Reach the threshold
When the required threshold is reached, the application can move the escrow into a state such as:
SIGNED
5. Release
The release process is then performed according to the actual wallet and multisig implementation.
For simulated tests, this may simply update the application state.
For Stagenet testing, the corresponding transaction can be independently verified on the Monero test network.
🧪 Testing on Stagenet
We have performed more than 25 automated and simulated tests covering the main escrow workflows.
The tests include:
- escrow creation;
- unique transaction IDs;
- authorization handling;
- duplicate signatures;
- expired escrow records;
- release workflows;
- cancellation;
- status queries;
- error handling;
- dashboard monitoring;
- robot/service integrations.
The purpose of these tests is to validate the application architecture before considering any production deployment.
We deliberately want to avoid using real funds while the system is still evolving.
🤖 AI and Robot Integration
One of the most interesting aspects of Urban Lab is that the escrow infrastructure is not limited to human-to-human transactions.
We are also experimenting with software agents and physical devices.
Current integrations include:
Pytho AI
An AI component used for planning and interaction with the escrow API.
Smart Scooter
A smart electric scooter concept combining mobility services, GPS and remote-control functionality.
MyZubster Robot
A bot-oriented component for community activities, bounties and reward workflows.
MIGHTY Planner
A planning assistant that can potentially participate in service and consulting workflows.
The broader idea is:
Customer
│
▼
AI / Robot Service
│
▼
Escrow API
│
▼
Multisig Authorization
│
├── Buyer
├── Service Provider
└── Admin / Arbitrator
│
▼
Monero
This is still experimental, but it raises an interesting question:
What happens when AI agents and physical machines can participate in structured financial workflows?
🌐 MyZubster Integration
Urban Lab is also being connected to MyZubster, our broader platform concept for community activity, bounties, rewards and marketplace functionality.
The integration is designed around several components.
Bounties
Users can create tasks or bounties for:
- bug reports;
- development;
- documentation;
- new features;
- community contributions.
Social Notifications
The system can be extended to send notifications when important events occur, such as:
- a new bounty;
- a new escrow;
- an escrow status change;
- a completed transaction.
Potential integrations include Telegram, Discord and other configurable channels.
Monitoring Dashboard
A lightweight web dashboard provides visibility into the escrow system.
It can display:
- total escrow operations;
- pending operations;
- completed operations;
- transaction amounts;
- escrow IDs;
- current status.
🌐 MyZubsterWeb
The planned web frontend is intended to provide a simple interface for users.
Potential functionality includes:
- browsing scooter rental listings;
- viewing repair and service offers;
- creating an escrow;
- checking payment status;
- receiving transaction notifications.
The architecture can be represented as:
MyZubsterWeb
│
▼
MyZubster API
│
▼
I-ECO-01
│
▼
Escrow System
│
▼
Monero Wallet
📦 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 Project Status
| Component | Status |
|---|---|
| Urban Lab backend | 🟢 Development active |
| Escrow API | 🟢 Operational in test environment |
| MongoDB | 🟢 Integrated |
| Monero Stagenet | 🟢 Testing |
| Dashboard | 🟢 Development version |
| Robot integrations | 🟢 Testing |
| MyZubster integration | 🟡 In development |
| Mainnet | ⚪ Not yet launched |
The most important point is that mainnet should only be considered after sufficient security and operational validation.
🔐 Security Before Mainnet
Moving from a test environment to real funds is a major step.
Before production deployment, we need to address areas such as:
- secure private-key management;
- wallet isolation;
- API authentication;
- authorization;
- rate limiting;
- HTTPS;
- audit logging;
- multisig recovery;
- dispute resolution;
- transaction verification;
- monitoring and alerting;
- backup procedures;
- independent security review.
The application database must also never be treated as the source of truth for blockchain settlement.
For example:
Database:
status = RELEASED
does not by itself prove that the corresponding Monero transaction has successfully settled.
The blockchain transaction must be independently verified.
🔜 What's Next?
Our roadmap includes:
1. More Stagenet Testing
Continue testing the complete wallet and multisig workflow without exposing real funds.
2. Better Authentication
Add stronger authentication and authorization to the API and dashboard.
3. MyZubster Frontend Integration
Make escrow functionality accessible directly through the web interface.
4. GPS Integration
Connect the scooter service layer with real-time vehicle monitoring.
5. Mobile Application
Explore a mobile interface for scooter rentals, payments and service management.
6. Reputation System
Develop reputation mechanisms for customers and service providers.
7. Production Readiness
Only after testing and security review will we evaluate whether a mainnet deployment is appropriate.
🙏 How to Contribute
If you're interested in the project, there are several ways to contribute:
- 🐛 Report bugs
- 💻 Submit pull requests
- 📖 Improve documentation
- 🔍 Review the architecture
- 🧪 Help test on Stagenet
- 💡 Propose new integrations
The GitHub repositories are the best place to start.
🏁 Conclusion
Urban Lab started with a simple idea:
Can smart mobility services use privacy-focused digital payments without requiring the customer and provider to completely trust each other?
Our current answer is an experimental 2-of-3 multisig escrow architecture built around Monero.
We're combining:
🛴 Smart mobility
🤖 AI and autonomous services
🔐 Multisig escrow
💰 Monero
🌐 Open-source software
The project is still evolving.
We are testing on Stagenet, improving the architecture and learning what is required to make the system secure enough for real-world use.
That's the interesting part of building in public.
Urban Lab — Mobility, AI, Privacy & Open Source. 🚀🌿🔐
Daniel Ioni — Urban Lab
Top comments (0)