🔐 Building a Monero Multisig Escrow for Urban Lab — Testing on Stagenet
Urban Lab is an experimental sustainable mobility project focused on smart electric scooters, AI-powered services and privacy-focused payments.
One of the components we are currently developing is a 2-of-3 multisig escrow workflow using Monero, designed to coordinate payments between customers, service providers and an optional administrator/arbitrator.
⚠️ Important: Everything described in this article is currently testing infrastructure. The examples use Monero Stagenet and/or simulated application data. No real funds are being used for these tests.
The goal is not to claim that the system is production-ready.
The goal is to build it, break it, test it and understand what is required before handling real XMR.
🧠 The Problem
Peer-to-peer transactions introduce a basic trust problem.
The customer wants confidence that the service will actually be delivered.
The service provider wants confidence that the customer has committed the agreed payment.
An escrow workflow can create a separation between:
- agreeing to a transaction;
- committing funds;
- delivering the service;
- authorizing the release.
Our experimental model uses a 2-of-3 authorization scheme involving the buyer, service provider and an administrator/arbitrator.
The important point is that a single participant should not be able to unilaterally perform an operation that requires the multisig threshold.
⚙️ Technical Architecture
The current Urban Lab prototype consists of several components:
- Backend: Node.js + Express
- Database: MongoDB
- Payment network: Monero Stagenet
- Wallet infrastructure: Monero wallet RPC
- Multisig model: 2-of-3
-
REST API:
create,sign,release,cancel,status,list - Dashboard: HTML + JavaScript
- AI / robotic integrations: Pytho AI, Smart Scooter, MyZubster Robot and MIGHTY Planner
At the application level, the architecture looks roughly like this:
CUSTOMER
│
▼
┌─────────────┐
│ ESCROW API │
└──────┬──────┘
│
┌────────────┼────────────┐
│ │ │
▼ ▼ ▼
BUYER SERVICE ADMIN
PROVIDER / ARBITRATOR
│ │ │
└────────────┼────────────┘
│
2-of-3
MULTISIG
│
▼
MONERO STAGENET
This separation also allows us to test the application logic independently from the actual blockchain transaction lifecycle.
🔄 Test Transaction Flow
A typical development test looks like this.
1. Create the escrow
The customer and service provider agree on the service and amount.
For example:
{
"service": "Smart Scooter Rental",
"amount": 25,
"currency": "XMR"
}
The backend generates a unique escrow identifier and stores the transaction state.
2. Fund the escrow
In a real deployment, this step would involve the appropriate Monero wallet and multisig workflow.
During our testing, we distinguish between:
- application-level simulated funds, and
- actual Stagenet XMR transactions.
This distinction is important because an API record showing 25 XMR does not automatically mean that 25 XMR actually moved on the Monero network.
3. Authorization
The relevant participants provide their authorization.
For example:
Buyer → authorization
Service → authorization
Admin → optional authorization
The application tracks the authorization state and determines whether the configured threshold has been reached.
4. Reach the 2-of-3 threshold
Once two authorized participants have approved the operation, the escrow can enter a state such as:
SIGNED
5. Release
The release process is then initiated according to the rules implemented by the escrow and wallet infrastructure.
In simulated tests, the release may only update the application state.
In actual Stagenet testing, the corresponding Monero transaction can be verified independently on the Stagenet network.
🧪 What We Tested
We have run more than 25 simulated escrow operations to test the application workflow.
The tests covered:
- unique escrow creation;
- escrow state transitions;
- robot/service authorization;
- customer authorization;
- duplicate signature handling;
- expired escrow handling;
- release logic;
- cancellation logic;
- API status queries;
- dashboard statistics;
- multiple robot integrations.
The objective was to verify that the application behaves predictably under both normal and invalid inputs.
🤖 Robots and AI Services
One of the more interesting parts of the project is the integration with autonomous software components.
Currently, our test environment includes:
| Component | Role |
|---|---|
| Pytho AI | AI-based planning and transaction integration |
| Smart Scooter | Physical mobility service |
| MyZubster Robot | Community, bounty and reward workflows |
| MIGHTY Planner | Project and resource planning |
The idea is to treat these systems as service providers or service agents that can participate in an escrow workflow.
For example:
Customer
│
▼
Request a service
│
▼
AI / Robot
│
▼
Create Escrow
│
▼
Authorization
│
▼
2-of-3 Threshold
│
▼
Release Workflow
This is still experimental.
We are interested in exploring what happens when AI agents, physical devices and privacy-focused payment infrastructure become part of the same transaction workflow.
📊 Local Escrow Dashboard
We also built a lightweight dashboard for monitoring the test environment.
The dashboard displays:
- total escrow operations;
- pending transactions;
- completed/released operations;
- simulated XMR volume;
- escrow IDs;
- transaction amounts;
- current state.
Example:
The dashboard currently runs locally during development.
For example:
http://localhost:8082
A production deployment would require proper authentication, HTTPS, access controls and protection of sensitive operational data.
🛠️ Development Tools
The repository also contains several development utilities for testing the system.
Examples include:
monitor_robots.sh
complete_escrow.sh
robot_escrow_config.json
pytho_escrow.py
escrow_dashboard.html
These tools allow us to automate repetitive testing and monitor the behavior of the integrated services.
One important lesson from the project is that automation must be treated as a security boundary.
A script capable of automatically completing an escrow should never be exposed as an unrestricted production endpoint.
🔐 Security Considerations
The current prototype is not being presented as a finished financial product.
Before using real funds, we need to address areas such as:
- secure key management;
- wallet isolation;
- authentication;
- authorization;
- API rate limiting;
- audit logging;
- secure deployment;
- multisig recovery procedures;
- dispute resolution;
- transaction verification;
- monitoring and alerting;
- independent security review.
We also need to clearly separate the application escrow state from the actual Monero blockchain state.
That distinction is critical.
A database saying:
status = RELEASED
does not by itself prove that a Monero transaction has successfully settled.
🧪 Why Start With Stagenet?
We deliberately want to avoid experimenting with real money while the architecture is still changing.
Monero Stagenet provides an environment where developers can test wallet and transaction workflows without putting production funds at risk.
Our development sequence is therefore:
Application Simulation
│
▼
Stagenet Testing
│
▼
Security Review
│
▼
Operational Testing
│
▼
Production Architecture
│
▼
Mainnet
The final step should only happen after the previous stages have been validated.
🔗 Open Source Repository
The Urban Lab source code is available on GitHub:
https://github.com/DanielIoni-creator/urban-lab
We are interested in feedback from developers working with:
- Monero;
- multisig wallets;
- AI agents;
- robotics;
- autonomous services;
- peer-to-peer marketplaces;
- privacy-focused applications.
Issues, code review and technical feedback are welcome.
🔜 What's Next?
The next development steps include:
1. Complete Stagenet testing
Move from simulated application flows to verified Stagenet wallet transactions where appropriate.
2. Improve authentication
Protect the API and dashboard with proper authentication and authorization.
3. Integrate MyZubster
Bring the escrow workflow into the MyZubster frontend so users can interact with the system directly.
4. Improve observability
Add better transaction monitoring, audit logs and error reporting.
5. Security review
Review the architecture and wallet/key-management model before considering any production deployment.
6. Mainnet — eventually
The goal is eventually to support real transactions, but only after the system has been properly tested and secured.
🧠 What We Are Really Building
At first glance, this looks like another cryptocurrency payment project.
But that's not the part we find most interesting.
The bigger experiment is the interaction between:
AI agents + physical machines + users + privacy-focused payments + multisig authorization.
Imagine a future where a customer can request a physical service from an autonomous system, agree on the conditions, lock funds into an escrow and release payment according to verifiable rules.
That's the direction we are exploring with Urban Lab.
We are still early.
There are plenty of technical problems left to solve.
And that's exactly why we're building it in public.
🏭 Urban Lab
Urban Lab — Mobility, AI, Privacy & Open Source.
We're experimenting with the infrastructure that could connect autonomous services with real-world mobility.
No hype.
No real-money production system yet.
Just code, testing, Stagenet and a lot of experiments. 🔐🤖🚀
If you're interested in the project, check out the repository and open an issue or start a discussion.
GitHub:
https://github.com/DanielIoni-creator/urban-lab
Top comments (0)