🔗
LYNQYO - Whitepaper
  • 💡Project explained
    • 🔍Lynqyo Overview
      • Content economy: challange and potential
      • Creator: web3 protocols, applications and tools for a decentralized content-led economy
  • 👨‍💻User system
    • Web3 gateway: lynq.yo/ ‘links’
    • Creator⇋fan: ecosystem pipe
    • Creator: system⇔journey
    • Fan: system⇔journey
  • 🛡️Lynqyo Content Economy Protocol
    • Structure
    • Creating value: tokenized intangible content
    • DAO: governance of tokenized intangible content
      • Quadratic voting
  • 🪙The token
    • Lynqyo token: $LNQ
    • Functionality
    • Intrinsic challenges
    • Technical approach
    • Automated Royalty Distribution
    • Protection
  • 🚧Product architecture
    • Approach
    • Web3 portal for tokenized content: CUBE
    • Subscription payments and lending: creator DeFi
    • Thrust subscriptions: dAPP
  • 📊Tokeomics: Ecosystem, Applications and Associations
    • Balanced approach
    • Transactions
    • User Engagement Rewards: Creator+Fan
    • User engagement rewards: the how
    • Flow controls: auto-management
    • Flow controls: principle equation
    • Token allocations
  • 🛣️Roadmap
    • Stage 1: 2022
    • Stage 2: 2023
    • Stage 3: 2024
  • 📲Connect with us
    • Social media links
Powered by GitBook
On this page
  1. Product architecture

Approach

PreviousProduct architectureNextWeb3 portal for tokenized content: CUBE

Last updated 2 years ago

  1. Entities

There are three main entities in lynqyo: creators, fans and content. Creators are able to supplement with value and entertain their fans easily using CUBE infrastructure on the lynqyo ecosystem. Each eligible creator can be uniquely identified by a public key constructed through a derivation of the address that staked the necessary amount and the node ID. Relations between entities in the lynqyo ecosystem are shown in Fig.2.

Fig.2 Entities Structure

Furthermore, our infrastructure is divided into smaller units called CUBES. An eligible validator is assigned to a shard based on an algorithm that keeps the nodes evenly distributed across shards, depending on the tree level. Each shard contains a randomly selected consensus group. Any block proposer is responsible to aggregate transactions into a new block. The validators are responsible to either reject, or approve the proposed block, thereby validating it and committing it to the blockchain.

🚧