# Mobius DApp Protocol (MDP protocol)

## Overview

**Mobius DApp Protocol (MDP)** is an on-chain DApp economic model developed by the 404CTO engineering team, and it is also the core protocol concept of the dapp.meme platform. MDP defines a **token-driven application** infrastructure layer, allowing every token to become an interactive on-chain economy rather than merely a tradable asset.

> 💡 **Core concept**: Tokens should not just be tradable assets — DApp.meme turns tokens into interactive on-chain economies.

***

## Three-layer architecture

The MDP protocol consists of three interconnected layers, forming a self-reinforcing loop:

```mermaid
graph TD
    subgraph Token Layer Token Layer
        A[ERC-20 token]
        A1[Each DApp is bound to a token economy]
    end
    
    subgraph Participation Layer Participation Layer
        B[Players · Creators · LP]
        B1[Interact within the same loop]
    end
    
    subgraph Revenue Loop Revenue Loop
        C[Revenue flow back]
        C1[Revenue continuously flows back into the token economy]
    end
    
    A --> B
    B --> C
    C --> A
    
    style A fill:#4F46E5,color:#fff
    style B fill:#D97706,color:#fff
    style C fill:#059669,color:#fff
```

### Layer 1: Token Layer

> **Each DApp is bound to a token economy**

* Each MemeDice game is bound to an ERC-20 token
* The token is the game's **only currency**: betting, investment, and earnings all use this token
* The token's value is directly tied to the game's activity

**Significance**: A token is no longer just a speculation tool; it now has real use cases and value support.

### Layer 2: Participation Layer

> **Players, creators, and LP interact within the same loop**

There are three roles in the MDP protocol:

| Role                 | Behavior           | Source of earnings                    |
| -------------------- | ------------------ | ------------------------------------- |
| **Player**           | Uses tokens to bet | Wins tokens from other players        |
| **Creator**          | Deploys games      | Owner fee share                       |
| **LP (shareholder)** | Provides liquidity | Long-term returns from the house edge |

The three roles interact within the same economic loop, each getting what they need.

### Layer 3: Revenue Loop

> **Revenue continuously flows back into the token economy**

* Player bets → transaction volume grows → token circulation increases
* House edge → pool grows → shareholder returns
* Owner fee → creator earnings → incentivizes more creation
* More games → more use cases → token value increases

***

## Mobius loop

The name MDP comes from the **Möbius Strip** — a topological structure with only one side. This symbolizes the **seamless loop**.

```mermaid
graph LR
    A[token] -->|binds to| B[DApp]
    B -->|attracts| C[participants]
    C -->|generates| D[revenue]
    D -->|flows back| A
    
    style A fill:#4F46E5,color:#fff
    style B fill:#7C3AED,color:#fff
    style C fill:#D97706,color:#fff
    style D fill:#059669,color:#fff
```

**Loop logic**:

1. **Token → DApp**: The token is bound to the DApp and gains use cases
2. **DApp → participants**: The DApp attracts players, investors, and creators
3. **Participants → revenue**: Participants' activities generate transaction volume and revenue
4. **Revenue → token**: Revenue flows back into the token economy, increasing token value
5. **Token value increases → attracts more participants** → the loop continues...

***

## Permissionless deployment

One of the core principles of the MDP protocol is **permissionless**:

* Anyone can deploy a game for any ERC-20 token
* No application, approval, or whitelist required
* The deployment process is fully automated and completed in one transaction
* The game is available immediately, with no waiting

**This means**:

* Meme token communities can immediately create games for their own tokens
* Project teams can add use cases for their tokens
* Anyone can become a DApp creator

***

## MDP in MemeDice

### Token binding

Each MemeDice game is bound to an ERC-20 token at deployment, and that token becomes the game's only currency:

```
Game A → binds to $PEPE → all betting and investment use $PEPE
Game B → binds to $DOGE → all betting and investment use $DOGE
Game C → binds to $USDT → all betting and investment use $USDT
```

### Participant loop

```mermaid
graph TD
    P[Player] -->|bets $TOKEN| G[Game pool]
    G -->|wins| P
    G -->|house edge| LP[shareholders/LP]
    LP -->|deposits $TOKEN| G
    LP -->|withdraws earnings| LP
    G -->|owner fee| C[creator]
    C -->|deploys more games| G2[new game]
    
    style G fill:#4F46E5,color:#fff
    style P fill:#D97706,color:#fff
    style LP fill:#059669,color:#fff
    style C fill:#7C3AED,color:#fff
```

### Value creation

| Participant      | Value created                         | Returns obtained                               |
| ---------------- | ------------------------------------- | ---------------------------------------------- |
| **Player**       | Transaction volume, token circulation | Entertainment experience, profit opportunities |
| **Shareholders** | Liquidity, pool depth                 | House edge收益                                   |
| **Creator**      | Game deployment, community operations | Owner fee share                                |
| **Token**        | Use cases, value support              | Value growth                                   |

***

## Comparison with traditional models

| Dimension                    | Traditional DApp            | MDP Protocol                                 |
| ---------------------------- | --------------------------- | -------------------------------------------- |
| **Token role**               | Governance/speculation      | Core economic currency                       |
| **Deployment threshold**     | Requires a development team | One-click deployment, no coding required     |
| **Participant relationship** | Disconnected                | Cyclical and mutually beneficial             |
| **Revenue distribution**     | Centralized control         | Automatically distributed by smart contracts |
| **Composability**            | Limited                     | Any token can be bound                       |
| **Decentralization**         | Partial                     | Can be fully decentralized                   |

***

## Future outlook

The MDP protocol is currently implemented through MemeDice (dice game), and will expand to more DApp types in the future:

| DApp type                | Status         | Description                            |
| ------------------------ | -------------- | -------------------------------------- |
| 🎲 **MemeDice**          | ✅ Launched     | Dice game                              |
| 📊 **Prediction market** | 🔜 Coming soon | Price prediction, event prediction     |
| ⚔️ **PvP battles**       | 🔜 Coming soon | Competitive games player versus player |
| 🎰 **Lottery**           | 📋 Planned     | On-chain lottery system                |
| 🧩 **Third-party DApp**  | 📋 Planned     | Developer-customized DApp              |
| 🛠️ **Developer SDK**    | 📋 Planned     | For developers to build custom DApps   |

Each new DApp type will follow the MDP protocol's three-layer architecture, creating more use cases for tokens.

***

## Summary

> **The essence of the MDP protocol**: Let every token have its own on-chain economy.
>
> By binding tokens to DApps, MDP creates a self-reinforcing loop: token gains use cases → attracts participants → generates revenue → flows back into the token economy → token value rises → attracts more participants.
>
> This is the Möbius loop — a value flow with no beginning and no end.

***

## Related links

* ⬅️ Back [Technical deep dive overview](/dapp.meme-en/technical-overview/technical-deep-dive-overview.md)
* 💸 Learn [Fee System](/dapp.meme-en/technical-overview/detailed-explanation-of-the-fee-system.md)
* 🏗️ Learn [Smart Contract Architecture](/dapp.meme-en/technical-overview/smart-contract-architecture.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.dapp.meme/dapp.meme-en/technical-overview/mobius-dapp-protocol-mdp-protocol.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.