# Openmesh Overview

Openmesh is building a fully decentralized cloud, data, and oracle network that eliminates the need for middlemen and centralized servers. By providing decentralized, permissionless cloud infrastructure, Openmesh ensures that blockchain nodes, Web3, and even Web2 applications can operate seamlessly without the threat of regulatory overreach or centralized control. With Openmesh, trust is embedded in the system itself, validated by a decentralized network of independent, anonymous validators, ensuring immutability and security by design.

## **Not your cloud, not your data**

<figure><img src="/files/1nDjBrCjKktvzxAdAGYX" alt=""><figcaption></figcaption></figure>

### Current Web3 Infrastructure Challenge

Despite Web3's decentralization ethos, approximately 80% of Web3 services (dApps, frontends, databases, validator nodes) rely on centralized cloud platforms. This centralization introduces vulnerabilities and contradicts Web3 principles.

{% hint style="info" %}
Ready to be a part of the Openmesh decentralized cloud ecosystem?

View our **getting started** & **template deployment** guides:

* [Basic Getting Started Guides](https://docs.openmesh.network/products/xnode/basic-getting-started-guides)
  * [Redeem you Xnode DVM Guide](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm)
* [App Template Deployment Guides](https://docs.openmesh.network/products/xnode/template-deployment-guides)
* [Use-Cases Deployment Guides](https://docs.openmesh.network/products/xnode/use-case-deployment-guides)
* [Advanced Template Deployment Guides](https://docs.openmesh.network/products/xnode/advanced-deployment-guides)
  {% endhint %}

### Openmesh Architecture

Openmesh leverages Xnode technology to create a truly decentralized cloud infrastructure:

1. **Distributed Xnodes**: Replace centralized data centers with a network of distributed nodes.
2. **XnodeOS**: Custom operating system based on NixOS, ensuring reproducible and verifiable system states.
3. **Wallet-Based Authentication**: Ethereum wallet integration for enhanced security and user sovereignty.
4. **Open-Source Codebase**: Enables community auditing and continuous improvement.
5. **Xnode Studio**: Web-based interface for deployment and management of decentralized applications.

### Technical Features

* **Permissionless Access**: No KYC required, accessible via crypto wallet
* **Cost Efficiency**: Up to 80% reduction in costs compared to traditional cloud services
* **Native Blockchain Integration**: Built-in interoperability with Web3 technologies
* **One-Click Deployment**: Simplified deployment of complex applications
* **Infrastructure Ownership**: Users can own pieces of the infrastructure through the Xnode One NFT program

<figure><img src="/files/1y8Tg7B9opY2UssE43KX" alt=""><figcaption></figcaption></figure>

### Chainlink Integration

Openmesh integrates Chainlink's Cross-Chain Interoperability Protocol (CCIP) and Data Feeds, enabling:

* Cross-chain communication
* Trustless token transfers
* Access to off-chain data
* Up to 90% true decentralization in applications

This integration facilitates the development of cross-chain DeFi protocols, decentralized data marketplaces, and blockchain-based IoT solutions.

### Comparison with Traditional Cloud Providers

| Feature                | Traditional Clouds             | Openmesh                   |
| ---------------------- | ------------------------------ | -------------------------- |
| Architecture           | Centralized                    | Decentralized              |
| Authentication         | Email, password, API keys      | Ethereum wallet-based      |
| Infrastructure Control | Provider-owned                 | User-owned (via NFTs)      |
| Deployment             | Complex, requires expertise    | One-click via Xnode Studio |
| Customization          | Limited to provider offerings  | Flexible, Nix-based        |
| Web3 Integration       | Retrofitted                    | Native                     |
| Open-source            | Closed-source                  | Fully open-source          |
| Cost                   | Higher, especially at scale    | Up to 80% cheaper          |
| Payment                | Fiat currencies                | Cryptocurrency             |
| Regulatory Risk        | Subject to jurisdictional laws | Censorship-resistant       |

### Read the Openmesh Litepaper to Learn More!

| Litepaper Section                                                                          | Content                         |
| ------------------------------------------------------------------------------------------ | ------------------------------- |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Decentralisation Compromised    |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | The Openmesh Solution           |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Principles and Governance       |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Openmesh's 10 Commandments      |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Core Innovation & Breakthroughs |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Openmesh Journey                |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Go to Market Milestones         |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Importance of Defining Web3     |
| [Roadmap](https://www.openmesh.network/litepaper#roadmap)                                  | Openmesh Roadmap                |
| [Governance & Transparency](https://www.openmesh.network/litepaper#governancetransparency) | Robust Governance Framework     |
| [Tokenomics](https://www.openmesh.network/litepaper#tokenomics)                            | Token Distribution              |
| [Openmesh DAO](https://www.openmesh.network/litepaper#dao)                                 | Voting Mechnanism               |


# Litepaper


# Openmesh Expansion Program

The Openmesh Expansion Program (OEP) is a community-funded initiative approved by OpenmeshDAO to support the development of the Openmesh roadmap and expand its infrastructure from Q3 2024 through Q4 2025. Whitelist now—closing October 15th—to participate in Openmesh's ongoing efforts to reshape decentralized infrastructure and secure the future of Web3. By participating in the OEP, you play a crucial role in advancing decentralized cloud infrastructure and securing the future of Web3.

{% hint style="info" %}
Read the full details at our [Official OEP Website!](https://oep.openmesh.network/)
{% endhint %}


# How to whitelist

{% hint style="warning" %}
Before you can participate, you require a self-custody wallet with some ETH (on the Ethereum network) to pay for gas fees. To acquire ETH, you can buy and withdraw it from any Centralised Crypto Exchange (CEX) We recommend having at least $5 worth of ETH in your wallet, $1 for the whitelisting, and up to $4 for the asset transfer.

You are free to choose any wallet and CEX that you prefer. The most popular ones are [MetaMask](https://metamask.io/) (wallet) and [Binance](https://www.binance.com/) (CEX).
{% endhint %}

**Step 1 - Visit** [**https://oep.openmesh.network/**](https://oep.openmesh.network/)

<figure><img src="/files/7d5kUmaOjNrNT8Au4dCu" alt=""><figcaption><p>This website contains all information about the Openmesh Expansion Program, ranging from initiative goals to participation considerations.</p></figcaption></figure>

**Step 2 - Head to the whitelist section**

<figure><img src="/files/devMWZeoiBrdfwbjRJAl" alt=""><figcaption><p>Either press the button at the top of the page or scroll all the way to the bottom.</p></figcaption></figure>

**Step 3 - Click the whitelist button of the desired ticket size**

You can only whitelist one ticket. Higher ticket size contributions have a higher bonus rate, earning you more Cloud Credits. Cloud Credits can be exchanged for a variety of Openmesh products, including XnodeOne and sOPEN. XnodeOne is an NFT that grants ownership to a server for 12 months, which you can use however you like, with the monthly fee paid by Openmesh. sOPEN is our early access ERC20 token on Ethereum, which can be redeemed 1 to 1 for OPEN after its Token Generation Event (TGE). OPEN is a governance token that grants voting rights in the Openmesh DAO. OPEN token holders will vote on the future of Openmesh, completely powered by smart contracts, allowing for transparent, trustless, and secure governance.&#x20;

**Step 4 - Connect your wallet**

<figure><img src="/files/ZzjXSZKkQZJObmsqRDii" alt=""><figcaption><p>In case you already connected your wallet, you can skip this step.</p></figcaption></figure>

Pick your wallet from the list. If you are visiting the website from a different device, e.g. on your laptop, while the wallet is on your phone, most wallets allow you to connect using a QR code. For this select WalletConnect.

**Step 5 - Enter your contact details**

<figure><img src="/files/LFMB7txq14tQqMzEtPAc" alt=""><figcaption><p>This information will only be visible to a limited amount of Openmesh members.</p></figcaption></figure>

**Step 6 - Review and accept the terms**

<figure><img src="/files/sK8U0FA1e76PDy350sos" alt=""><figcaption></figcaption></figure>

**Step 7 - Sign your contact details with your wallet**

After pressing send, you should get a signature request in your wallet.

<figure><img src="/files/W840iAdeXSQRjso1yttR" alt=""><figcaption><p>Example of a signature request in the MetaMask browser extension</p></figcaption></figure>

**Step 8 - Sign the reserve transaction**

After accepting the signature request, a transaction request should pop up in your wallet.

<figure><img src="/files/SONCrsEP11kQOLscOcY1" alt=""><figcaption><p>Example of a reserve transaction request in the MetaMask browser extension</p></figcaption></figure>

In case you are facing any issues, you can try to disconnect and reconnect your wallet in the top right corner. Please ensure you have enough Ethereum in your wallet to pay for gas.&#x20;

The smart contract you will be transacting with can be reviewed [here](https://etherscan.io/address/0xc939d1e0c5a6faae5edbcfe84239ddad546ff495).

**Step 9 - Finished!**

Thank you for participating. Your ticket should now show up underneath the whitelist table, but this can take a few minutes. Please contact <samuel.mens@openmesh.network> in case you run into any issues.


# How to perform asset transfer

{% hint style="warning" %}
You can only perform the asset transfer after [whitelisting](/openmesh/openmesh-expansion-program/how-to-whitelist) and receiving an email confirming your whitelist.
{% endhint %}

**Step 1 - Open the link in the email and connect your wallet**

<figure><img src="/files/u5w8PTYciSZbxzG8eX34" alt=""><figcaption><p>Please verify that this link starts with https://oep.openmesh.network</p></figcaption></figure>

**Step 2 - Confirm your whitelist summary is correct**

<figure><img src="/files/wsvfo8yZOHDb1xNsDpNg" alt=""><figcaption></figcaption></figure>

**Step 3 - Choose which to transfer**

<figure><img src="/files/oKSTyg6ZwGioD1oXJhSL" alt=""><figcaption><p>The current ETH/USD exchange rate is provided underneeth this dropdown. Stablecoins have a fixed exchange rate of 1:1.</p></figcaption></figure>

**Step 4 - Perform a test transfer ($10)**

<figure><img src="/files/5nm3qIHswBlonJWnr29R" alt=""><figcaption><p>You will be asked to sign a transaction in your wallet.</p></figcaption></figure>

**Step 5 - Verify the transfer**

<figure><img src="/files/J0zzt4aGnMy20tQhbG88" alt=""><figcaption><p>It can take a few seconds for it to appear.</p></figcaption></figure>

A transfer should have appeared at the bottom of the page. Please click view on explorer and verify that the funds were moved to "0x24496D746Fd003397790E41d0d1Ce61F4F7fd61f" or "openmesh-network.eth". You can also verify this address in your wallet before making the transfer instead.

**Step 6 - Perform the asset transfer**

Click the transfer button with your ticket size ($500,000 in the screenshots). You will be asked to sign a transaction in your wallet.

**Step 7 - Finished!**

<figure><img src="/files/KUCATenF4XcRFDIVOKk9" alt=""><figcaption><p>Your transfer has been added at the bottom of the page and the asset transfer interface has disappeared.</p></figcaption></figure>


# Project FAQs

## **About Openmesh**

**Q: What is Openmesh?**&#x20;

A: Openmesh is an initiative to build an all-in-one petabyte scale decentralized open data infrastructure for web3 allowing anyone access to immutable data without any censorship.

**Q: What can Openmesh do for the community?**&#x20;

A: Openmesh will enable anyone to stream live web3 transactional data, access historical web3 data, query and perform analytics, build interoperable data products, and do business intelligence, at scale, at almost zero cost forever without having any intervention, interference, or influence over regulations, governments, corporations including the creators themselves.

**Q: What is Openmesh's vision?**&#x20;

A: Openmesh will serve as the “Wayback Machine” and “Open Finance Archive of Web 3.0”. We envision a thriving ecosystem of researchers, data scientists, entrepreneurs, quants, traders, financial engineers, protocol architects, startups, lawyers, and regulators using Openmesh Open Data Infrastructure for live and unedited, tamper-proof historical information to build various applications from research & data analytics, trading, risk management, financial engineering, financial forensics, etc.

**Q: What is Openmesh's mission?**&#x20;

A: Openmesh's mission is to address the information asymmetry in Web 3.0 by democratizing data and providing everyone with access to quality, immutable data for free, forever.

**Q: How did Openmesh start?**&#x20;

A: Openmesh has been in the blockchain and crypto space since 2015 and faced issues with data quality and cost from centralized data providers. The team decided to build its own data lake, which took more than a year to build, but now covers 70% of the entire crypto and Web 3.0 transactional data market.

**Q: What types of data does Openmesh store and cover? What are the sources of these data?**&#x20;

A: Openmesh stores all transactional data in Web 3.0 including decentralized finance data, decentralized crypto exchange data, centralized crypto exchange data, blockchain game data, metaverse data, oracle data, and public blockchain data.

<table><thead><tr><th width="305.5">Source</th><th>Type of data</th></tr></thead><tbody><tr><td>Decentralized Finance</td><td>All financial transactions including wallets, assets, liquidity, value locked, asset transfers, asset custody</td></tr><tr><td>Decentralized Crypto Exchanges</td><td>All financial transaction, liquidity, assets, asset transfers, wallets</td></tr><tr><td>Centralized Crypto Exchanges</td><td>Order books, trade data, transactional data, candle stick, ticker, inflow and outflow data</td></tr><tr><td>Blockchain Games</td><td>Games, user assets, user activities, game asset classifications, game assets transfers, in-game transactions</td></tr><tr><td>Metaverses</td><td>Metaverse assets, transactions, user activities</td></tr><tr><td>Oracles</td><td>All oracle transactions</td></tr><tr><td>Public Blockchains</td><td>Block size, block events, asset transfers, wallet addresses, blockchain confirmations, smart contract events</td></tr></tbody></table>

More information about Web 3.0 data can be found [here](https://gdafund.medium.com/evaluation-of-confusing-web-3-0-metrics-b99f87c4ea5e) on our medium page.

**Q: What is Openmesh's approach to transparency?**&#x20;

A: Openmesh is transparent in all aspects, including open-source technology, open accounting, open R\&D, open infrastructure monitoring, and open verification through end-to-end data encryption.

**Q: What is Openmesh's approach to excellence and passionate maximalism?**&#x20;

A: Openmesh's team works 7 days a week with extreme passion and discipline toward innovation in the Web 3.0 and open-source ecosystem.

**Q: What is Openmesh's philosophy?**&#x20;

A: Openmesh's philosophy is based on decentralization, with a belief in openness, equality, and freedom.

**Q: How do we aim to make Openmesh work?**&#x20;

A: Openmesh aims to use a self-serve design and data mesh architecture that supports distributed, domain-specific data consumers and views data as a product.

**Q: How does Openmesh handle data?**&#x20;

A: Openmesh has no single authority that can alter its data, how the information is distributed, or who can access it. The infrastructure is open-source and governed by an open-source community, and each domain handles its own data pipelines.

**Q: How is the data aimed to be stored and managed?**&#x20;

A: The data is stored in a decentralized data lakehouse secured by cryptography\
\ <br>


# Important Links

### General Info

| Item                                                                | Content                         |
| ------------------------------------------------------------------- | ------------------------------- |
| [Openmesh Website](https://www.openmesh.network/)                   | Official Website                |
| [Openmesh Litepaper](https://www.openmesh.network/litepaper#basics) | Decentralisation Compromised    |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | The Openmesh Solution           |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | Principles and Governance       |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | Openmesh's 10 Commandments      |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | Core Innovation & Breakthroughs |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | Openmesh Journey                |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)  | Importance of Defining Web3     |

### Developers

| Item                                                                                                 | Description                                   |
| ---------------------------------------------------------------------------------------------------- | --------------------------------------------- |
| [Openmesh Github](https://github.com/Openmesh-Network)                                               | Our open-source software!                     |
| [Xnode Studio](https://www.openmesh.network/xnode)                                                   | Xnode deployment website                      |
| [OpenCircle Developer Group](https://circle.openmesh.network/groups/developers/members/all-members/) | Developer training and Web3 community website |
| [Openmesh Developers Telegram Channel](https://t.me/OpenmeshDevs)                                    | TG Developer Announcements                    |
| [Openmesh Developers X Community ](https://x.com/i/communities/1844577110045950312)                  | Our X community for developers                |
| [Openmesh Discord #dev-chat](https://discord.gg/AgJENtgqQy)                                          | Our developer discord channel                 |

### Community & Social Media

| Item                                                                        | Description               |
| --------------------------------------------------------------------------- | ------------------------- |
| [Openmesh X](https://x.com/OpenmeshNetwork)                                 | Official X account        |
| [Openmesh Telegram](https://t.me/openmesh)                                  | Official Telegram channel |
| [Openmesh Discord](https://opnm.sh/discord)                                 | Official Discord server   |
| [LinkedIn](https://www.linkedin.com/company/openmesh)                       | Official LinkedIn profile |
| [Medium Blog](https://blog.openmesh.network/)                               | Official Medium blog      |
| [YouTube Channel](https://www.youtube.com/channel/UC-GI8ObQgUieNlvyWQmpRuw) | Official YouTube channel  |

### Investors & Stakeholders

| Item                                                                                       | Description                 |
| ------------------------------------------------------------------------------------------ | --------------------------- |
| [Roadmap](https://www.openmesh.network/litepaper#roadmap)                                  | Openmesh Roadmap            |
| [Openmesh Overview](https://www.openmesh.network/litepaper#basics)                         | Go to Market Milestones     |
| [Tokenomics](https://www.openmesh.network/litepaper#tokenomics)                            | Token Distribution          |
| [Governance & Transparency](https://www.openmesh.network/litepaper#governancetransparency) | Robust Governance Framework |
| [Openmesh DAO](https://www.openmesh.network/litepaper#dao)                                 | Voting Mechanism            |


# Xnode

### What is Xnode?

Xnode is an all-in-one infrastructure deployment and configuration system within Openmesh's P2P immutable data network. At its core, Xnode runs on XnodeOS, a custom operating system based on NixOS. This foundation provides critical technical capabilities:

* Reproducible builds for consistent deployments
* Declarative system configuration
* Atomic upgrades and rollbacks
* No-reboot software stack changes
* Pure functional package management

Each Xnode operates as a microservice in the network, collectively forming a network of data collectors, aggregators, and validators which facilitate a global system of data verification and dissemination.

<figure><img src="/files/fWItxHr7HhKdQjY3r79p" alt=""><figcaption></figcaption></figure>

### Technical Infrastructure

Xnode currently operates through bare metal deployment, providing organizations with complete control over their infrastructure. The system's foundation is built on XnodeOS, a nix-based operating system, enabling rapid changes to software stacks while maintaining system stability and reliability. Through reproducible builds and atomic updates, XnodeOS ensures consistent deployments across bare metal environments without requiring system reboots.

### Deployment and Templates

Xnode Studio serves as the central hub for infrastructure deployment and management. Users can deploy their infrastructure stack to bare metal servers through an intuitive interface. The system comes with an extensive library of pre-built application templates, significantly reducing setup time and complexity.

<figure><img src="/files/gJzpBih2g8GCpmNsBHzF" alt=""><figcaption></figcaption></figure>

Available templates span various categories:

* Blockchain nodes and validators
* Data processing applications
* Development environments
* Analytics tools
* Web service stacks

Each template is preconfigured for optimal performance on XnodeOS, while still allowing customization to meet specific requirements.

## Core Components

### Xnode DVM - NFT Access Pass

Xnode DVM (Decentralized Virtual Machine) provides infrastructure deployment through virtualized resources. The system offers equivalent computing power to $3,500 USD of traditional cloud resources, accessible for 12 months through NFT-based authentication.

<figure><img src="/files/nDRn6VuEw4UzT2WHvTzS" alt=""><figcaption></figcaption></figure>

Key technical specifications:

* NFT-based access control
* 12-month resource allocation
* Template-based deployment system
* Full infrastructure portability

{% hint style="info" %}
Technical details of DVM architecture, deployment options, and resource specifications are available in our → [Xnode DVM Documentation](https://docs.openmesh.network/products/xnode/xnode-dvm)&#x20;
{% endhint %}

### Xnode Studio

The web-based management interface enables:

* Infrastructure design through drag-and-drop functionality
* Bare metal provisioning
* Pre-built infrastructure templates
* Application deployment and management
* Resource consumption monitoring
* Integration with third-party services

Performance metrics show a single c3.medium.x86 server can host over 3000 applications and services, significantly reducing infrastructure costs compared to traditional cloud services. Read the [full blog post](https://medium.com/@Ashton_/xnode-6b7e7c21d340) for more info.

{% hint style="info" %}
Xnode Studio V4 is now released! (October 2024) Read our docs section about [Xnode Studio](https://docs.openmesh.network/products/xnode/xnode-studio)!
{% endhint %}

<figure><img src="/files/Y0IAZxLWjdqNIreRLSjp" alt=""><figcaption></figcaption></figure>

### Deployment Process

Xnode deployment follows a straightforward, secure workflow. After selecting a template in Xnode Studio, the system generates a JSON configuration which is processed by the Xnode Admin Service. This service handles the entire deployment process, from initial setup to software stack configuration.

The deployment workflow is designed for reliability:

1. Template selection in Xnode Studio
2. Configuration customization if required
3. Automated deployment to bare metal
4. System verification and testing
5. Continuous monitoring activation

### Resource Management

Xnode implements comprehensive resource management on bare metal servers. Through the Xnode Admin Service, the system maintains optimal resource allocation for all deployed applications. This architecture ensures efficient utilization of server resources while maintaining isolation between different applications and services.

### Security and Authentication

Security is built into every aspect of Xnode deployment. All interactions with Xnode Studio and deployed services are authenticated through Ethereum wallet integration, providing a robust and permissionless access system. This Web3-native approach eliminates traditional security vulnerabilities while maintaining easy access for authorized users.

### Current Use Cases

Xnodes can be used for several key applications:

**Development Infrastructure:** Developers deploy complex Web3 applications directly to bare metal infrastructure, utilizing pre-built templates to reduce setup time from weeks to minutes. The system's NixOS foundation ensures reproducible builds and consistent environments across deployments.

**Node Operation:** Teams run blockchain nodes and validators with significantly reduced operational complexity. The template system includes optimized configurations for various blockchain networks, enabling quick deployment while maintaining security and performance.

**Data Management:** Organizations deploy data processing and analytics stacks using templates designed for high-throughput data operations. The bare metal deployment ensures optimal performance for data-intensive applications.

### Templates and Customization

The template system forms the cornerstone of Xnode deployment. Each template represents a fully configured application stack, optimized for bare metal deployment. Users can customize these templates through:

Template configuration options are extensive but straightforward, allowing users to modify key parameters without requiring deep technical knowledge of the underlying systems. The NixOS foundation ensures that all customizations maintain system stability and reproducibility.

For developers who require more control, templates can be extended through additional NixOS configurations, enabling advanced customization while maintaining the benefits of the Xnode deployment system.


# Xnode DVM

### **Decentralized Virtual Machines**

Xnode DVM (Decentralized Virtual Machine) is a sophisticated infrastructure deployment system that provides NFT-controlled access to computing resources. Each DVM delivers computing power equivalent to $3,500 USD of traditional cloud infrastructure, enabling developers and organizations to build and deploy Web3 applications efficiently.

<figure><img src="/files/nDRn6VuEw4UzT2WHvTzS" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Learn more about [buying your DVM NFT from open marketplaces like Opensea](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/buying-your-dvm-from-opensea), or [how to redeem your Xnode DVM](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm) at our [Getting Started Guides here!](https://docs.openmesh.network/products/xnode/basic-getting-started-guides)
{% endhint %}

###

### Technical Architecture

The DVM system leverages NFT-based authentication through ERC-721 tokens, providing secure and transferable ownership of infrastructure resources. Once activated, users receive 12 months of access to their allocated resources, with the ability to preserve or wipe machine states during transfers. This architecture ensures complete control over resource management while maintaining security and portability.

Resource allocation includes comprehensive infrastructure capabilities:

* Computing power and storage capacity
* Network bandwidth and routing
* Development and deployment tools
* Analytics and monitoring systems

### Deployment and Implementation

The DVM supports a wide range of deployment scenarios, from validator nodes to complete development environments. Users can deploy blockchain infrastructure, data processing systems, analytics engines, and P2P compute layers. The implementation process is streamlined through Xnode Studio, allowing rapid setup and configuration of various application stacks.

Our template system provides pre-configured application stacks while maintaining flexibility for customization. Users can modify existing templates or create custom deployments using infrastructure-as-code principles. These templates significantly reduce setup time while ensuring consistent deployment across different use cases.

### Access Control and Resource Management

Access to DVM resources is managed through a secure NFT system. When users obtain an Xnode DVM access card or code, they can visit openmesh.network/xnode to initiate their deployment. The process includes NFT entitlement verification, resource allocation, and system initialization. Once activated, users gain complete control over their infrastructure, including the ability to:

* Configure and manage resource allocation
* Transfer ownership through NFT transactions
* Customize deployment configurations
* Maintain or reset system state


# Xnode Studio

<figure><img src="/files/GILfMw6id50GKt87N3lv" alt=""><figcaption><p>Xnode Studio v4 now live as of 18th Oct 2024</p></figcaption></figure>

[Xnode Studio](https://openmesh.network/xnode) is a web-based interface to deploy and manage your Xnodes. It provides a user experience similar to android, where users can select an app to install with 1 button press and deploy a decentralized cloud node in under 10 minutes.&#x20;

### Xnode Studio means you don't need to KYC, no credit cards, just connect your Web3 Wallet

<figure><img src="/files/VPEM2Q7qSWFVY1n0TfPk" alt=""><figcaption><p>No KYC to Deploy to Openmesh - <a href="https://www.openmesh.network/xnode/login">Just connect your Web3 Wallet</a></p></figcaption></figure>

### Xnode Studio makes it Easy for Web3 builders to deploy onto Bare Metal

Xnode Studio features a powerful resource aggregation engine that scans through thousands of combinations of bare metal and cloud providers across various cities, regions, and countries to find the best resources such as compute, storage, and GPUs for your infrastructure needs, similar to how Skyscanner scans for airlines.

<figure><img src="/files/JnxXz1hrx4PWZ3BG5Ako" alt=""><figcaption><p>View our <a href="https://www.openmesh.network/xnode/resources">Resources navigator dashboard</a> to see what Bare Metal is available</p></figcaption></figure>

### Xnode Studio Offers 1-Click Deploy of App Templates

<figure><img src="/files/nBftnBZSBIBa07xcUiEa" alt=""><figcaption></figcaption></figure>

Choose from many 1-click deployment templates to get your app running as quick as possible on a Decentralised Cloud at the [Openmesh Xnode Studio App Store](https://www.openmesh.network/xnode/app-store)!

{% hint style="info" %}
Visit [Xnode Studio V4](https://www.openmesh.network/xnode/) to deploy your Xnode!
{% endhint %}

### Deploy an AI Chatbot in less than 10 minutes!

Check out our [Getting Started Guides](https://docs.openmesh.network/products/xnode/basic-getting-started-guides) and [Template Deployment Guides](https://docs.openmesh.network/products/xnode/template-deployment-guides) to get started right now!

<figure><img src="/files/yLp3bxrRgv4eedSLSAij" alt=""><figcaption></figcaption></figure>


# XnodeOS

{% hint style="info" %}
View the [XnodeOS Github Repo](https://github.com/Openmesh-Network/XnodeOS)
{% endhint %}

XnodeOS is an operating system derived from work done by the NixOS project but specialized for certain usecases such as web3 nodes and data infrastructure. The operating system is built for several deployment methods including iPXE netboot, ISO and kexec to make it compatible with as many cloud providers as possible, since each can differ in their API capabilities.&#x20;

Whilst currently in very early stages, this operating system gives openmesh a platform to build it's infrastructure technology on very few dependencies which minimises overhead and upstream dependencies. Being nix-based, deployments are also highly stable and reproducible.

## Next features to be added

Currently, the Studio API system enables direct JSON responses to be received by Xnodes for them to convert into nix code and reconfigure themselves, however this system lacks several important features such as version control, rollbacks, CI/CD tests, etc.&#x20;

Reconfiguration on Xnode will be expanded to support a git-based configuration where the Xnode Studio will directly apply git commits to a repository from the browser, using isomorphic git. This system would enable the previously mentioned features to be built and makes it easier to fully self-host the infrastructure to manage Xnode.&#x20;

Scalability: If there are a huge number of Xnodes being reconfigured through this infrastructure then PowerDNS can be employed to notify Xnodes through a TXT record when they have a new configuration to pull. This event-based solution would reduce the strain of constant querying (by a search interval) from many Xnodes to the configuration infrastructure.

Reliability / Stability: By enabling reconfiguration infrastructure to be self-hosted by anybody, there can be more than one provider for git hosting, enabling users to avoid relying on a centralized entity.


# Basic Getting Started Guides

Xnode Studio V4 is now live as of October 2024!

<figure><img src="/files/GILfMw6id50GKt87N3lv" alt=""><figcaption></figcaption></figure>

Xnode Studio V4 is a intuitive way to manage your bare metal deployments. You can connect your Web3 wallet directly manage your bare metal deployments with up to 32 service providers from around the world.

{% hint style="info" %}
The easiest way to start is to [redeem your Decentralized Virtual Machine (DVM) now!](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm)
{% endhint %}

### Basic Getting Started Guides

* [Buying your DVM from Opensea](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/buying-your-dvm-from-opensea)
* [Connecting your Web3 Wallet & Creating a Login Session](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/connecting-your-web3-wallet-and-creating-a-login-session)
* [Redeeming Your DVM](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm)
* [Select Template via App Store](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/select-template-via-app-store)
* [Deploy to DVM or Bare Metal](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/deploy-to-dvm-or-bare-metal)
* [Monitoring Your Deployments](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/monitoring-your-deployments)


# Buying your DVM from Opensea

All Decentralized Virtual Machines (DVM)'s are controlled through an "access token" that is actually an ERC-721 token on Ethereum. [Read more about what a DVM is here!](https://docs.openmesh.network/products/xnode/xnode-dvm)&#x20;

For those not lucky enough to receive a DVM from one of Openmesh's early adopter giveaways, you can buy them on the open market via Ethereum NFT marketplaces like [Opensea](https://opensea.io/).

<figure><img src="/files/s5H3tGLEZfUI6VjhLjSk" alt=""><figcaption></figcaption></figure>

###

### Navigate and Search for Xnode on Opensea

The quickest way to see which Xnode DVM's are activated or not yet activated (Entitlement) is to simply visit <https://opensea.io> and search for "xnode". From here two results should pop-up straight away:

* [**Xnode Unit Entitlement**](https://opensea.io/collection/xnode-unit-entitlement) - these are Xnode DVM ERC-721 NFT's that have not been activated yet on Xnode Studio.
* [**Xnode Unit**](https://opensea.io/collection/xnode-unit) - these Xnode DVM ERC-721 NFT's have been redeemed on Xnode Studio, following [this redemption process](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm) of entering in the 9 digit code on the back of the card. &#x20;

<figure><img src="/files/2z5ti5txpCYvPiNYxXwK" alt=""><figcaption></figcaption></figure>

###

### Xnode Unit Entitlement NFT Collection

By visiting the [Xnode Unit Entitlement NFT collection on Opensea](https://opensea.io/collection/xnode-unit-entitlement) you can see the total amount of Xnode DVM cards claimed by an Ethereum wallet via Xnode Studio.

<figure><img src="/files/cMpgZoXHVG73BolO6w5k" alt=""><figcaption></figcaption></figure>

By clicking on these NFT's within [Opensea's website](https://opensea.io/), you can see further details about which Ethereum wallet claimed ownership of the asset, which contract address the NFT belongs to, the Token ID, the Token Standard (ERC-721) and what date it was claimed or last updated.

<figure><img src="/files/k5JrNOx6osYPN9fCvwkh" alt=""><figcaption></figcaption></figure>

###

### Xnode Unit NFT Collection

By visiting the [Xnode Unit NFT collection on Opensea](https://opensea.io/collection/xnode-unit) you can see the total amount of Xnode DVM cards claimed by an Ethereum wallet via Xnode Studio that also had a bare metal server associated.

<figure><img src="/files/5Jpy37e92K9NpM0jl6Fi" alt=""><figcaption></figcaption></figure>

By clicking on these NFT's within [Opensea's website](https://opensea.io/), you can see further details about which Ethereum wallet claimed ownership of the asset, which contract address the NFT belongs to, the Token ID, the Token Standard (ERC-721) , what date it was claimed or last updated, and the fact it was activated with a bare metal server associated running application workloads.

<figure><img src="/files/GxvBVuJEXs1og8YuZqnR" alt=""><figcaption></figcaption></figure>

### How do I see if any Xnode DVM's are listed for sale and available?

Of course, the Ethereum wallet owner of the Xnode DVM, needs to list the NFT on the marketplace, before a person can buy it. After viewing the respective Openmesh Xnode NFT collection, you need to select the 'Listed' filter status to see what has been listed for sale. All Xnode DVM NFT's typically have a 12-month usage with the associated bare metal provider, after the date it is activated. By default, 'All' is selected as the filter, which shows all listed and unlisted NFT's in this collection.

<figure><img src="/files/bZ0WLImNRAnmtMP5vsUM" alt=""><figcaption></figcaption></figure>

### Innovative Use-Case of Decentralized Cloud DVM's

**It is now possible, for an online business owner to procure decentralized cloud resources, build an online business, and then sell all assets of that business with a single NFT sale on an open NFT marketplace!**&#x20;

Look forward to more innovative use-cases as the Openmesh decentralized cloud ecosystem grows!


# Connecting your Web3 Wallet & Creating a Login Session

1. Hit the connect wallet button in your desktop browser. You can do so at the following Xnode Studio login page link: <https://www.openmesh.network/xnode/login>. Make sure you already have an Ethereum-compatible Web3 wallet available to use, such as Metamask or Brave Browser wallet extension.

<figure><img src="/files/SZR5Ec7t498PQN8JGzbF" alt=""><figcaption></figcaption></figure>

2. Select your Ethereum wallet extension connected to your desktop browser.

<figure><img src="/files/bb6xYFGXH5O9oszFd0Xt" alt=""><figcaption></figcaption></figure>

3. Select your desired wallet extension to use and unlock it.

<figure><img src="/files/GCl3dsIYk0MB3XRRSoOE" alt=""><figcaption></figcaption></figure>

4. Select the Ethereum account you would like to use.

<figure><img src="/files/N323HMcQs1Bw8JGjHSef" alt=""><figcaption></figcaption></figure>

5. Confirm you will grant the needed permissions and duration. Xnode Studio only needs the following to connect a wallet:
   1. Check wallet balance and activity
   2. Request approval for transactions and signatures
   3. View your permitted wallet address

{% hint style="info" %}
Xnode Studio DOES NOT require permission to "Move funds without your permission". Alway check you are at the valid <https://openmesh.network/xnode> URL and triple check which permissions you grant when using a Web3 wallet.
{% endhint %}

<figure><img src="/files/6xrO5NRAt2gyat4AsyD2" alt=""><figcaption></figcaption></figure>

6. Once you have signed the permission authorization the Xnode Studio will show your wallet address details & account balance in the main section of the page (replacing the Connect Wallet button) and also at the top right of the website. This top right button is constant throughout all pages of Xnode Studio to show the wallet is connected and hasn't expired.

<figure><img src="/files/IX3uOMsWcQ2GC98yuXz6" alt=""><figcaption></figcaption></figure>

7. Now that you have an Ethereum wallet connected, let's move on to the next step which is to create a login session.\
   \
   A Login Session is required to link your connected Ethereum wallet to Xnode Studio and display relevant data in the dashboard pages. You will be requested to sign a signature. This will not require gas to approve and sign this.

<figure><img src="/files/TGYgl2BvAusC9xaH09I7" alt=""><figcaption></figcaption></figure>

8. You should now see both the Ethereum Wallet connected and the Login Session created with both sections on the main page appearing green.

<figure><img src="/files/Wa5p3upxHQECwDfIBclV" alt=""><figcaption></figcaption></figure>

9. Once you have both your Ethereum wallet and login session created, you can go back to the <https://www.openmesh.network/xnode/claim> Xnode claim page to enter in your DVM code.


# Redeeming Your DVM

The goal of Xnode Studio is to make it super easy, convenient and quick for a Web3 user to deploy cloud services onto bare metal providers within <10 minutes anywhere in the world.

To facilitate early adoption, Openmesh has created Xnode Decentralized Virtual Machine's (DVM's) to help onboard the next 1000+ Xnode's into the Openmesh network.&#x20;

### Step by Step Tutorial to Redeem your Openmesh Xnode DVM

1. Visit the Xnode DVM claim page at <https://www.openmesh.network/xnode/claim>

<figure><img src="/files/KuO6mSu8NpH0GkAJ2lkQ" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
To connect your Ethereum wallet be sure to check out this guide!

\
<https://docs.openmesh.network/products/xnode/basic-getting-started-guides/connecting-your-web3-wallet-and-creating-a-login-session>
{% endhint %}

2. Connect your Ethereum-compatible Web3 Wallet desktop browser extension.

<figure><img src="/files/wYSdBOU5GtVsczUzszrx" alt=""><figcaption></figcaption></figure>

3. Simply scratch the back of your Openmesh Xnode DVM card to get the 9 digit code and enter it into the Xnode Studio claim page.

<div><figure><img src="/files/x4TOaKpBocA7DnxEc3z1" alt="" width="563"><figcaption></figcaption></figure> <figure><img src="/files/s5H3tGLEZfUI6VjhLjSk" alt="" width="375"><figcaption></figcaption></figure></div>

4. Once your 9 digit code is entered, you should now see in your Dashboard page located at<https://www.openmesh.network/xnode/dashboard>. At the top left of the screen you will see your new bare metal machine name, for example "XnodeDVM M8U". After deploying your App Template from the [App Store](https://docs.openmesh.network/products/xnode/template-deployment-guides), you will then see your "Individual Nodes" machine specs appear.

<figure><img src="/files/0v9r1lnWwrEMrA7ICHbi" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
After you have a DVM deployed and connected to your Ethereum account, you can now deploy [app templates](https://docs.openmesh.network/products/xnode/template-deployment-guides) and [use-cases](https://docs.openmesh.network/products/xnode/use-case-deployment-guides) on to it! Check out the relevant Deployment Guides section to learn more!
{% endhint %}


# Select Template via App Store

The goal of Xnode Studio is to make it easy and quick to deploy Web3 applications onto 32 bare-metal providers around the word in under 10 minutes.

{% hint style="info" %}
With the October 2024 launch of Xnode Studio V4 we have restricted which apps are deployed until full testing and fixes are completed for each template. Currentlythere are 10 templates available to get you started, with another \~40 in development or being re-certified for Xnode Studio V4.
{% endhint %}

You can visit the Xnode Studio App Store at the following URL:

<https://www.openmesh.network/xnode/app-store>

<figure><img src="/files/kfWGdTdaba9MZQMtt1tH" alt=""><figcaption></figcaption></figure>

### 3 Types of App Templates

There are 3 types of App Templates on the App Store:

* App Templates - Single app deployed on to bare metal server. Can have multiple apps deployed per server. Each app is typically separate.
* Use-Cases Templates - Multiple apps deployed on to bare metal server where each app communicate with each other to form an application.
* Advanced Templates - these are custom XnodeOS forked code bases that can be deployed on bare metal servers. <br>

### App Templates

Single app deployed on to bare metal server. Can have multiple apps deployed per server. Each app is typically separate.

<figure><img src="/files/J7Ey6umFQOqVjige7Lzy" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Deploy an [App Template](https://docs.openmesh.network/products/xnode/template-deployment-guides) now!
{% endhint %}

### Use-Cases Templates

These are Multiple apps deployed on to bare metal server where each app communicate with each other to form an application.

An example of this is the combination of a Ollama backend app deployed with a WebUI frontend app.&#x20;

<figure><img src="/files/89KmbDklxcA1pJrowd3y" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Deploy a [Use-Case Template](https://docs.openmesh.network/products/xnode/use-case-deployment-guides) now!
{% endhint %}

### Advanced Templates

Here is an example of an forked advanced template submitted for a recent Openmesh Hackathon:

* [XnodeOS NextJS Template](https://github.com/Openmesh-Network/xnode-nextjs-template) - click to view the Github repo of the original template
* [XnodeOS NextJS Blog Template](https://github.com/johnforfar/xnode-nextjs-template) - this template has been modifying to host a blog by the community
* [XnodeOS NextJs Linktree Template](https://github.com/Arturou/xnode-nextjs-linktree) - this template has been modified to host a Linktree clone by the community

<figure><img src="/files/9w3FYXA8DVrLNJZkBNlS" alt=""><figcaption></figcaption></figure>

{% hint style="info" %}
Deploy an [Advanced Template](https://docs.openmesh.network/products/xnode/advanced-deployment-guides) now!
{% endhint %}


# Deploy to DVM or Bare Metal

When deploying an app template from the [App Store](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/select-template-via-app-store), you can choose from multiple deployment targets  when making the deployment. This is done by selecting the Deploy button from the App Store app template, use case, or advanced template page.

<figure><img src="/files/vysGQboXRoarlrZi6BVV" alt=""><figcaption></figcaption></figure>

After selecting the Deploy button you will be presented with 4 options as deployment targets.

* Xnode DVM (existing) - if you have already [redeemed your existing Openmesh Xnode DVM](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm), then you will see it's ID at the top of the deployment  server page. You can choose to deploy here if it has sufficient storage available.
* Xnode DVM (new) - if you have a new Xnode DVM, then you can scratch the back of the card and [redeem the code](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm), to deploy to a new bare metal machine.&#x20;
* Bare Metal (coming soon) - in an upcoming release you will be able to select from 32 bare metal service providers around the world by simply providing your respective API Key.
* Openmesh Early Validator (coming soon) - with an upcoming Early Node Validator Pass it will be possible to run a higher spec validator for Chainlink & Avalanche.

<figure><img src="/files/Ii7HJTiht2ecf5tV7KvK" alt=""><figcaption></figcaption></figure>

When selecting a bare metal provider, you can filter by several options:

* The [Openmesh Cloud](https://docs.openmesh.network/products/openmesh-cloud) is coming soon. For each Xnode deployed a small % of resources is allocated to created the Openmesh Cloud. Read more at the [Openmesh Cloud](https://docs.openmesh.network/products/openmesh-cloud) documentation pages.
* Xnode DVM are cloud credits given away by Openmesh to support builders, startups and new clients onboard into the Openmesh ecosystem. Read more about [redeeming your DVM](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm) here.
* Bare metal machines can be selected directly within this bare metal provider page. You can filter from 32 bare metal providers across 100's of datacenters located all across the world. You can search by provider name, location, and filter by price or region.

<figure><img src="/files/qEYKxIdebf5fO177oxnj" alt=""><figcaption></figcaption></figure>

Once selecting a bare metal machine, you will be able to specify the bare metal provider API key directly. This removes Openmesh Xnode Studio from being a "middleman" as you are dealing directly with the bare metal provider in a decentralized manner.

<figure><img src="/files/SI50t9cB1gLl9lKGw3Mx" alt=""><figcaption></figcaption></figure>


# Monitoring Your Deployments

Once you have deployed your App Template or Use-case Template, you can then monitor what has been deployed onto your bare-metal server.

Visit the deployments page: <https://www.openmesh.network/xnode/deployments>

<figure><img src="/files/L6QmX7FU8Ts0tLh98Xao" alt=""><figcaption></figcaption></figure>

From here you will see a list of bare metal servers that are associated with your connected Web3 Wallet.

<figure><img src="/files/tkHOp8mhT8Ewfp2ZAHQM" alt=""><figcaption></figcaption></figure>

After selecting the Xnode DVM bare metal server you can now see all your app deployments and resources used including CPU utilization, RAM utilization and Storage used.

Another important part of this screen is the status, this changes from Online to Configuring during app deployments and tells you if any errors with your server. The IP Address is also specified, which forms the base URL for all apps deployed here, with the port number being specific in the app settings popup within each app deployment at the bottom of the page.

Finally, as your Xnode DVM typically has a limited duration of 12 months (365 days) you can also see the "Remaining Xnode Time" at the top of the page.

<figure><img src="/files/6SlqJQiITiySa7UVHoXs" alt=""><figcaption></figcaption></figure>


# Template Deployment Guides

App templates are single NixOS package templates that can be deployed onto bare metal machines. You can install multiple packages on one bare metal deployment.

### App Template Deployment Guides

* [Deploying a Minecraft Server](/products/xnode/template-deployment-guides/deploying-a-minecraft-server)
* [Deploy Your Own Chainlink Data Feed & CCIP Databoard](https://docs.openmesh.network/products/xnode/template-deployment-guides/deploy-a-chainlink-data-dashboard)


# Deploy a Chainlink Data Dashboard

Thanks to our partnership with Chainlink, we can deploy Xnodes with Chainlink Oracle Data Feeds and CCIP message data! [Learn more about the integration here](https://docs.openmesh.network/products/integrations/chainlink-ccip).

<figure><img src="/files/FnUzoLmkvXyTpOeTvHcy" alt=""><figcaption></figcaption></figure>

### How to Build Your Own Chainlink Data Dashboard

Like all deployments, make sure to connect your [web3 wallet and create a session](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/connecting-your-web3-wallet-and-creating-a-login-session).

Then visit the [App Store](https://www.openmesh.network/xnode/app-store) from within your Xnode Studio dashboard and select the Chainlink app template.

<figure><img src="/files/E02NlDHpnB4OPtMAH7Dh" alt=""><figcaption></figcaption></figure>

After selecting the App Template, you will need to hit the Deploy button.

<figure><img src="/files/Ki6M8pkyMk3gHmwG4qdd" alt=""><figcaption></figcaption></figure>

From there, choose your deployment target. For this example, we have already [redeemed and deployed a DVM](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm). Select it and then hit the Deploy button.

<figure><img src="/files/tnEgAzA7zr1fr8Tr4wPj" alt=""><figcaption></figcaption></figure>

After Deploying to your deployment target (our DVM) then you can wait for the deployment to start running.

<figure><img src="/files/votBEQCjfyAZZGGbJ852" alt=""><figcaption></figcaption></figure>

Once it is running you will now be able to select the "Go to Deployment" button.

<figure><img src="/files/rg0ObAuXVhbegIaK5DDR" alt=""><figcaption></figcaption></figure>

On the Dashboard you can see your deployed bare metal server along with all the Apps installed on it. As we have only just created the DVM, it has our Chainlink Data Dashboard.&#x20;

At the top left the current deployment status shows it is "Configuring".

<figure><img src="/files/s6oVfS9eUcOi0Sg4d3K1" alt=""><figcaption></figcaption></figure>

Once the deployment status has moved to "Online", you will be able to view the app, by selecting the URL shortcut to the left of the App name. (See highlighted green square areas in the screenshot below).

<figure><img src="/files/OvzfiPQfelWfWXQdDZjU" alt=""><figcaption></figcaption></figure>

By selecting the shortcut icon, it will navigate you to the deployment URL. From here you can see the current price of the various digital assets listed on the screen. If you wait for multiple time intervals to pass it will render a graph line to track price movements.

This utilises [Chainlink Oracle Price Feeds](https://docs.openmesh.network/products/integrations/chainlink-ccip) and then displays them on a NextJS Template. [This template is open source](https://github.com/Openmesh-Network/chainlink-data-dashboard) and you can customise and then deploy it via the [Advanced Template process](https://docs.openmesh.network/products/xnode/advanced-deployment-guides).

<figure><img src="/files/o2mJuUF5V5BEmYvTJWLY" alt=""><figcaption></figcaption></figure>

You can also select the tab at the top right, to see another important Chainlink feature called Cross-[Chain Interoperability Protocol (CCIP)](https://docs.openmesh.network/products/integrations/chainlink-ccip). which is essentially trustless messaging between blockchains. [Learn more about the CCIP here](https://docs.openmesh.network/products/integrations/chainlink-ccip).

<figure><img src="/files/TWK7HnHDLp60lkxVGi3G" alt=""><figcaption></figcaption></figure>


# Deploying a Minecraft Server

<figure><img src="/files/YX8nXft0Kf8pC8VBtMOp" alt=""><figcaption></figcaption></figure>

It is easy to run a Minecraft server on top of your Xnode by following this App Template for deploying Minecraft!

Like all deployments, make sure to connect your [web3 wallet and create a session](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/connecting-your-web3-wallet-and-creating-a-login-session).

Then visit the [App Store](https://www.openmesh.network/xnode/app-store) from within your Xnode Studio dashboard and select Minecraft app template.

<figure><img src="/files/cfC2vp0krLoAjBkPsyM0" alt=""><figcaption></figcaption></figure>

Once you have selected the Minecraft app template, you can now configure it by selecting the Edit button.

<figure><img src="/files/nmXtOjEYKJvLbAlPlyi0" alt=""><figcaption></figcaption></figure>

There is only one configuration needed, which our template cannot automate. This setting is important to Minecraft, which is manually selecting that you agree to the EULA agreement.

<figure><img src="/files/8L8OrF9xGrXg2Af9Nzko" alt=""><figcaption></figcaption></figure>

Now that the configuration is complete, you can now select the deployment target.

For our guide we will be deploying to our existing DVM. Please read this [Redeem your DVM Getting Started Guide](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm), if you need to get your DVM bare metal server allocated and deployed.

<figure><img src="/files/umOg8grAh6WpfEK8KGT3" alt=""><figcaption></figcaption></figure>

Once your deployment target is selected and you hit deploy, you will be presented with a loading page. This provides an estimation of the total deployment time, however you can select Go to Deployment button to see the live status.

<figure><img src="/files/4er1t6Fs1lHFHUIoSm0P" alt=""><figcaption></figcaption></figure>

At the top left of page you will see "Progressing" move to "Online" once it is ready. Take note of the IP address of your bare metal server just next to this, as it will be needed to be entered when configuring Minecraft.

<figure><img src="/files/yEy24SXsRPmRztGNDFhh" alt=""><figcaption></figcaption></figure>

Open up Minecraft. On MacOS for the purposes of this guide we will be using [Minecraft Java Edition which can be downloaded here](https://www.minecraft.net/en-us/download). You will need to login with your Microsoft account.

<figure><img src="/files/aOP8SNvFzYenrBTzowC3" alt=""><figcaption></figcaption></figure>

Once Minecraft is installed it will automatically download any updates needed for the client. Currently our App Template for Minecraft supports version 1.21 so you must ensure your client is also running Minecraft 1.21 otherwise you will receive a version error. After selecting the version select the Play button.

<figure><img src="/files/QZLqamXbzEQk8juwcsrf" alt=""><figcaption></figcaption></figure>

Once in Minecraft, select Multiplayer.

<figure><img src="/files/AhN5ZqSjuqWzNnZuZv59" alt=""><figcaption></figcaption></figure>

From the Multiplayer screen select Add Server. You will need to configure a new server within the Minecraft client to point to your Xnode Minecraft server. For our guide example, it is 74.50.98.253 and the server name can be anything you want. Select the Done button.

<figure><img src="/files/yUos1GT6GrricVUEE5AU" alt=""><figcaption></figcaption></figure>

Assuming you have selected the correct Minecraft version and correct IP address, it will now appear as a playable multiplayer server showing server name, player count and server latency! Hit the Join Server to continue.

<figure><img src="/files/XH41qMr5LjcwZuhV6LkC" alt=""><figcaption></figcaption></figure>

You are now in Minecraft! 🔥🔥🔥 Watch out for Zombies&#x20;

<figure><img src="/files/zSkI9JoJB2prpXfJAvuw" alt=""><figcaption></figcaption></figure>


# Use-Case Deployment Guides

Use-case deployments are deployments of multiple app templates that communicate with eachother.&#x20;

### Use Case Deployment Guides

* [Deploying Ollama + Open WebUI App](https://docs.openmesh.network/products/xnode/use-case-deployment-guides/deploying-ollama-+-open-webui-app)


# Deploying Ollama + Open WebUI App

Lets deploy a 'Use-Case' which is multiple server app templates deployed together. For this guide we will be deploying Ollama LLM framework + Open-webui frontend UX.&#x20;

This is a powerful combination of 2 apps, that allows you to access and interact with powerful AI LLM's directly from your web browser, allowing you to switch between current industry-leading open source models like Llama3.1 & Mistral. This template streamlines the process, to get an LLM and GenAI chatbot frontend running on your bare metal server!

Make sure to connect your [web3 wallet and create a session](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/connecting-your-web3-wallet-and-creating-a-login-session), then visit the [App Store](https://www.openmesh.network/xnode/app-store) from within your Xnode Studio dashboard and select "Use-Cases" tab at the top of the page.

<figure><img src="/files/DbhdeKBtJNShFnV7z6kS" alt=""><figcaption></figcaption></figure>

Once you have selected the Ollama + Open-webui Use Case, you need to select your deployment target. For this deployment guide we will be using a bare metal Xnode we have previously [redeemed](https://docs.openmesh.network/products/xnode/basic-getting-started-guides/redeeming-your-dvm).

<figure><img src="/files/kLMBODae0SLdhlRy2hWA" alt=""><figcaption></figcaption></figure>

Selecting the DVM will then deploy it, with an estimated time of 2 minutes. Of course, you can select "Go to Deployment" button to see it's live deployment status.

<figure><img src="/files/H1cbndpKyd0KYH3GpRWy" alt=""><figcaption></figcaption></figure>

Going back to the bare metal page, you can see what Apps are deployed on your server.

As we have selected a Use Case, it has deployed 2 app templates, Ollama and Open WebUI.

By selecting the the arrow icon, it will take you to your chatbot frontend website URL.

<figure><img src="/files/GeX1OJeW2NMGKgzaEbdS" alt=""><figcaption></figcaption></figure>


# Advanced Deployment Guides

As Openmesh is a fully open-source project, you can modify the XnodeOS template to deploy a wide variety of NixOS packages.

Here is an example of an advanced template that can be used for any NextJS deployment and a variety of forks submitted for the recent Openmesh "Speedhack" Hackathon at the Chainlink SmartCon conference:

* [XnodeOS NextJS Base Template](https://docs.openmesh.network/products/xnode/advanced-deployment-guides/xnode-nextjs-base-template) - click to view the our guide on deploying the NextJS base template which deploys a simple "Hello World" static website. We also have open source community submissions a blog template, a Linktree clone and a Notion app, all fully hosted and deployed on Openmesh!


# Xnode NextJS Base Template

{% hint style="info" %}
In order to show how easy it is to leverage Xnode Studio, XnodeOS (forked NixOS) and bare metal server providers, we are working with the open source developer community to host hackathons where devs can submit their new app templates and get rewarded! Check out our [open source bounty platform called Open R\&D](https://openrd.openmesh.network/tasks) where you can complete development tasks to earn bounties! These tasks are created, reviewed and funds escrowed in alignment to our Openmesh hackathon initiatives! The first one was completed during the Openmesh Speedhack hackathon at the Chainlink SmartCon HK 2024 event.
{% endhint %}

### The Xnode NextJS Base Template

The NextJS base template is the foundational code needed to deploy your NextJS application locally and then onto Openmesh bare metal servers.

[Xnode NextJS Base Template - Github Repo](https://github.com/Openmesh-Network/xnode-nextjs-template)

<figure><img src="/files/O6Xfxq4IavQuI7djoQ2s" alt=""><figcaption></figcaption></figure>

This template is provided so you can make your NextJS app Xnode/Nix compatible.

### Base Template Modification Steps

1. Replace all instances of "xnode-nextjs-template" with the name of your project. This should be unique, as no apps with the same name can be run on a single Xnode.
2. Build your NextJS app
3. In case your npm dependencies change, run `nix run` in the root folder and replace the npmDepsHash in [package.nix](https://github.com/Openmesh-Network/xnode-nextjs-template/blob/main/nix/package.nix) with the got hash in the error.
4. Once your app is ready for deployment and runs using `nix run`, push to GitHub and copy your GitHub url (e.g. <https://github.com/Openmesh-Network/xnode-nextjs-template>).
5. Go the the App Store in [Xnode Studio](https://www.openmesh.network/xnode/app-store) and go to the advanced tab.
6. Paste your GitHub url and enter the name of the project you choose during step 1.
7. Hit deploy and wait for your app to be ready.
8. Copy the deploy link and replace the one click deployment url in the next section. (to allow others to easily deploy your application)

### One click deployment

<div align="left"><figure><img src="/files/I9ln2C0YS6BQnkGHIh66" alt=""><figcaption></figcaption></figure></div>

You can find the one click [deploy button at the Github repository readme page](https://github.com/Openmesh-Network/xnode-nextjs-template) (cannot embed the link within Gitbook). When you click it it will quickly deploy this NextJS Base Template to Xnode after you connect your wallet to Xnode Studio.

### Commands (in root folder)

```
nix run
```

### Commands (in nextjs-app)

```
npm i
npm run dev
npm run build
npm run start
```

### Deployment Tips

We are updating XnodeOS to use the latest NixOS features like Flakes. Therefore, if you have any errors that are Flake related please try the following nix run commands:

```
nix run --extra-experimental-features "nix-command flakes"
```

You can also update the \~/.config/nix/nix.conf file with the following to make it flakes permanent, so that the simple "nix run" will execute successfully:

```
experimental-features = nix-command flakes
```

### Openmesh Developer Community Forks

During our Openmesh developer community hackathons, we have already had submissions for other  NextJS base template [Forks](https://github.com/Openmesh-Network/xnode-nextjs-template/forks) that you can deploy on top of Openmesh. All community submissions are external to Openmesh (not on the official repo or supported). Please conduct your own due diligence on the code modifications from the base template.

* [Xnode NextJS Blog Template](https://github.com/johnforfar/xnode-nextjs-template) by [johnforfar](https://github.com/johnforfar)
* [Xnode NextJS Linktree Template](https://github.com/Arturou/xnode-nextjs-linktree) by [Arturou](https://github.com/Arturou)
* [Xnode NextJS Notion Template](https://github.com/elbarroca/OpenMesh__Blog_Speedaton) by [elbarroca](https://github.com/elbarroca)


# Xnode One

{% hint style="info" %}
In active development
{% endhint %}


# Openmesh Cloud

{% hint style="info" %}
In active development
{% endhint %}

<figure><img src="/files/pobVZ0esAHydDSihY08N" alt=""><figcaption></figcaption></figure>

### Overview

Openmesh Cloud is a decentralized infrastructure platform that enables peer-to-peer resource sharing and consumption. The system allows users to rent out their compute and storage resources to the network, while others can consume these resources through a decentralized marketplace.

### Architecture Components

#### Openmesh Core

At the heart of Openmesh Cloud lies Openmesh Core, built on CometBFT (a Tendermint implementation in Go). This consensus engine maintains network integrity using Byzantine Fault Tolerant (BFT) consensus, ensuring secure and reliable operations across the decentralized cloud infrastructure.

The consensus process begins with block proposal, where a proposer is selected for each round using a stake-weighted algorithm. The chosen proposer creates new blocks containing valid transactions and broadcasts them across the network. This initiates a structured voting sequence where validators participate in a two-phase voting process.

#### Consensus Management

The voting process consists of pre-vote collection, where validators assess block validity, followed by pre-commit collection once sufficient pre-votes are gathered. When a block receives more than two-thirds of pre-commits, it achieves final commitment status and is permanently added to the blockchain, ensuring immediate finality.

Critical consensus components:

* Pre-vote collection and validity assessment
* Pre-commit gathering and block finalization
* Final commitment and state transition

#### Resource Management

Transaction integrity is maintained through comprehensive verification procedures. Each transaction undergoes thorough validation, including digital signature verification and double-spending prevention. The system enforces protocol-specific rules before applying valid transactions to the current state, producing a new agreed-upon state across the network.

#### Security Framework

Openmesh Cloud implements Byzantine Fault Tolerance, allowing the network to maintain consensus even when up to one-third of nodes are malicious or faulty. The system includes mechanisms for detecting and punishing misbehavior through stake slashing of malicious validators.

Key security features:

* Byzantine Fault Tolerance up to one-third malicious nodes
* Automated detection and punishment of protocol violations
* Comprehensive state consistency verification

#### Data Validation

The data validation process assigns different data sources to nodes at each block interval. Nodes fetch and validate data from their assigned sources, with the core handling IPFS-based data seeding. Each validated dataset receives a Content Identifier (CID), which is then submitted as a transaction to the network.

### Future Development

Openmesh Cloud aims to evolve into a comprehensive resource aggregator across multiple networks. The platform will enable seamless integration of various compute and storage networks, optimizing resource allocation and pricing while maintaining decentralized principles.


# Openmesh Core

{% hint style="info" %}
In active development
{% endhint %}

Openmesh Core is a crucial piece of software that is responsible for maintaining consensus among different validator nodes in the network. Openmesh-core utilizes the Tendermint consensus protocol, which is a **Byzantine Fault Tolerant** (BFT) consensus algorithm, to ensure secure and reliable blockchain operations. The specific implementation of **Tendermint** used by Openmesh-core is **CometBFT**, written in Go.

### Responsibilities of Core

* **Block Proposal**:
  * **Selection of Proposer**: The core is responsible for selecting the proposer (validator) for each round in a fair manner, typically using a round-robin or weighted round-robin approach based on stake.
  * **Block Creation**: The selected proposer creates a new block with valid transactions and broadcasts it to all validators.
* **Voting Process**:
  * **Pre-vote Collection**: The core collects pre-votes from all validators for the proposed block. Each validator votes based on the validity of the block.
  * **Pre-commit Collection**: After pre-votes are collected, the core collects pre-commits from validators who have received sufficient pre-votes.
  * **Final Commit**: The core ensures that if a block receives more than two-thirds of the pre-commits, it is added to the blockchain.
* **Transaction Validation**:
  * **Transaction Verification**: The core verifies the validity of transactions included in the proposed block. This includes checking digital signatures, ensuring no double-spending, and validating any other protocol-specific rules.
  * **State Transition**: The core applies valid transactions to the current state, producing the new state that will be agreed upon.
* **Network Communication**:
  * **Message Broadcasting**: The core handles the broadcasting of proposal, pre-vote, pre-commit, and commit messages to all validators in the network.
  * **Synchronizing Nodes**: The core ensures that all nodes stay synchronized, resolving any discrepancies in state or blockchain history.
* **Fault Tolerance and Security**:
  * **Byzantine Fault Tolerance**: The core implements mechanisms to handle up to one-third of nodes being malicious or faulty, maintaining consensus despite these issues.
  * **Punishment and Slashing**: The core is responsible for detecting and punishing misbehavior, such as double-signing or other forms of protocol violations, by slashing the stake of malicious validators.
* **Consensus Finality**:
  * **Immediate Finality**: The core ensures that once a block is committed, it is final and cannot be reverted, providing security and confidence to users and applications relying on the blockchain.
* **State Management**:
  * **State Updates**: The core manages the application of committed transactions to the state, ensuring that all nodes have a consistent view of the blockchain state.
  * **Data Integrity**: The core ensures the integrity and correctness of the state data, preventing corruption and inconsistencies.
* **Protocol Upgrades**:
  * **Consensus Upgrades**: The core may facilitate upgrades to the consensus protocol, ensuring smooth transitions without disrupting the network.
  * **Feature Implementation**: The core implements new features and improvements in the consensus mechanism, enhancing performance, security, and functionality.
* **Data Validation and Seeding:**
  * **Data Submission:** At each block each node is assigned a different data source to fetch data from until the next block. The data is than seeded by the core via IPFS and a CID of the data is submitted as a transaction.&#x20;
  * **Data Seeding:** The core is responsible for seeding the Data in the network. The core seeds the data via IPFS.


# Decentralized Service Mesh Protocol (DSMP)

### Abstract

{% hint style="info" %}
In active development
{% endhint %}

The Openmesh Decentralized Service Mesh Protocol (DSMP) is designed to enable decentralized service discovery, communication, and orchestration in the Openmesh network. The protocol allows individuals and organizations to run and manage services (called Service Mesh Workers) on Xnodes—physical or virtualized hardware—while allowing others to consume these services. By fractionalizing service mesh tasks, sharing resources, and enabling decentralized observability, DSMP provides a scalable, resilient, and decentralized alternative to traditional service mesh architectures. This paper outlines the architecture, protocols, consensus mechanisms, and the economic model underlying DSMP.

***

### 1. Introduction

Service meshes are a critical component of modern distributed systems, allowing services to communicate, discover, and manage one another. However, traditional service meshes like **Istio** and **Linkerd** operate in centralized environments, making them unsuitable for decentralized cloud platforms. The **Decentralized Service Mesh Protocol (DSMP)** from Openmesh addresses this gap by offering a fully decentralized approach to service communication, resource sharing, and observability.

DSMP allows anyone to run services, known as **Service Mesh Workers**, on Xnodes within the Openmesh network, while enabling others to consume these services. Instead of running isolated services or relying on centralized cloud infrastructure, DSMP offers a decentralized environment where service operators can share their resources and offer their services to the network.

***

### 2. Architecture of DSMP

#### 2.1 Service Mesh Workers

A **Service Mesh Worker** is an independent service running on an Xnode. It can be a microservice, a compute task, or an application running on the Openmesh network. Service Mesh Workers can be made **public** or **private**:

* **Public Service Mesh Workers:** These are advertised in the network, and anyone can subscribe to use them.
* **Private Service Mesh Workers:** These are limited to specific users or groups.

#### 2.2 Xnodes

**Xnodes** are the backbone of the Openmesh network. They represent physical servers, virtual machines, or custom hardware owned by individual users or organizations. Xnodes run services, store data, and participate in the Openmesh consensus mechanisms.

#### 2.3 Decentralized Communication and Resource Sharing

At the core of DSMP is a **peer-to-peer (P2P)** communication model, where each Xnode can discover, communicate, and share resources with other Xnodes. Through this decentralized communication framework, DSMP enables:

* **Decentralized Service Discovery:** Xnodes can discover available services via the **Kademlia Distributed Hash Table (DHT)**.
* **Resource Fractionalization:** Services do not need to run in isolation; they can utilize shared compute, storage, or networking resources offered by multiple Xnodes.
* **Service Observability:** Service Mesh Workers advertise their usage statistics, allowing for network-wide visibility through the **Open Observability Protocol**.

#### 2.4 Open Observability Protocol

DSMP integrates an **Open Observability Protocol**, providing a transparent and decentralized way for Service Mesh Workers to display their metrics:

* **Subscription Counts:** Anyone can see which Service Mesh Workers are the most subscribed to.
* **Performance Metrics:** Uptime, response time, and other service performance data are made publicly available.
* **Fault Detection:** Any faults, errors, or failures are tracked and made visible, enabling automatic recovery and fault-tolerance mechanisms.

***

### 3. Protocols Enabling DSMP

#### 3.1 Kademlia Distributed Hash Table (DHT) for Service Discovery

The Kademlia DHT provides a decentralized and efficient way for Xnodes to discover Service Mesh Workers within the network:

* **Key-Value Store:** Each Service Mesh Worker is assigned a unique key in the DHT, mapping to its network location and metadata.
* **Efficient Lookup:** Kademlia enables quick lookups for services, ensuring low-latency discovery of available Service Mesh Workers.
* **Fault Tolerance:** The DHT is fault-tolerant, allowing for service discovery even if some nodes in the network go offline.

#### 3.2 Libp2p for Peer-to-Peer Communication

**Libp2p** is the foundational networking layer that DSMP uses for peer-to-peer communication between Xnodes. Key features include:

* **Secure Communication:** Provides encrypted communication between nodes to ensure privacy and integrity.
* **Transport Flexibility:** Supports multiple transport protocols (TCP, QUIC, WebRTC) for efficient networking in different environments.
* **Service Discovery:** Works in conjunction with Kademlia DHT to enable dynamic service discovery and task delegation.

#### 3.3 Task Delegation with Resource-Aware Distribution

DSMP uses a **Delegated Task with Resource-Aware Distribution** model for assigning tasks to Service Mesh Workers:

* **Resource Awareness:** Each Xnode advertises its available compute, memory, and storage resources.
* **Task Delegation:** Tasks are assigned to Xnodes based on their available resources and capacity. Larger tasks are given to nodes that can handle them, while smaller nodes take on smaller, simpler tasks.
* **Load Balancing:** Tasks are distributed dynamically to avoid overloading any single Xnode, ensuring even distribution of network workloads.

***

### 4. Consensus Mechanisms in DSMP

#### 4.1 Proof of Stake (PoS)

DSMP uses **Proof of Stake (PoS)** to ensure the correctness of tasks performed by Service Mesh Workers:

* **Token Staking:** Xnode operators must stake **Open tokens** to participate in task execution. This ensures accountability, as nodes that fail to perform tasks correctly can lose their staked tokens.
* **Task Verification:** Other nodes in the network verify the correctness of completed tasks. If a node is found to be acting maliciously or failing to perform its task, it is penalized.

#### 4.2 Proof of Resource (PoR)

**Proof of Resource (PoR)** is used to validate that Xnodes offering their resources can indeed deliver the promised compute or storage capacity:

* **Resource Verification:** Before a task is assigned, the Xnode provides proof that it has the necessary resources (CPU, GPU, storage) to complete the task.
* **Continuous Proof:** Xnodes must provide regular proofs to show that they are maintaining their advertised resources over time.

#### 4.3 Byzantine Fault Tolerance (BFT)

DSMP integrates **Byzantine Fault Tolerance (BFT)** for task result verification:

* **Task Redundancy:** For critical tasks, multiple nodes may be assigned the same task. BFT ensures that consensus is reached on the correct task result, even if some nodes behave maliciously or fail.
* **Fault-Tolerant Consensus:** BFT allows the network to tolerate faulty or malicious nodes without compromising the accuracy of task results or network stability.

***

### 5. Service Mesh Worker Operation

#### 5.1 Fractionalizing Services

DSMP enables **fractional service operation**, where multiple Xnodes share resources to operate a service:

* **Compute and Storage Sharing:** Instead of dedicating one node to run an entire service, multiple Xnodes can combine their resources to run the service collaboratively.
* **Dynamic Resource Pooling:** The Openmesh protocol dynamically allocates compute, storage, and networking resources based on service demand. As the number of consumers increases, additional resources are allocated automatically.

#### 5.2 Service Subscription and Commitment

Consumers can subscribe to **public Service Mesh Workers** and use their services. DSMP incorporates a commitment mechanism to ensure long-term availability:

* **Subscription Mechanism:** Consumers can subscribe to Service Mesh Workers and pay a fee in Open tokens. This commitment can be reflected as either a one-time payment or a recurring subscription.
* **Staking for Accountability:** Service providers can stake Open tokens to signal accountability. The more they stake, the more confidence consumers have in their reliability.

***

### 6. Open Observability Protocol

#### 6.1 Transparent Metrics

The **Open Observability Protocol** in DSMP provides a transparent layer of metrics that are accessible to all nodes:

* **Service Usage Statistics:** Displays the number of consumers subscribed to a Service Mesh Worker and the resource consumption patterns.
* **Performance Metrics:** Uptime, response time, and reliability are continuously monitored and made available for public review.
* **Fault Reporting:** Errors and failures are logged and available for network-wide review, allowing automatic fault detection and recovery.

#### 6.2 Decentralized Monitoring

Monitoring is decentralized, with metrics collected and aggregated by multiple nodes. There is no single point of failure or control, ensuring resilient and reliable monitoring of services in DSMP.

***

### 7. Incentive and Economic Model

#### 7.1 Token-Based Payment and Incentive System

DSMP operates on a token-based economy where Service Mesh Workers are compensated in Open tokens for offering their services. Key components include:

* **Service Fees:** Consumers pay Service Mesh Workers in Open tokens based on their resource usage or subscription model.
* **Staking and Rewards:** Nodes can earn additional tokens by staking tokens and performing tasks correctly. Misbehaving nodes lose a portion of their stake as a penalty.

#### 7.2 Resource Leasing

Xnode operators can lease their idle resources to other nodes through the DSMP:

* **Compute Leasing:** Xnodes can lease their unused compute power to other services that need additional capacity.
* **Storage Leasing:** Xnodes with excess storage can lease it to services that require decentralized storage, receiving Open tokens in return.

***

### 8. Fault Tolerance and Recovery Mechanisms

#### 8.1 Automatic Task Reallocation

In the event that a Service Mesh Worker becomes unavailable or fails to complete a task, DSMP automatically reallocates the task to another node:

* **Fault Detection:** The Open Observability Protocol continuously monitors service health and identifies failures.
* **Task Reassignment:** Failed tasks are quickly reassigned to healthy Xnodes to ensure seamless service continuity.

#### 8.2 Redundant Service Execution

Critical services can be executed redundantly across multiple Xnodes, ensuring that even if one node fails, the service remains operational:

* **Byzantine Fault Tolerance** ensures that redundant service execution results are verified for consistency.

***

### 9. Conclusion and Future Directions

The **Openmesh Decentralized Service Mesh Protocol (DSMP)** is a robust, scalable, and fully decentralized service management framework. By leveraging decentralized communication protocols like **Kademlia DHT** and **libp2p**, and consensus mechanisms like **PoS**, **PoR**, and **BFT**, DSMP ensures efficient, secure, and fault-tolerant service discovery, communication, and task execution.

Future developments will focus on further optimizing resource pooling, enhancing security protocols, and improving the token economics to attract more service providers and consumers to the Openmesh network.

<br>


# Openmesh API

{% hint style="info" %}
In active development
{% endhint %}

## Openmesh API

### Overview & Position in Openmesh Cloud

Openmesh API serves as the data access layer within the broader Openmesh Cloud ecosystem. While Openmesh Cloud provides decentralized infrastructure for compute and storage resources, the API layer enables standardized access to blockchain and market data through this infrastructure. This integration ensures that data access remains decentralized while maintaining high performance and reliability.

### Technical Architecture

The system implements multiple access methods tailored to different use cases. WebSocket services deliver real-time market events with minimal latency, critical for applications requiring immediate data updates. Historical data access operates through scalable object storage served via CDN, optimized for applications requiring extensive historical analysis. For targeted analytics, the system integrates directly with Pythia's visualization capabilities.

### Universal Data Collector (UDC)

The Universal Data Collector functions as a cornerstone component within the Openmesh ecosystem. When network nodes validate a new block, the UDC connects to source APIs through WebSocket connections, segmenting incoming data into discrete chunks. Each chunk receives a unique IPFS Content Identifier (CID), enabling peer-to-peer distribution through the Boxo protocol.

Blockchain data processing occurs through direct node connections via JSON RPC calls. This architecture processes raw blockchain data into human-readable events without relying on external APIs. After collection, data undergoes normalization using industry standards, receiving validation through consensus before indexing in the Openmesh Ledger.

Smart contract events undergo specialized processing, particularly for DeFi protocols where event data exists outside block headers. The OpenmeshDAO governs the selection of valuable data sources, determining which contract events merit collection and indexing under specific topics.

### Data Flow & Processing

The infrastructure implements a sophisticated multi-stage processing pipeline designed for horizontal scalability and high throughput. Exchange data enters the system as semi-structured JSON, partitioned by exchange-symbol pairs, while blockchain data utilizes the Apache Avro format for efficient schema preservation.

Stream processors operate in parallel, maintaining event order integrity for exchange-specific data while enabling massive scalability. Raw data archives persist in compressed JSON format within object storage, while processed data converts to Apache Parquet for optimal column-based storage efficiency.

The datetime-based partitioning structure organizes events by year, month, day, and hour, facilitating efficient data retrieval. A PostgreSQL database provides advanced querying capabilities, while a scalable broadcaster network enables real-time event distribution.

### Connector Infrastructure

Data connectors form the entry point for the Openmesh data pipeline, facilitating real-time ingestion from both on-chain and off-chain sources. The system employs containerized architecture managed through Kubernetes, ensuring stateless operation for rapid scaling and isolated failure domains.

Error handling encompasses sophisticated retry mechanisms and connection monitoring. The modular codebase supports extension to any arbitrary data source, enabling community contribution while maintaining system integrity.

### Supported Data Types & Schema

Symbol notation follows the format \<base>.\<quote>-\[PERP], accommodating both spot pairs and perpetual futures markets. Off-chain data coverage encompasses comprehensive exchange data, including order books, trades, market metrics, futures data, and real-time indicators.

On-chain data coverage provides extensive Ethereum blockchain data, including raw blocks, transactions, logs, and token transfers. DeFi protocol coverage includes the top thousand trading pairs by volume across major platforms.

### Integration with Cloud & Pythia

The API layer integrates seamlessly with both Openmesh Cloud's decentralized infrastructure and Pythia's analytics capabilities. Cloud integration enables distributed data storage and processing, while Pythia integration provides sophisticated data visualization and analysis tools.

Future developments will expand blockchain coverage and enhance data processing capabilities, leveraging Openmesh Cloud's growing network of decentralized resources.


# Pythia

{% hint style="info" %}
In active development
{% endhint %}

### Overview & Role in Openmesh Cloud

Pythia functions as the advanced analytics engine within the Openmesh Cloud ecosystem. As Openmesh Cloud provides decentralized infrastructure and the API layer handles data collection, Pythia enables sophisticated data analysis and visualization through direct integration with these components. This positioning allows Pythia to leverage the decentralized nature of Openmesh Cloud while providing centralized analytics capabilities.

{% embed url="<https://youtu.be/nArL3rfswxs>" %}

### Technical Architecture

Pythia interfaces directly with Openmesh's primary PostgreSQL database, executing user-defined queries through an efficient queue management system. The platform provides a SQL IDE interface accessible to both authenticated and anonymous users, enabling complex data analysis while maintaining system performance.

The architecture implements multiple storage layers, combining primary database access with object storage integration for historical data and real-time event streams for live analysis. Query routing automatically selects optimal data sources based on query requirements, balancing performance with data freshness.

### Authentication System

The authentication architecture implements Web3-native principles, eliminating traditional password requirements in favor of blockchain-based verification. The process begins with server-generated nonce assignment to user addresses, followed by Ethereum wallet signature verification. This system maintains minimal user data, storing only Ethereum addresses as unique identifiers.

### Data Processing & Storage

Data access patterns optimize for both performance and flexibility. Raw data queries can access compressed JSON archives when necessary, while structured queries utilize columnar storage for optimal performance. Real-time queries integrate directly with live event streams, providing immediate market insights.

The system implements sophisticated caching through Redis, optimizing resource utilization while maintaining data freshness. Cache management includes user-defined timeouts and intelligent invalidation strategies, balancing performance with data accuracy.

### Query & Visualization Engine

The query engine supports both direct SQL execution and natural language processing for query generation. This dual approach enables both technical users to write complex queries and non-technical users to access data through conversational interfaces. The visualization layer supports multiple data representation formats, enabling custom chart creation and data export functionality.

Result sets implement row-limit management for efficient data handling, encouraging optimized aggregate queries for large-scale analysis. The system supports result sharing through embeddable charts, with ownership verification through wallet integration.

<figure><img src="/files/EuYlWQVnwl5GFQQE18Ga" alt=""><figcaption></figcaption></figure>

### Performance Optimization

Performance optimization occurs at multiple levels throughout the system. Query execution implements parallel processing where possible, while the caching layer minimizes redundant computations. The system employs intelligent query planning and resource allocation, ensuring efficient utilization of computational resources.

### Cloud Integration & Data Flow

Pythia's integration with Openmesh Cloud enables distributed query execution and data access. The system leverages Cloud resources for computation-intensive operations while maintaining data locality for frequently accessed information. Real-time data streams from the API layer flow through Cloud infrastructure before reaching Pythia's visualization components.

Data transformation occurs at multiple stages:

1. Initial ingestion from Openmesh API sources
2. Intermediate processing for analytics optimization
3. Final preparation for visualization and export

### Future Development

The development roadmap encompasses several key areas for enhancement. Multi-blockchain data coverage expansion will enable cross-chain analytics capabilities. Complete trading history implementation will provide comprehensive historical analysis capabilities. Public key encryption for queries and results will enhance security and privacy.

Community engagement remains central to development, with planned support for community-created visualizations and enhanced customization capabilities. Integration with Openmesh Cloud will deepen, enabling more sophisticated distributed analytics capabilities while maintaining the platform's accessibility and performance.


# Integrations


# Chainlink CCIP

Openmesh has successfully integrated Chainlink CCIP and Chainlink Data Feeds directly into its Decentralized Cloud infrastructure, enabling developers to build and deploy highly decentralized applications with advanced cross-chain capabilities. This integration significantly expands the toolset available for creating robust, interoperable Web3 services that can seamlessly operate across multiple blockchain networks.

<figure><img src="/files/1wPpZMAS2R96EtSb3QQo" alt=""><figcaption></figcaption></figure>

### Significance of the Openmesh x Chainlink CCIP Integration

Research involving hundreds of Web3 startups reveals a critical infrastructure gap: despite building with Chainlink technologies (CCIP and streaming services), many developers default to centralized cloud providers like AWS or GCP due to existing tooling and familiarity.

The Openmesh x Chainlink integration provides developers with a complete technical stack for building truly decentralized Web3 services. This integration addresses core technical challenges in cross-chain communication infrastructure, full-stack decentralization, and developer-focused deployment architecture. By combining cross-chain message and token transfer capabilities with decentralized infrastructure deployment, developers can build scalable Web3 applications that directly leverage Chainlink's oracle networks.

### Web2 vs. Web3 Infrastructure: Key Differences

#### Traditional Cloud

Web2 infrastructure forces developers into centralized constraints: KYC requirements, fiat-only payments, country-specific deployments, and complex certificate management. Your application's security and availability depend entirely on the cloud provider's closed-source infrastructure, potential backdoors, and corporate policies.

#### Openmesh

Built for Web3 developers from the ground up. Deploy with just an Ethereum wallet - no KYC, no borders, no certificates. Security is anchored to Ethereum consensus, making your applications resistant to censorship or unauthorized access. Native CCIP integration enables true cross-chain functionality, while open-source infrastructure and DAO governance ensure transparency and community control. Users maintain full ownership of their deployments with a simplified interface suitable for both technical and non-technical users. All this at 80% lower cost than traditional cloud providers.

### Integration Goals

* **Simplified CCIP Implementation**: Deploy production-ready Chainlink integrations in minutes. As your infrastructure provider, we handle the complex off-chain setup - from website hosting to database management - letting you focus on building your dApp's core functionality.
* **True Decentralization**: Break free from centralized hosting risks. Self-hosted web interfaces mean your dApp remains accessible and secure even if individual actors are compromised. No single point of failure, no central authority, no backdoors - just the same decentralization guarantees as your smart contracts.

<figure><img src="/files/n63AuabBxfuHaF0aZ9jn" alt=""><figcaption></figcaption></figure>

### What is Chainlink CCIP?

Chainlink CCIP is your secure bridge for cross-chain development, enabling three core capabilities:

* **Arbitrary Messaging**: Send encoded data across chains to trigger smart contract actions - from rebalancing indexes to orchestrating complex multi-chain operations.
* **Token Transfers**: Move tokens seamlessly between chains, supporting both smart contracts and EOAs, with built-in rate limiting and security checks.
* **Programmable Token Transfers**: Combine data and token transfers in a single transaction. For example, transfer tokens to a lending protocol while simultaneously instructing it to use them as collateral.

<figure><img src="/files/TWK7HnHDLp60lkxVGi3G" alt=""><figcaption></figcaption></figure>

### Why it Matters for Developers

Traditional cross-chain development requires building separate implementations for each blockchain interaction - complex, time-consuming, and risky. CCIP provides a single, secure middleware solution with defense-in-depth security, powered by Chainlink's oracle networks that secure $14T+ in transaction value.

{% hint style="info" %}
For detailed implementation guides, security features, and network configurations, visit the [Chainlink CCIP Documentation](https://docs.chain.link/ccip).
{% endhint %}

### Integration Demo: CCIP-Enabled Xnode Template

Our ready-to-deploy NextJS template demonstrates CCIP integration with two key features:

* **Price Feed Dashboard**:
  * Real-time crypto prices via Chainlink Data Feeds
  * Customizable token selection
  * Multi-currency conversion support
  * Similar to CoinMarketCap/CoinGecko, but trustless
* **CCIP Transaction Monitor**:
  * Track cross-chain messages on Ethereum mainnet
  * View complete transaction details:
    * Source/destination chains and addresses
    * Token transfers
    * Message data
    * Gas metrics

{% hint style="info" %}
Deploy this template to your Xnode for instant access to decentralized price feeds and CCIP monitoring. [Checkout the tutorial here!](https://docs.openmesh.network/products/xnode/template-deployment-guides/deploy-a-chainlink-data-dashboard)
{% endhint %}

### Potential Use Cases

The Openmesh x Chainlink CCIP integration enables developers to build sophisticated cross-chain applications while maintaining true decentralization. Through our infrastructure, teams can deploy complex systems that were previously impossible or required significant centralized components.

Infrastructure applications range from decentralized data services to cross-chain orchestration systems. Teams are building true decentralized data infrastructure with real-time markets, while others implement hybrid cloud services that bridge traditional and Web3 architectures.

Key development areas include:

* **Cross-chain dApp Deployment and Composability**: Deploy Web3 applications that seamlessly interact across multiple chains. Build composable systems where smart contracts on different networks can communicate and execute complex operations through CCIP.
* **Cross-chain Cloud Resource Sharing**: Enable dynamic resource allocation across different blockchain networks. Deploy compute and storage resources where needed, with automated provisioning and cross-chain payment settlement.
* **Decentralized AI and Predictive Analytics**: Create AI models that process cross-chain data through decentralized infrastructure. Deploy prediction markets and analytics engines that aggregate data from multiple blockchain networks for real-time analysis.
* **Multi-chain DAO Operations**: Build governance systems that span multiple chains, enabling DAOs to execute decisions across different networks. Implement voting mechanisms that aggregate results from various chains while maintaining security and transparency.
* **Web3-native Financial Instruments**: Deploy DeFi applications that leverage cross-chain liquidity and price feeds. Create sophisticated financial products that can access and move assets across multiple networks through secure CCIP bridges.
* **Decentralized Media Distribution**: Build content delivery networks that span multiple chains, enabling efficient distribution of media assets with cross-chain monetization and access control.
* **Cross-chain NFT and Gaming**: Create unified marketplaces where digital assets trade seamlessly across networks. Build gaming ecosystems with cross-chain asset portability and verifiable ownership tracking.

Each use case benefits from our integrated approach to decentralization, combining Chainlink's secure cross-chain messaging with Openmesh's infrastructure capabilities. Whether you're building decentralized identity solutions or creating new token economies, the integration provides the necessary tools while maintaining security and decentralization.

<figure><img src="/files/o2mJuUF5V5BEmYvTJWLY" alt=""><figcaption></figcaption></figure>

### Deploy this CCIP Xnode Studio template to your DVM now! <br>

Deploy from the [Xnode Studio App Store](https://docs.openmesh.network/products/xnode/xnode-studio) using a [Getting Started](https://docs.openmesh.network/products/xnode/getting-started-guides) tutorial:

* [Deploy your own Chainlink Price Feed & CCIP Data Dashboard](https://docs.openmesh.network/products/xnode/template-deployment-guides/deploy-a-chainlink-data-dashboard)


# Contributions

The Openmesh project is dedicated to free and open source software that anybody can contribute to, if you intend on contributing to our software please ensure you understand the vision and purpose of the component that you are modifying.&#x20;

Openmesh provides several pathways for contributing to the project:

* Running infrastructure for the network as an Xnode operator
* Validating data in the network as an Openmesh Validator
* Joining Circle to discuss the project and wider web3 topics
* Taking tasks on OpenR\&D and making a paid contribution to the project
* Opening issues on github requesting a feature or reporting a bug
* Volunteering code contributions through forking and pull-requesting new features or fixes
* Becoming a Verified Contributor and taking part in the Openmesh governance process


# OpenR\&D

{% hint style="info" %}
OpenR\&D Homepage:[ ](https://deeplink-frontend-dao.vercel.app/tasks)<https://openrd.openmesh.network/>
{% endhint %}

### Vision <a href="#vision" id="vision"></a>

<figure><img src="/files/unN9LWnnhk578ZcUBHI8" alt=""><figcaption></figcaption></figure>

Learn about the history of how OpenR\&D started and find out what OpenR\&D aims to achieve [here](/open-source-initiatives/openr-and-d/vision)

### Getting Started <a href="#getting-started" id="getting-started"></a>

Let's jump right in and discover how you can start contributing to the platform! Either as a [task creator](/open-source-initiatives/openr-and-d/getting-started/creating-tasks) or [task performer](/open-source-initiatives/openr-and-d/getting-started/perform-tasks).

### Technical <a href="#technical" id="technical"></a>

Explore the architecture of OpenR\&D, including our smart contract modules and backend services. Find out more in the [technical](https://open-mesh.gitbook.io/l3a-dao-documentation/technical/smart-contracts) segment of this documentation


# Vision

To reach scalable innovation in distributed engineering

OpenR\&D is proud to be one of the pioneers of R\&D platforms in Web3. We are empowering developers, engineers, and DAOs to improve the developer experience and project management through a truly decentralized R\&D platform built for scalable innovation in distributed engineering.

> #### Our vision is to empower Web3 projects and teams to collaborate seamlessly <a href="#our-vision-is-to-empower-web3-projects-and-teams-to-collaborate-seamlessly" id="our-vision-is-to-empower-web3-projects-and-teams-to-collaborate-seamlessly"></a>

OpenR\&D enables information to flow freely, enabling efficient project management and distribution of work. We are committed to making development and payment more open, transparent, and accessible for everybody.

[<br>](https://open-mesh.gitbook.io/l3a-dao-documentation)


# Problem Statement & Innovation

### Addressing pain points in Open Source and DAOs <a href="#addressing-pain-points-in-open-source-and-daos" id="addressing-pain-points-in-open-source-and-daos"></a>

Open-source communities have a variety of problems when it comes to development and coordination. Challenges exist when holding contributors accountable and adhering to any sort of law. By implementing a DAO structure, core teams are able to assemble and create a structure that enables them to become the final decision-makers for a variety of responsibilities.

However, we need an environment to leverage developer experiences where developers can perform better while maintaining truly decentralized governance. These are issues that we specifically addressed with our R\&D development portal. We aim to improve the developer experience while maintaining some control of the development and introduce mechanisms to incentivize proper behavior and developer empowerment. Importantly, we wanted this portal to scale as we do, and not limit our ability to grow or be agile.

***

### Empowering developers and engineers <a href="#empowering-developers-and-engineers" id="empowering-developers-and-engineers"></a>

Empowering developers is crucial to scaling engineering. There are a variety of obstacles within centralized businesses that prohibit developers from owning their work and sharing it. Using a platform like ours, developers will have a more liberating experience that provides access to task lists with complete transparency.

***

#### DAO friendly <a href="#dao-friendly" id="dao-friendly"></a>

OpenR\&D supports the usage of [Decentralized Autonomous Organization](https://ethereum.org/en/dao/) (DAO); an entity structure with no central authority which is governed by the community members. Members of the DAO, who own community tokens, can vote on initiatives for the entity. The smart contracts and code governing the DAO's operations is publicly disclosed and available for everyone to see.

<br>


# Task progression

A task can progress from start to finish in multiple ways listed bellow. Every step is prefixed with the entity that is required to perform this action. Steps prefixed with \* are optional.

### Successful completion <a href="#successful-completion" id="successful-completion"></a>

1. Task manager: The task is created.
2. Applicant: One of multiple applications are made.
3. Task manager: One or multiple applications are accepted.
4. Applicant: One of the accepted applicants takes the task.
5. Applicant: Finishes the task and creates a submission.
6. Task manager: Reviews the submission and accepts it.
7. The reward will paid out by the smart contract automatically. Any leftover budget will be returned to the task funder. The task is closed.

### Deadline passed <a href="#deadline-passed" id="deadline-passed"></a>

1. Task manager: The task is created.
2. Applicant: One of multiple applications are made.
3. Task manager: One or multiple applications are accepted.
4. Applicant: One of the accepted applicants takes the task.
5. \*Applicant: Creates a submission that gets rejected or not reviewed by the task manager.
6. \*Applicant: Creates a dispute that gets rejected or not reviewed by the dispute manager.
7. The deadline passes.
8. Task manager: Cancels the task, this does not require a confirmation from the executor anymore as the deadline has passed. All funds are returned to the task funder. The task is closed.

### Completed by dispute <a href="#completed-by-dispute" id="completed-by-dispute"></a>

1. Task manager: The task is created.
2. Applicant: One of multiple applications are made.
3. Task manager: One or multiple applications are accepted.
4. Applicant: One of the accepted applicants takes the task.
5. Applicant: Creates a submission that gets rejected or not reviewed by the task manager.
6. Applicant: Creates a dispute.
7. Dispute manager: Reviews the dispute and accepts it.
8. The (partial) reward will paid out by the smart contract automatically. Any leftover budget will be returned to the task funder. The task is closed.

### Early cancellation <a href="#early-cancellation" id="early-cancellation"></a>

1. Task manager: The task is created.
2. Applicant: One of multiple applications are made.
3. Task manager: One or multiple applications are accepted, but none of them take the task.
4. Task manager: Cancels the task, this does not require a confirmation from the executor as there is none yet. All funds are returned to the task funder. The task is closed.

### Agreed cancellation <a href="#agreed-cancellation" id="agreed-cancellation"></a>

1. Task manager: The task is created.
2. Applicant: One of multiple applications are made.
3. Task manager: One or multiple applications are accepted.
4. Applicant: One of the accepted applicants takes the task.
5. Task manager: Tries to cancel the task, this will put in a request for the executor to review.
6. Applicant: Accepts cancelation request.
7. All funds are returned to the task funder. The task is closed.


# Supported Chains

## Supported chains

OpenR\&D is deployed on the following chains: (\* are testnets) Its address is also registered under [openrd.openmesh-network.eth](https://app.ens.domains/openrd.openmesh-network.eth)

| Chain              | Address                                    |
| ------------------ | ------------------------------------------ |
| Ethereum           | 0xDdb23dacd41908C4eAE03982B1c6529252A56b62 |
| Polygon            | 0xDdb23dacd41908C4eAE03982B1c6529252A56b62 |
| Sepolia\*          | 0xDdb23dacd41908C4eAE03982B1c6529252A56b62 |
| Arbitrum Sepolia\* | 0xDdb23dacd41908C4eAE03982B1c6529252A56b62 |

OpenR\&D extensions are deployed on the following chains:

| Extension         | Chain              | Address                                    |
| ----------------- | ------------------ | ------------------------------------------ |
| RFPs              | Ethereum           | 0x9687C4dcBf62f6D8400c17A3ec545C70b1a50A20 |
| RFPs              | Polygon            | 0x9687C4dcBf62f6D8400c17A3ec545C70b1a50A20 |
| RFPs              | Sepolia\*          | 0x9687C4dcBf62f6D8400c17A3ec545C70b1a50A20 |
| RFPs              | Arbitrum Sepolia\* | 0x9687C4dcBf62f6D8400c17A3ec545C70b1a50A20 |
| Dispute Proposals | Ethereum           | 0x945E13855cC61F33373Ec7D42eD30D800A832377 |
| Dispute Proposals | Polygon            | 0x945E13855cC61F33373Ec7D42eD30D800A832377 |
| Dispute Proposals | Sepolia\*          | 0x945E13855cC61F33373Ec7D42eD30D800A832377 |
| Dispute Proposals | Arbitrum Sepolia\* | 0x945E13855cC61F33373Ec7D42eD30D800A832377 |
| Draft Proposals   | Ethereum           | 0x1DC2017f07a1996dA3F093c11570dE038088DCa4 |
| Draft Proposals   | Polygon            | 0x1DC2017f07a1996dA3F093c11570dE038088DCa4 |
| Draft Proposals   | Sepolia\*          | 0x1DC2017f07a1996dA3F093c11570dE038088DCa4 |
| Draft Proposals   | Arbitrum Sepolia\* | 0x1DC2017f07a1996dA3F093c11570dE038088DCa4 |

Anyone is able to deploy these contracts to the same address on other EVM chains using the CREATE2 factory located at [0x4e59b44847b379578588920ca78fbf26c0b4956c](https://github.com/Arachnid/deterministic-deployment-proxy) with the salt OPENMESH. The bytecode and source code can be found [here](https://github.com/Plopmenz/openrd-foundry). Do note that interacting with it through the web interface will require you to run your own forked version of the [OpenR\&D indexer](https://github.com/Plopmenz/openrd-indexer) and [OpenR\&D frontend](https://github.com/Plopmenz/openrd-frontend) with the new chain.


# Glossary

{% hint style="info" %}
Entity is used as a way to refer to a blockchain address. This could be a single person or a group (utilizing a multisig or DAO).
{% endhint %}

**Task** A single item on OpenR\&D that includes a budget and description. It can have multiple (accepted) applicants, but only 1 executor. It can have multiple submissions, but only 1 accepted submission. This could be a longer-term job listing or a one-time job. It could be anything, from software development to feeding your neighbour's cat.

**Task funder** The entity that has funded the initial budget of the task. This is usually also the creator of the task.

**Task manager** The entity that will perform the management operations. Every task has a single task manager. Usually, this is the funder of the task, but in special cases, it makes sense to give this power to someone else.

**Task state** A task can be either Open, Ongoing, or Closed. An Open task does not have an executor yet and allows new applications. A taken task does have an executor, will not allow application, but will allow submissions. A closed task does not allow any interactions, as it has finished.

**Applicant** An entity that is willing to perform a task for a certain reward. They apply and specify the desired reward on a per-task basis. The asked reward can be higher than the task budget and can include payouts to several different entities, although usually it will be only to the applicant. Their application can be accepted by the task manager, but if their asked reward exceeds the budget, the manager will need to increase the budget to be equal or greater first. Any accepted applicant can take the task to become the executor, this action is irreversible and on a first come first serve basis.

**Executor** An entity that is chosen to perform the task. They are the only entity that can create submissions.

**Submission** A declaration from the executor that they believe the task has been completed. Alternatively, you could view this as a request for the reward to be released and the task to be closed. A submission includes an explanation on why they think the task has been completed, which usually includes where to find the deliverables (if any). The task manager will review this submission and either accept or reject it. Acceptance will close the task and release the reward, where any leftover budget will be sent back to the task funder's wallet. In case of rejection, no action will be performed. When reviewing the task manager is required to provide an explanation on why this decision has been made.

**Dispute manager** The entity that will handle any disputes related to the task. This dispute manager is chosen by the task creator. In case the executor and task manager cannot reach an agreement on whether the task has been completed, the executor is able to create a request to the dispute manager to look into the case and provide their judgment. This request does cost a fee, which is set by the dispute manager, to compensate them for their resources spend on reviewing the case. The executor can also specify how much of the reward they think they should receive (in case they agree they did not complete the task completely, but do think they should receive more than the task manager is offering them). If the dispute manager decides in favor of the executor, the (partial) reward will be paid out and the task will be closed. Any leftover budget will be refunded to the task funder, similar to completing the task normally. The dispute manager protects against malicious or unfair task managers. Every dispute manager can choose their way of deciding on disputes, although we would recommend using a decentralized process. Openmesh provides a dispute manager, but task creators are free to pick any other one they prefer. Similarly, anyone is free to start their own dispute management service.


# Contact Us

## Contact Us

As an open-source platform, we're here to listen and assist. If you have any questions, suggestions, or feedback, please don't hesitate to get in touch with us at <engineering@openmesh.network>.

For any items related to community decisions, we'd recommend posting about it on Circle: <https://circle.openmesh.network/>.

Otherwise, follow our socials to get the latest updates!


# Verified Contributors

### Verified Contributors

OpenR\&D is open to anyone to use. Verified Contributors is Openmesh's way of using OpenR\&D to develop its products. Verified Contributors form a DAO which decides who is part of it. This Verified Contributor status is represented by an NFT (ERC721). The Verified Contributors decide who gets minted this NFT and can similarly also decide if it should be revoked from someone.

This Verified Contributor group gets extra OPEN token rewards for completing tasks based on RFM (Recency, Frequency, Monetary value). Furthermore, there are several departments, which contain a subset of Verified Contributors. Normal Verified Contributors work on a task-by-task payment schedule, whereas Verified Contributors part of a department are instead working on a fixed salary, where the task completion reward is paid out to the department treasury instead. This allows them to have a more predictable income.

### **How to become a Verified Contributor?**

Becoming a Verified Contributor is currently invite-only.

### **What are the responsibilities of a Verified Contributor?**

Being a Verified Contributor you are expected to interact with the OpenR\&D platform or community regularly. Usually, this will be in the form of completing tasks, which will be represented in your RFM score. Being in a department will introduce more responsibilities, which that department decides.

### **How do we avoid bad actors?**

When a Verified Contributor fails to fulfill their responsibility, they are held accountable by the other Verified Contributors, who will cast a vote to burn the bad actor's NFT, meaning they will lose the additional benefits and governance that is granted to it. This also means that they are removed from any department they are part of.

{% hint style="info" %}
The Verified Contributor NFT collection and DAOs exist on Polygon mainnet.[<br>](https://open-mesh.gitbook.io/l3a-dao-documentation/about/openr-and-d/contact-us)
{% endhint %}


# OVC DAO

As this DAO decides who has the Verified Contributor status, which is required to enter a department, it can be seen as "Department Owner".

This is the only responsibility of this DAO, managing the group of verified contributors by adding any new promising candidates and removing those that aren't involved enough, abusing the system, or any other kind of harm is done to the Verified Contributors by keeping them.

## Optimistic actions

As adding Verified Contributors is not a very harmful action and it is expected to be done regularly, this can be done optimistically. This means that an existing Verified Contributor creates the action to mint a new NFT to a promising candidate, explaining why they made this choice. All other Verified Contributors will then have 7 days to review this action and in case they do not agree, the opportunity to reject it. Only a single rejection is required to prevent the action from happening.

In case someone creates suspicious actions or is rejecting actions without good reason, this could be a reason to remove their Verified Contributor status. It is recommended to mention it to them beforehand before taking this last resort.

## Voting actions

Any other actions will need at least 20% of all Verified Contributors to vote on it and the majority (>50%) to approve it.&#x20;

The only action that is expected is the burning of NFTs. Any Verified Contributor who knows they will stop interacting with the platform can also burn their NFT themselves, to save the DAO the hassle of voting.

The Verified Contributors are in complete control of this DAO, so they can decide on any other actions they want to perform, such as building up a treasury.


# Departments

Departments are subsets of Verified Contributors, where each department has its own "tag" (e.g. DISPUTE for the dispute department and EXPERT for the expert department). These tags can be applied to and removed from any Verified Contributor NFT by the department itself, allowing the department to pick its own members, with the restriction that they hold a Verified Contributor NFT.

The department owner, the DAO formed by all Verified Contributors, holds the permission to manage these tags, allowing or revoking a certain address from being able to grant a certain tag. Hence creating and removing a department is done by a proposal in the department owner DAO. The smart contracts required to be deployed for the new department can be found [here](https://github.com/Openmesh-Network/openmesh-department).

## Payments

Departments provide the opportunity to complete tasks as a group and pay all members a fixed salary. For this to be sustainable, the department members should earn more together than the combined salary. Having a consistent income is preferred by most people and will allow members to work on bigger tasks without having to worry about their monthly expenses.

Most of the departments will mainly be taking tasks related to Openmesh products, for example, the technical departments would be requested to implement new features. These requests are expected to mostly come from the Openmesh community DAO (governed by OPEN token holders), but other entities that have an interest in having these features developed can also create such tasks.

## Optimistic actions

Similar to the optimistic actions of the [department owner](/open-source-initiatives/openr-and-d/verified-contributors/ovc-dao), a department member can perform a certain action if no department member rejects it within 7 days. For departments, these actions are limited to interactions with the OpenR\&D smart contract (based on address).

Department members are recommended to have an OpenR\&D task with their department to handle their payments. This task should hold enough funding for at least 1 payout, in case they did their work but the department refuses to pay them. For this to be possible, the task should clearly describe what they are expected to do. They can then make use of dispute resolution to still get their payment. As payments, top-ups, and deadline extensions related to managing these members are regular occurrences, they can be done optimistically.&#x20;

## Voting actions

Any other actions will need at least 20% of all department members to vote on it and the majority (>50%) to approve it. In case the NFT of a department member has been burned, the tagging contract needs to be made aware to update the total department members for this threshold to be 20%.

The only action that is expected is the granting and revoking of their tag, to add or remove department members.

The department members are in complete control of this DAO, so they can decide on any other actions they want to perform. They are also able to change the governance thresholds or add more optimistic actions if they prefer.

## [Crosschain account](https://github.com/Plopmenz/crosschain-account)

Using [Chainlink CCIP](https://docs.chain.link/ccip) we have a smart contract on Ethereum for the department (which are deployed on Polygon). This allows them to actually take tasks of the Openmesh community DAO (which is deployed on Ethereum) and hold assets which do not exist on Polygon. They can also use any Ethereum dApps this way, paying Polygon gas fees for governance and only the Ethereum gas fee once for actually executing the action.

## [Smart account](https://github.com/Plopmenz/smart-account)

The departments all have a smart account for a deterministic address across chains (controlled by the DAO on Polygon and controlled by the crosschain account on Ethereum). This smart account holds all funds and permissions to be able to easily change the way it is controlled (for example, if we wish to change DAO platform in the future, allows us to keep the same address, permissions, and assets). This smart account also supports "modules" to extend it.


# Dispute Department

The dispute department is responsible for handling OpenR\&D disputes. This is the default dispute manager we will recommend from Openmesh, although the task creator is free to pick any they prefer, and we'd be happy for other dispute providers to be created.

The difference with a normal department is that the smart account has installed the [OpenR\&D dispute proposals extension](https://github.com/Openmesh-Network/openrd-dao-extensions). This is done on both its Polygon and Ethereum smart account, to allow it to resolve disputes on both.

Furthermore, this department will receive its funding from the dispute fees. Depending on the consistency of these requests, this could mean that this department will choose to compensate its members based on the frequency of these requests instead of a salary.


# Expert Department

The dispute department is responsible for helping other entities integrate Openmesh products. You could compare them to consultants. They will not work on developing the Openmesh products but will advise or customize them to the needs of a certain entity.

The members of this department are experienced with Openmesh products and can thus answer questions much more efficiently than if an outside entity without this knowledge wants to know something. As all our products are open source and created in such a way that they provide value to not just Openmesh, it is to be expected that these entities will present themselves. Having the expert department ready to assist them will improve adoption and increase integration speed and quality.

This department does not have any smart contract changes compared to other departments but will receive its funding mainly from other entities. Depending on the consistency of these requests, this could mean that this department will choose to compensate its members based on the frequency of these requests instead of a salary. The Openmesh community DAO can choose to create tasks for the expert department to keep their knowledge up to date in case funding from other sources is not sufficient to justify it.


# Getting Started


# Creating Tasks


# Create a Task

{% embed url="<https://drive.google.com/file/d/1IDEAt1YXtbTe6fRnW-1qF5MB0bGxYlzW/view?usp=sharing>" %}

In the OpenR\&D platform, tasks can be created by anyone and can be completed by anyone, if their application is accepted. All tasks will be displayed on the OpenR\&D homepage.

![](https://open-mesh.gitbook.io/~gitbook/image?url=https%3A%2F%2F1957194339-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F6ALxkPYXstkjVdL9Duqf%252Fuploads%252Fc1Np5ENla95v6K4EkARH%252Fimage.png%3Falt%3Dmedia%26token%3D9ba6133a-92cc-4593-a188-03863dcbb938\&width=768\&dpr=4\&quality=100\&sign=129b2243\&sv=1)The different stages of projects

In case the project is not just beneficial to yourself, but the whole ecosystem, you can also request it to be funded by one of our departments. These projects are created to help advance the development of the protocol.

***

### **What are the task statuses?**

* <mark style="color:red;">Draft</mark> - These tasks are requested to be funded and are awaiting approval.
* <mark style="color:green;">**Open**</mark> - These tasks have been funded and are open for application.
* <mark style="color:blue;">**Active**</mark> - The tasks have an executor and are actively being worked on.
* **Completed** - These tasks are finished, either by completion (an accepted submission), by dispute or by cancelation.

***

### How to create a task? <a href="#how-to-create-a-task" id="how-to-create-a-task"></a>

1. [Connect your wallet.](/open-source-initiatives/openr-and-d/getting-started/creating-tasks/create-a-task/connect-wallet)
2. Look for the "Add a Project" button on the "Tasks" page, which you can find in the top bar.
3. Enter all the fields in the form and hit the create button.
4. Sign the transaction with your wallet.

{% hint style="info" %}
**What are the task budgets?**

Every task will have a clear budget allocated as a suggested maximum reward for completion. The budget is set in units of cryptocurrencies of your choice, including stablecoins (any ERC20 or native currency). These funds will be held in an escrow smart contract, to make sure executor is able to get their reward if they finish the task. Applicants can only apply for a reward in the currencies you specified in the budget, although their reward can be lower or higher than the budget. To accept an application with a reward higher than the current budget, you will need to increase the budget to at least this amount first. If a task fails to be completed or is canceled, the full budget will be returned to the task funder. In case the task is completed, but the full reward was not asked by the applicant, the leftover budget is returned to the task funder.
{% endhint %}

{% hint style="info" %}
**How to decide on project duration, team size, and deadline?**

The project duration and team size are a reference to improve the clarity between the task creator and applicants. They are only meant as guidelines to understand the task. Project duration is an expectation of how many hours the task will take and team size is an expectation on how many different skills are required. Deadline is the date from which the task manager can cancel the task freely without having to pay anything to the executor. The executor should always aim to finish the project well before this, so there is time to go through the dispute resolution if needed. After the deadline it is not mandatory to cancel the task, the task manager can still accept a submission to complete the task normally. The task manager is recommended to extend the deadline if they are planning on doing so, as the executor has no guarantees of payment after this date has passed.
{% endhint %}

{% hint style="info" %}
**Preapproved applicants**

In the case where you have already decided on the executor who will take on the project, you will be able to add their wallet addresses in the project creation form along with their reward. This will save in gas costs and improve user experience by not needing them to create an applicantion and you to accept it. Instead an empty acecpted applicant is created for them, so they can take the task right away.
{% endhint %}


# Connect Wallet

{% embed url="<https://drive.google.com/file/d/1zg1UGl8jVPAmdp30f9cThlbGAyQ1WsJ2/view?usp=sharing>" %}

As a first step to participate in the protocol, you have to connect to your wallet to be able to edit your profile and apply for projects.

Connecting a crypto wallet is an essential step for securely managing and accessing your account. Whether you're new to cryptocurrencies or an experienced user, this step-by-step guide will walk you through the process of connecting your crypto wallet.

1. Download any web3 wallet or use an existing supported social account
2. Click the "Connect Wallet" button on the top right of the page and select your wallet
3. Accept the connection
4. When successfully connected, the wallet address should be shown in the original button on the top right of the page


# Accept an application

## Accept an application

After your task has been created, people can apply to your task. It is your (the task manager) responsibility to accept anyone you think is able to complete the task. If you have a preference for certain applicants, you can accept them earlier, and wait to see if they take the task (confirm they still want it, after which they will immediately start working). You can accept as many applications as you want in as many separate waves as you want.

### How to accept an application? <a href="#how-to-accept-an-application" id="how-to-accept-an-application"></a>

1. Go to the view task page.
2. Head to the "applications" tab, where you can view the list of current applications.
3. Review each application carefully, considering the applicant's profile, past jobs, proposed reward, plan of approach, and background.
4. If you wish, you can directly contact some of the applicants through their linked socials on their profile to further assess their suitability for the project.
5. Click "Approve" if you think the applicant is a good fit for the project
6. You can repeat these steps as often as you want, in case none of the applications are sufficient, you can consider waiting for more applications, possibly extending the deadline, or increasing the budget, or canceling the task.
7. It is recommended to keep in touch with the executor (applicant who will perform the task) throughout the project to ensure your expectations of the deliverables align.


# Review a submission

{% embed url="<https://drive.google.com/file/d/1n6zs0nMPWXgc4PUCJEhlRcH5JlSBF0kI/view?usp=sharing>" %}

Once the executor believes they have completed the task, they will create a submission for the task manager to review. If they agree, the task is successfully completed, the reward will be released to the executor automatically through the smart contracts. Any leftover budget will be sent back to the task funder.

If you reject a submission, nothing will happen. In case your rejection and explanation is not fair, the executor can open a dispute and still receive their reward if the dispute manager agrees.

### How to review a submission? <a href="#how-to-review-a-submission" id="how-to-review-a-submission"></a>

1. Go to the view task page.
2. Head to the "submissions" tab, where you can view the list of current submissions.
3. Review the last submission carefully, verifying all deliverables.
4. Fill out the form below the submission.
5. Press the review button and sign the transaction.

{% hint style="info" %}
What if there are multiple open submissions? Usually, this means that the executor has revised or improved their submissions, in which case you just review the last one. There are no consequences for not reviewing a submission, except that it could be used in dispute resolution (ignoring a valid submission could be seen as trying to get closer to the deadline and prevent payout).
{% endhint %}

{% hint style="info" %}
What if a dispute arises? Find out about our [dispute resolution](/open-source-initiatives/openr-and-d/getting-started/perform-tasks/dispute-resolution) mechanism

{% endhint %}


# Additional management

{% embed url="<https://drive.google.com/file/d/1odrqf6Tt-33EGbJ6sJRHENLcibzBTP8a/view?usp=sharing>" %}

{% embed url="<https://drive.google.com/file/d/1kON1xtbbjUBElSS9qOZWKjgEo9UxfYbT/view?usp=sharing>" %}

As the task manager you have a few more actions you can perform. You can find these in the "manage" tab on the view task page.

### Edit metadata <a href="#edit-metadata" id="edit-metadata"></a>

This will allow you to change task information fields.

{% hint style="info" %}
This can only be done while the task is still open. This option is not available on active tasks.
{% endhint %}

### Extend deadline <a href="#extend-deadline" id="extend-deadline"></a>

This will allow you to postpone the deadline date.

{% hint style="info" %}
It is not possible to make the deadline date earlier.
{% endhint %}

### Increase budget <a href="#increase-budget" id="increase-budget"></a>

This will allow you to increase the task budget. Both native and ERC20 budget can be increased.

{% hint style="info" %}
It is not possible to decrease the budget.
{% endhint %}

### Cancel task <a href="#cancel-task" id="cancel-task"></a>

This will allow you to close the task and refund the budget to the task funder.

{% hint style="info" %}
If the task is active, this will create a request that requires the executor to accept it before the task is canceled.
{% endhint %}


# Perform Tasks


# Apply to task

{% embed url="<https://drive.google.com/file/d/1bunbEQpsN2PuNuB2Ea8khFyFKikn7j-W/view?usp=sharing>" %}

### **Who can be an applicant?**

Any user that has connected their wallet can apply for tasks.

{% hint style="info" %}
Tasks can have application requirements, such as holding a certain amount of a token.
{% endhint %}

### **What reward do I earn after completing a task?**

You can set your own desired reward for completing the task. It is recommended to stay under the budget of the task. After the task manager confirms that you have finished the task, or if you create a dispute which is accepted, the reward will be sent to your wallet automatically.

***

### How to apply to a task? <a href="#how-to-apply-to-a-task" id="how-to-apply-to-a-task"></a>

Create a compelling application for every project to increase your likelihood of being accepted to take the task.

1. You are recommended to [set up your profile](/open-source-initiatives/openr-and-d/getting-started/perform-tasks/apply-to-task/edit-profile) before applying to tasks.
2. Browse through open tasks in the task list under "Tasks" in the navigation bar.
3. If you find an interesting task, press "view task" to see more details.
4. If you want to take the task on, go to the "applications" tab and fill out the form at the bottom of the page.
5. Click the create button and sign the transaction with your wallet.

{% hint style="info" %}
Note: Proposing a lower amount than budget in each task shows that you will be able to complete the task in a more cost-effective manner.

However, if you believe that the available funding is not sufficient, you can request a higher amount. This will require the task manager to increase the budget before they can accept your application.
{% endhint %}

{% hint style="info" %}
Make sure to verify the dispute manager before accepting to take on a task. In case the dispute manager colludes with the task manager, they can prevent you from getting your reward, even if you completed the task.

In general, we recommend only taking tasks with dispute managers you are familiar with (such as the Openmesh dispute department) or you trust the task manager enough to pay the reward.

As a trustless protocol, Openmesh cannot help you with any tasks that do not use our dispute management.
{% endhint %}


# Edit Profile

{% embed url="<https://drive.google.com/file/d/10ptJgIuROA2iM69px_NzNOPX1V36tJNZ/view?usp=sharing>" %}

Editing your profile will allow other contributors to see your identity and contributions in the platform. As a user, you will have the option to add display names, tags, and social links.

### **Editing your profile**

1. Once your [wallet is connected](/open-source-initiatives/openr-and-d/getting-started/creating-tasks/create-a-task/connect-wallet), click the "My Profile" tab in the navigation bar to access your personal profile page
2. On your profile page, click on the "Edit Profile" option to open up the editing view
3. Update the fields you want to change
4. Click on the "Edit Profile" button to save your edited profile information
5. You will be required to sign a message with your wallet to confirm the changes


# Take a task

{% embed url="<https://drive.google.com/file/d/1h2dEJ7-aRTa1QWQyMWW395F2_FXbVokW/view?usp=sharing>" %}

After the task manager has accepted your application, you have the option to take the task. If you decide to take the task, you cannot back out freely. In case you do not complete the task, this will be shown in the statistics on your profile.

After you have taken the task you can start working on it. Cancelling the task will require both your and the task manager's confirmation from here on.

{% hint style="info" %}
Task taking is done on a first come first serve basis. If you wait too long to take the task, it is possible that someone else will do it before you.
{% endhint %}

### How to take a task? <a href="#how-to-take-a-task" id="how-to-take-a-task"></a>

1. Go to the view task page.
2. Head to the "applications" tab, where you will find your accepted application.
3. Click the take task button and sign the transaction with your wallet.


# Create a submission

{% embed url="<https://drive.google.com/file/d/1N3s_Eg8IIYwjNHXenMKDyhtoQsdpvJch/view?usp=sharing>" %}

After you believe you have done everything that the task requires of you, you can create a submission. This is essentially a report with your deliverables for the task manager to review. It can also be one of the deciding factors for [dispute resolution](/open-source-initiatives/openr-and-d/getting-started/perform-tasks/dispute-resolution), hence it should be clear to the dispute manager too where to find everything, instead of basing it on the prior off-chain communication with the task manager.

In case your submission is accepted by the task manager, the task will be closed and you will recieve your reward. It is also possible to use submissions for milestone-based partial rewards if agreed upon in the task description. Here you can either deliver the milestone using off-chain communication with the task manager, after which they will issue a partial payment, or do it fully on-chain by creating a submission for each.

### How to create a submission? <a href="#how-to-create-a-submission" id="how-to-create-a-submission"></a>

1. Got to the view task page.
2. Head to the "submissions" tab.
3. Fill out the form at the bottom of the page.
4. Click the create button and sign the transaction with your wallet.


# Dispute Resolution

What to do if dispute arises for completion of projects

{% embed url="<https://drive.google.com/file/d/14Q2Xbeg9XkdQFsT-KZBT_GjSs9OPZa5f/view?usp=sharing>" %}

A dispute can arise when the task manager and executor cannot reach an agreement on if the task has been completed correctly. The executor can create a dispute for the dispute manager to review. This will usually cost a fee to compensate the dispute manager for their used resources to review.

The following outlines the steps of dispute resolution:

1. The task manager and executor try to reach an agreement, but after several attempts, this does not seem possible.
2. The executor goes to the view task page and selects the "disputes" tab.
3. They fill out the form at the bottom of this page.
4. Click the create button and sign the transaction.
5. The dispute manager will look into the case and either accept or reject your dispute. In case it is accepted, your specified reward % will be paid out and the task will be closed. Any leftover funds are returned to the task funder.

{% hint style="info" %}
How the dispute manager will decide their judgment differs from dispute manager to dispute manager.
{% endhint %}


# FAQs

Frequently Asked Questions

### **What are the key features of the tool?**

OpenR\&D allows for decentralized, transparent, and trustless task management. Using an Escrow ensures there won't be any issues with paying out the task. You can have a budget out of native currency and any ERC20 token. You can work on a task alone or in a team. You can even make a whole governance structure for your organization to work together in a transparent and trustless way. It is also possible to receive parts of the reward during the project, instead of everything at the end. In case there is any conflict if the task is completed successfully, you can create a dispute.

### **What security measures are in place to protect user data?**

All data related to tasks is stored on the IPFS network and the IPFS hash is stored on the blockchain. The IPFS hash of profile information is currently only stored in our indexer. It is not advisable to upload any sensitive user data, as it is very hard, if not impossible, to remove completely.

### **Are there any costs associated with using the tool?**

We do not charge any fees for using our service, however, as the tool uses smart contracts, which exist on a blockchain, gas fees apply. These will depend on what blockchain you are using and how busy the network is. These fees are paid to keep the network secure, Openmesh is not able to influence this.

### **How does the tool facilitate communication between applicants and tasks?**

Communication between the applicants and task manager is not part of the tool, as it would be very expensive to communicate on the blockchain. Task creators are recommended to provide a way to contact them in the task information. Applicants usually have GitHub or another platform linked on their profile, which you can contact. There are also various communication protocols based on blockchain addresses.

### **Can users track the progress of tasks they're involved in?**

The tool does not provide a native way to track progress. It is possible to make submissions to showcase the current state of the task, which should be rejected (as it does not complete the project). This would showcase the progress in a completely trustless and independent way but will require a gas fee to be paid for each update. Alternatively, the applicant can provide or be required to use any project tracking tool, such as Jira.

### **Is there a rating or review system for task participants?**

There is currently no way to rate or review participants. The problem with giving such a rating is that it is tempting to only check out this score. Due to the pseudonymous nature of the blockchain, this score could easily be tampered with. We do provide statistics on how many tasks someone has completed and what their success rate is. These figures should not be taken blindly though, instead, we recommend checking out their profile and seeing the quality of the tasks and submissions they completed.

{% hint style="info" %}
For example, it is possible to create a task with a very high budget and take it yourself. As we do not charge any fees, they will only lose out on some gas in exchange for a high score.
{% endhint %}

### **Where can I find support if I encounter any issues?**

In case of any issues, you can email us at <engineering@openmesh.network>.

[<br>](https://open-mesh.gitbook.io/l3a-dao-documentation/technical/audits)


# OpenR\&D Smart Contracts

### [Tasks](/open-source-initiatives/openr-and-d/openr-and-d-smart-contracts/tasks) <a href="#tasks" id="tasks"></a>

The Tasks contract is the heart of the OpenR\&D project. It contains all the functionality related to creating and updating tasks. It also stores all the task information and can be used standalone.

### [Escrow](/open-source-initiatives/openr-and-d/openr-and-d-smart-contracts/escrow) <a href="#escrow" id="escrow"></a>

The Escrow contract is used by the Tasks contract to store funds. Every task has its own escrow contract which will contain the budget of the task. Do not send funds to this contract directly, but instead, use the Tasks contract to increase the budget.

### [Task Drafts](broken://spaces/rlydSH1MIHSizkmm0cZU) <a href="#task-drafts" id="task-drafts"></a>

The Task Drafts contract is an Aragon OSx plugin. This means it can be installed into any Aragon OSx DAO. The plugin itself provides the functionality to allow anyone to create a proposal to create a certain task. This proposal will need to be approved by the governance structure of the DAO before the task is created.


# Tasks

### Create task <a href="#create-task" id="create-task"></a>

#### Inputs <a href="#inputs" id="inputs"></a>

**Metadata**: string; an uri to locate the json file describing the metadata of this task.

**Deadline**: uint64; unix time stamp (in seconds) before which the task should be finished. If not finished before the deadline, the task can be refunded by the manager.

**Budget:** ERC20Transfer\[] (tuple(address,uint96)); a list of ERC20 contract addresses and the amount of this token that is up for budget. At task creation this amount of ERC20 tokens will be transfer from the sender of the transaction to an escrow contract. This means the Tasks contract should be approved to spend this amount of ERC20 tokens beforehand.

**Manager**: address; the address that will have the permission to manage the task, such as approving applicants and reviewing submissions. This allows the funder to give this responsibility to someone else.

**Preapprove**: PreapprovedApplication\[] (tuple(address, Reward\[] (tuple(bool, address, uint88))); these addresses will get an approved application on task creation. This can be used to save gas on internal tasks or motivate a contributor to take your task, by making it easier for them to take it.

### Outputs <a href="#outputs" id="outputs"></a>

**TaskId**: uint256; the id of the newly created task. Note: currently Solidity does not give the return value of transactions, you can extract this id from the TaskCreated event in the transaction receipt logs instead.

### Code <a href="#code" id="code"></a>

````
```solidity
function createTask(
    string calldata _metadata,
    uint64 _deadline,
    ERC20Transfer[] calldata _budget,
    address _manager,
    PreapprovedApplication[] calldata _preapprove
) external returns (uint256 taskId) {
    _ensureNotDisabled();
    taskId = taskCounter++;

    Task storage task = tasks[taskId];
    task.metadata = _metadata;
    task.deadline = _deadline;
    task.budgetCount = uint8(_budget.length);
    Escrow escrow = Escrow(Clones.clone(escrowImplementation));
    escrow.__Escrow_init();
    task.escrow = escrow;
    for (uint8 i; i < uint8(_budget.length); ) {
        _budget[i].tokenContract.transferFrom(
            _msgSender(),
            address(escrow),
            _budget[i].amount
        );
        task.budget[i] = _budget[i];
        unchecked {
            ++i;
        }
    }

    task.manager = _manager;
    task.creator = _msgSender();

    // Default values are already correct (save gas)
    // task.state = TaskState.Open;
    unchecked {
        // Impossible to overflow due to openTasks <= taskCounter
        ++openTasks;
    }

    // Gas optimization
    if (_preapprove.length > 0) {
        task.applicationCount = uint16(_preapprove.length);
        for (uint16 i; i < uint16(_preapprove.length); ) {
            Application storage application = task.applications[i];
            application.applicant = _preapprove[i].applicant;
            application.accepted = true;
            _ensureRewardEndsWithNextToken(_preapprove[i].reward);
            _setRewardBellowBudget(
                task,
                application,
                _preapprove[i].reward
            );

            unchecked {
                ++i;
            }
        }
    }

    emit TaskCreated(
        taskId,
        _metadata,
        _deadline,
        _budget,
        _msgSender(),
        _manager,
        _preapprove
    );
}
```
````

### Apply for task <a href="#apply-for-task" id="apply-for-task"></a>

### Inputs <a href="#inputs-1" id="inputs-1"></a>

**TaskId**: uint256; the id of the task that you want to apply for.

**Metadata**: string; the uri pointing to the json metadata of your application.

**Reward**: Reward\[] (tuple(bool, address, uint88)); the desired reward if you manage to complete the task succesfully.

### Outputs <a href="#outputs-1" id="outputs-1"></a>

**ApplicationId**: uint16; the id of the newly created application.

### Code <a href="#code-1" id="code-1"></a>

````
```solidity
function applyForTask(
    uint256 _taskId,
    string calldata _metadata,
    Reward[] calldata _reward
) external returns (uint16 applicationId) {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsOpen(task);
    _ensureRewardEndsWithNextToken(_reward);

    Application storage application = task.applications[
        task.applicationCount
    ];
    application.metadata = _metadata;
    application.applicant = _msgSender();
    application.rewardCount = uint8(_reward.length);
    for (uint8 i; i < uint8(_reward.length); ) {
        application.reward[i] = _reward[i];
        unchecked {
            ++i;
        }
    }

    applicationId = task.applicationCount++;

    emit ApplicationCreated(
        _taskId,
        applicationId,
        _metadata,
        _reward,
        task.manager,
        _msgSender()
    );
}
```
````

### Accept applications <a href="#accept-applications" id="accept-applications"></a>

### Inputs <a href="#inputs-2" id="inputs-2"></a>

**TaskId**: uint256; the id of the task you want to accept applications of.

**ApplicationIds**: uint16; the ids of the applications you want to accept.

### Code <a href="#code-2" id="code-2"></a>

````
```solidity
function acceptApplications(
    uint256 _taskId,
    uint16[] calldata _applicationIds
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsOpen(task);
    _ensureSenderIsManager(task);

    for (uint i; i < _applicationIds.length; ) {
        _ensureApplicationExists(task, _applicationIds[i]);

        Application storage application = task.applications[
            _applicationIds[i]
        ];
        application.accepted = true;
        _increaseBudgetToReward(
            task,
            application.rewardCount,
            application.reward
        );
        emit ApplicationAccepted(
            _taskId,
            _applicationIds[i],
            _msgSender(),
            application.applicant
        );

        unchecked {
            ++i;
        }
    }
}
```
````

### Take task <a href="#take-task" id="take-task"></a>

#### Inputs <a href="#inputs-3" id="inputs-3"></a>

**TaskId**: uint256; the id of the task you want to take.

**ApplicationId**: uint16; the id of your applications, which has been accepted.

#### Code <a href="#code-3" id="code-3"></a>

````
```solidity
function takeTask(uint256 _taskId, uint16 _applicationId) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsOpen(task);
    _ensureApplicationExists(task, _applicationId);
    
    Application storage application = task.applications[_applicationId];
    _ensureSenderIsApplicant(application);
    _ensureApplicationIsAccepted(application);
    
    task.executorApplication = _applicationId;
    
    unchecked {
        --openTasks;
        ++takenTasks;
    }
    task.state = TaskState.Taken;
    
    emit TaskTaken(_taskId, _applicationId, task.manager, _msgSender());
}
```
````

### Create submission <a href="#create-submission" id="create-submission"></a>

#### Inputs <a href="#inputs-4" id="inputs-4"></a>

**TaskId**: uint256; the id of the task you want to make a submission for.

**Metadata**: string; the uri pointing to your submission data.

#### Outputs <a href="#outputs-2" id="outputs-2"></a>

**SubmissionId**: uint8; the id of the newly created submission.

#### Code <a href="#code-4" id="code-4"></a>

````
```solidity
function createSubmission(
    uint256 _taskId,
    string calldata _metadata
) external returns (uint8 submissionId) {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsTaken(task);
    _ensureSenderIsExecutor(task);

    Submission storage submission = task.submissions[task.submissionCount];
    submission.metadata = _metadata;
    submissionId = task.submissionCount++;

    emit SubmissionCreated(
        _taskId,
        submissionId,
        _metadata,
        task.manager,
        _msgSender()
    );
}
```
````

### Review submission <a href="#review-submission" id="review-submission"></a>

#### Inputs <a href="#inputs-5" id="inputs-5"></a>

**TaskId**: uint256; the id of the task you want to review a submission of.

**SubmissionId**: uint8; the id of the submission you want to review.

**Judgement**: SubmissionJudgement (uint8); if you accept the submission as completion of the task.

**Feedback**: string; the uri explaining why you made your decision.

#### Code <a href="#code-5" id="code-5"></a>

````
```solidity
function reviewSubmission(
    uint256 _taskId,
    uint8 _submissionId,
    SubmissionJudgement _judgement,
    string calldata _feedback
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsTaken(task);
    _ensureSenderIsManager(task);
    _ensureSubmissionExists(task, _submissionId);

    Submission storage submission = task.submissions[_submissionId];
    _ensureSubmissionNotJudged(submission);
    _ensureJudgementNotNone(_judgement);
    submission.judgement = _judgement;
    submission.feedback = _feedback;

    if (_judgement == SubmissionJudgement.Accepted) {
        unchecked {
            --takenTasks;
            ++successfulTasks;
        }
        _payoutTask(task);

        emit TaskCompleted(
            _taskId,
            _msgSender(),
            task.applications[task.executorApplication].applicant
        );
    }

    emit SubmissionReviewed(
        _taskId,
        _submissionId,
        _judgement,
        _feedback,
        _msgSender(),
        task.applications[task.executorApplication].applicant
    );
}
```
````

### Cancel task <a href="#cancel-task" id="cancel-task"></a>

#### Inputs <a href="#inputs-6" id="inputs-6"></a>

**TaskId**: uint256; the id of the task you wish to cancel.

**Explanation**: string; the uri to why you would like to cancel this task.

#### Outputs <a href="#outputs-3" id="outputs-3"></a>

**CancelTaskRequestId**: uint8; in case the task is able to be cancelled instantly, this will return 255. Otherwise it will return the id of the request that has been made.

#### Code <a href="#code-6" id="code-6"></a>

````
```solidity
function cancelTask(
    uint256 _taskId,
    string calldata _explanation
) external returns (uint8 cancelTaskRequestId) {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureSenderIsManager(task);

    _ensureTaskNotClosed(task);

    if (
        task.state == TaskState.Open ||
        task.deadline <= uint64(block.timestamp)
    ) {
        // Task is open or deadline past
        if (task.state == TaskState.Open) {
            unchecked {
                --openTasks;
            }
        } else {
            // if (task.state == TaskState.Taken) {
            unchecked {
                --takenTasks;
            }
        }
        _refundCreator(task);

        emit TaskCancelled(
            _taskId,
            _msgSender(),
            task.state == TaskState.Open
                ? address(0)
                : task.applications[task.executorApplication].applicant
        );
        // Max means no request
        cancelTaskRequestId = type(uint8).max;
    } else {
        // Task is taken and deadline has not past
        CancelTaskRequest storage request = task.cancelTaskRequests[
            task.cancelTaskRequestCount
        ];
        request.explanation = _explanation;
        cancelTaskRequestId = task.cancelTaskRequestCount++;

        emit CancelTaskRequested(
            _taskId,
            cancelTaskRequestId,
            _explanation,
            _msgSender(),
            task.applications[task.executorApplication].applicant
        );
    }
}
```
````

### Accept request <a href="#accept-request" id="accept-request"></a>

#### Inputs <a href="#inputs-7" id="inputs-7"></a>

**TaskId**: uint256; the id of the task you want to accept a request from.

**RequestType**: RequestType (uint8); the type of request you want to accept.

**RequestId**: uint8; the id of the request you want to accept.

**Execute**: bool; if you want to execute the request in this transaction.

#### Code <a href="#code-7" id="code-7"></a>

````
```solidity
function acceptRequest(
    uint256 _taskId,
    RequestType _requestType,
    uint8 _requestId,
    bool _execute
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsTaken(task);
    _ensureSenderIsExecutor(task);

    //if (_requestType == RequestType.CancelTask) {
    {
        _ensureCancelTaskRequestExists(task, _requestId);

        CancelTaskRequest storage cancelTaskRequest = task
            .cancelTaskRequests[_requestId];
        _ensureRequestNotAccepted(cancelTaskRequest.request);

        if (_execute) {
            // use executeRequest in the body instead? (more gas due to all the checks, but less code duplication)
            unchecked {
                --takenTasks;
            }
            _refundCreator(task);

            emit TaskCancelled(_taskId, task.manager, _msgSender());
            cancelTaskRequest.request.executed = true;
        }

        cancelTaskRequest.request.accepted = true;
    }

    emit RequestAccepted(
        _taskId,
        _requestType,
        _requestId,
        task.manager,
        _msgSender()
    );
}
```
````

### Execute request <a href="#execute-request" id="execute-request"></a>

#### Inputs <a href="#inputs-8" id="inputs-8"></a>

**TaskId**: uint256; the id of the task you want to execute a request from.

**RequestType**: RequestType (uint8); the type of request you want to execute.

**RequestId**: uint8; the id of the accepted request you want to execute.

#### Code <a href="#code-8" id="code-8"></a>

````
```solidity
function executeRequest(
    uint256 _taskId,
    RequestType _requestType,
    uint8 _requestId
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureTaskIsTaken(task);

    //if (_requestType == RequestType.CancelTask) {
    {
        _ensureCancelTaskRequestExists(task, _requestId);

        CancelTaskRequest storage cancelTaskRequest = task
            .cancelTaskRequests[_requestId];
        _ensureRequestAccepted(cancelTaskRequest.request);
        _ensureRequestNotExecuted(cancelTaskRequest.request);

        unchecked {
            --takenTasks;
        }
        _refundCreator(task);

        emit TaskCancelled(
            _taskId,
            task.manager,
            task.applications[task.executorApplication].applicant
        );
        cancelTaskRequest.request.executed = true;
    }

    emit RequestExecuted(
        _taskId,
        _requestType,
        _requestId,
        _msgSender(),
        task.manager,
        task.applications[task.executorApplication].applicant
    );
}
```
````

### Extend deadline <a href="#extend-deadline" id="extend-deadline"></a>

#### Inputs <a href="#inputs-9" id="inputs-9"></a>

**TaskId**: uint256; the id of the task you want to extend the deadline of.

**Extensions**: uint64; how many seconds to increase the deadline by.

#### Code <a href="#code-9" id="code-9"></a>

````
```solidity
function extendDeadline(uint256 _taskId, uint64 _extension) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureSenderIsManager(task);
    
    _ensureTaskNotClosed(task);
    
    task.deadline += _extension;
    
    emit DeadlineExtended(
        _taskId,
        _extension,
        _msgSender(),
        task.state == TaskState.Open
            ? address(0)
            : task.applications[task.executorApplication].applicant
    );
}
```
````

### Increase budget <a href="#increase-budget" id="increase-budget"></a>

#### Inputs <a href="#inputs-10" id="inputs-10"></a>

**TaskId**: uint256; the id of the task you want to increase the budget of.

**Increase**: uint96\[]; the amount to increase the budget by. This array should be the same length as the budget array. Each item will increase the budget entry with the same array index.

#### Code <a href="#code-10" id="code-10"></a>

````
```solidity
function increaseBudget(
    uint256 _taskId,
    uint96[] calldata _increase
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureSenderIsManager(task);

    _ensureTaskIsOpen(task);

    for (uint8 i; i < uint8(_increase.length); ) {
        ERC20Transfer storage transfer = task.budget[i];
        transfer.tokenContract.transferFrom(
            _msgSender(),
            address(task.escrow),
            _increase[i]
        );
        transfer.amount += _increase[i];

        unchecked {
            ++i;
        }
    }

    emit BudgetIncreased(_taskId, _increase, _msgSender());
}
```
````

### Edit metadata <a href="#edit-metadata" id="edit-metadata"></a>

#### Inputs <a href="#inputs-11" id="inputs-11"></a>

**TaskId**: uint256; the id of the task you want to edit the metadata of.

**NewMetadata**: string; the uri of the new metadata of this task.

#### Code <a href="#code-11" id="code-11"></a>

````
```solidity
function editMetadata(
    uint256 _taskId,
    string calldata _newMetadata
) external {
    _ensureNotDisabled();
    Task storage task = _getTask(_taskId);
    _ensureSenderIsManager(task);

    _ensureTaskIsOpen(task);

    task.metadata = _newMetadata;
    emit MetadataEditted(_taskId, _newMetadata, _msgSender());
}
```
````

### [Auto-generated documentation](https://github.com/L3A-Protocol/openrd/blob/main/docs/Tasks/Tasks.md) <a href="#auto-generated-documentation" id="auto-generated-documentation"></a>


# Escrow

### Initialize <a href="#initialize" id="initialize"></a>

#### Code <a href="#code" id="code"></a>

````
```solidity
function __Escrow_init() external {
    if (owner != address(0)) {
        revert AlreadyInitialized();
    }

    owner = msg.sender;
}
```
````

### Transfer <a href="#transfer" id="transfer"></a>

#### Inputs <a href="#inputs" id="inputs"></a>

**Token**: IERC20 (address); the ERC20 contract to transfer tokens of.

**To**: address; the address to transfer tokens to.

**Amount**: uint256; the amount of tokens to transfer.

#### Code <a href="#code-1" id="code-1"></a>

````
```solidity
function transfer(IERC20 token, address to, uint256 amount) external {
    if (msg.sender != owner) {
        revert NotOwner();
    }

    token.transfer(to, amount);
}
```
````

### [Auto-generated documentation](https://github.com/L3A-Protocol/openrd/blob/main/docs/Tasks/Escrow.md) <a href="#auto-generated-documentation" id="auto-generated-documentation"></a>


# Task Drafts

### Create draft task <a href="#create-draft-task" id="create-draft-task"></a>

#### Inputs <a href="#inputs" id="inputs"></a>

**Metadata**: string; the uri for the metadata of the proposal.

**StartDate:** uint64; unix timestamp (seconds) when the proposal voting period starts.

**EndDate**: uint64; unix timestamp (seconds) when the proposal voting period ends.

**TaskInfo**: CreateTaskInfo (tuple(string, uint64, ERC20Transfer\[] (tuple(address, uint96)), address, PreapprovedApplication\[] (tuple(address, Reward\[] (tuple(bool,address,uint88)))))); information about the task you want to propose to be created.

#### Code <a href="#code" id="code"></a>

````
```solidity
function createDraftTask(
    bytes calldata _metadata,
    uint64 _startDate,
    uint64 _endDate,
    CreateTaskInfo calldata _taskInfo
) external {
    // Could also add approve ERC20's of budget here
    // Currently the DAO should approve select ERC20's in advance (once) for unlimited spending

    IDAO.Action[] memory actions = new IDAO.Action[](1);
    {
        bytes memory callData = abi.encodeWithSelector(
            tasks.createTask.selector,
            _taskInfo.metadata,
            _taskInfo.deadline,
            _taskInfo.budget,
            _taskInfo.manager,
            _taskInfo.preapproved
        );
        actions[0] = IDAO.Action(address(tasks), 0, callData);
    }

    governancePlugin.createPluginProposal(
        _metadata,
        actions,
        0,
        _startDate,
        _endDate
    );
}
```
````

### Update Addresses <a href="#update-addresses" id="update-addresses"></a>

#### Inputs <a href="#inputs-1" id="inputs-1"></a>

**Tasks**: ITasks (address); the new address of the tasks contract used to create the draft tasks.

**GovernancePlugin**: IPluginProposals (address); the new address of the governance plugin used to create proposals.

#### Code <a href="#code-1" id="code-1"></a>

````
```solidity
function updateAddresses(
    ITasks _tasks,
    IPluginProposals _governancePlugin
) external auth(UPDATE_ADDRESSES_PERMISSION_ID) {
    tasks = _tasks;
    governancePlugin = _governancePlugin;
}
```
````

### [Auto-generated documentation](https://github.com/L3A-Protocol/openrd/blob/main/docs/DAO/TaskDrafts/TaskDrafts.md) <a href="#auto-generated-documentation" id="auto-generated-documentation"></a>