[SPEC] Tangle Marketplace Mechanism Spec Discussion

[drewstone]

Tangle Marketplace Mechanism Technical Specification

1. Overview

The Tangle Marketplace is a decentralized platform for cloud services, connecting developers, operators, and users. It facilitates price discovery and service matching through a hybrid model combining aspects of reverse auctions and order book systems.

2. Key Components

2.1 Blueprint Registry

• Developers register service templates (Blueprints) on-chain
• Each Blueprint includes:
  • Service specifications
  • Resource requirements
  • Configurable parameters

2.2 Operator Registry

• Operators register to Blueprints to provide services
• Include hardware specifications and capabilities

2.3 Price Advertisement System

• Operators advertise base prices for each Blueprint they can support
• Prices are specified per resource unit (e.g., CPU, memory, bandwidth)
• Operators can specify price multipliers for different configurations

2.4 User Request System

• Users can submit service requests with target budgets
• Requests include Blueprint ID and specific configuration parameters

2.5 Dynamic Order Book

• Maintains bid/ask spreads for each Blueprint
• Separate order books for different Blueprint configurations

3. Pricing Mechanism

3.1 Base Price Calculation

• Operators provide a base price matrix for each Blueprint:

  BP = f(CPU, Memory, Storage, Bandwidth)
  

• Price adjustments based on configuration:

  AP = BP * (1 + Σ(config_param_i * weight_i))
  

  Where AP is the adjusted price, and config_param_i represents different configuration parameters (e.g., number of nodes)

3.2 Reverse Auction Component

• When a user submits a request with a target budget:
  1. System broadcasts request to eligible operators
  2. Operators can bid at or below their advertised price
  3. Lowest bid wins if below user's target budget

3.3 Order Book Integration

• If no immediate match in reverse auction:
  1. User request added to buy-side of order book
  2. Operator advertisements form sell-side of order book
• Continuous matching attempts as new operators join or prices update

3.4 Dynamic Pricing Adjustments

• Operators can update prices based on:
  • Current demand
  • Resource availability
  • Competitor pricing
• Price updates trigger re-evaluation of open order book entries

4. Matching Algorithm

1. When a new user request is submitted:
   a. Check for immediate match with operator advertisements
   b. If match found, execute service provision
   c. If no match, initiate reverse auction
2. Reverse auction process:
   a. Broadcast request to eligible operators
   b. Collect bids for a set time period (e.g., 100 blocks)
   c. If winning bid found, execute service provision
   d. If no winning bid, add request to order book
3. Continuous order book matching:
   a. Attempt to match new operator advertisements with existing requests
   b. Attempt to match updated operator prices with existing requests

5. Incentive Mechanisms

5.1 Operator Incentives

• Reward for accurate price advertisements (e.g., lower transaction fees)
• Reputation system based on service quality and price consistency

5.2 User Incentives

• Discounts for flexible time windows on service requests
• Rewards for providing accurate market feedback

6. Market Stability Measures

6.1 Price Volatility Controls

• Implement price change limits per time period
• Use time-weighted average prices for extended services

6.2 Sybil Resistance

• Require stake from operators proportional to their advertised capacity
• Implement progressive reputation building for new operators

7. Data Collection and Analysis

• Record all transactions, bids, and matches
• Provide market analytics to all participants
• Use collected data to refine pricing models and matching algorithms

8. Governance and Upgrades

• Implement on-chain governance for adjusting market parameters
• Allow for community-driven proposals for mechanism improvements

[monaiuu]

Preliminary Questions:

1. Does the auction mechanism result in a single operator or multiple operators winning for each bid?
2. How does automatic vs. manual approval and max. # instance configurations set by operators impact the selection process and auction mechanism?
3. Confirming user first go through the initial operator selection process, allowing the user to choose preferred operators based on factors like liquidity, assets, success rates, and geographical location, to select the operators to compete in bidding.
4. Does the system requires pre-funding/escrow to ensure users have sufficient funds to cover their target budgets, determined by TTL and various configurations? How does the system ensure Operators are protected/ compensated in case of insufficient funding and prevent service disruption?