search

Proof-of-Participation Protocol

Concept of Interactive Distribution for the $PORTAL Token on the Stellar Blockchain

The distribution of the $PORTAL token is implemented through a Proof-of-Participation Protocol (PoPP), where token rights are derived not from direct financial investment, but from cryptographically verifiable vectors of engagement within the PORTAL POINT ecosystem and related projects.

hashtag
πŸ”· Architectural Foundation

1. Data Layer:

  • In-Game Protocol: Local POINT scores and achievement_data metadata stored off-chain.

  • Attestation Protocol: Periodic publication of Merkle hashes MerkleRoot_attestation from user state snapshots to the Stellar blockchain via the ManageData operation.

  • External Activity: A user's on-chain actions in connected projects (Stellar NFT transactions, DApp activity) recorded on the public Stellar ledger.

2. Verification Layer:

  • Soroban Contract Portal_Distribution: The core contract that: a) Accepts signed attestations signed_attestation and Merkle proofs merkle_proof. b) Verifies the attestation signature and its inclusion in a committed MerkleRoot_attestation. c) Parses structured data from the attestation: user_id_hash, metrics_vector.

3. Distribution Layer:

  • Allocation Formulas: Deterministic functions F(metrics_vector) executed within the Soroban contract.

  • Claim Mechanism: The claim_tokens(claim_proof) function, which mints $PORTAL tokens to the address specified in the claim_proof.

hashtag
πŸ”Ή Distribution Phases and Their Technical Implementation

Phase 1: Merit-Based Genesis Drop (MBGD)

  • Goal: Distribution based on pure participation.

  • Allocation: 250,000,000 $PORTAL.

  • Mechanics: The Portal_Distribution contract calculates a user's weight W1:

    text

    W1 = k1 * sqrt(S) + k2 * L + k3 * C

    Where:

    • S β€” Aggregated score from metrics_vector (a derivative of in-game actions, not direct POINTS).

    • L β€” Longevity coefficient (time since first verifiable activity).

    • C β€” Complexity coefficient (accounting for completing complex non-financial achievements).

    • k1, k2, k3 β€” Calibration constants set in the contract.

  • Technical Specifics: Does not require the user to hold any Stellar assets at the snapshot time. Verifiable activity within the MiniApp is sufficient.

Phase 2: Contribution-Weighted Allocation (CWA)

  • Goal: Accounting for external ecosystem support.

  • Allocation: 300,000,000 $PORTAL.

  • Mechanics: The contract calculates weight W2:

    Where:

    • V β€” "Participation Value," calculated based on analysis of the user's public Stellar transactions related to the ecosystem (e.g., payment for services via a partner gateway). Calculated by the contract based on last_N_transactions with specific memo tags.

    • A β€” Aggregated score from Phase 1 (measure of engagement).

    • D β€” Dilution coefficient, reducing weight for a short period between the transaction and the state snapshot.

  • Technical Specifics: Requires the user to perform public, tagged transactions on the Stellar network to form the evidence for V.

Phase 3: Asset & Partnership Multiplier (APM)

  • Goal: Integration with asset ownership and achievements in third-party projects.

  • Allocation: 250,000,000 $PORTAL.

  • Mechanics: The contract calculates weight W3:

    Where:

    • R_i β€” Rarity coefficient of owned NFT i (Stellar Asset), taken from the asset's metadata.

    • T_i β€” Time-held coefficient.

    • U_i β€” Usage coefficient (e.g., number of smart contract method calls associated with this NFT).

    • P β€” Bonus multiplier from partner projects. An external Soroban contract of a partner (e.g., HERO2QUEST) signs a message confirming the user's status/achievements. Portal_Distribution verifies this signature.

  • Technical Specifics: Uses direct queries to smart contract states and verification of cryptographic signatures from authorized partner accounts.

Phase 4: Community-Governed Emission (CGE)

  • Allocation: 200,000,000 $PORTAL (remainder + programmed emission).

  • Governance: Transferred to a DAO implemented as the Soroban contract Portal_DAO.

  • Emission Mechanics: The Portal_DAO contract mints tokens upon a voting-approved request, according to the formula:

    Where:

    • M β€” Monthly emission limit set in the contract.

    • Total_Value_Locked_In_Ecosystem β€” Aggregated value in XLM locked in related Soroban contracts (staking, liquidity).

    • $PORTAL_Price_EMA β€” Exponential Moving Average of the price, obtained from oracles.

hashtag
πŸ”Ή Claim Mechanism

  1. The user forms a claim_proof containing:

    • Stellar address for receipt.

    • Signed attestations and proofs for the relevant phases.

    • Proofs of ownership/transactions.

  2. Calls the function claim(phase_id, claim_proof) in the Portal_Distribution contract.

  3. The contract verifies the proofs, calculates the final allocation amount A_total = Ξ£(W_phase * Phase_Allocation_Pool / Total_Weight_phase), and executes the minting of $PORTAL tokens to the specified address via the Stellar Asset Mint operation controlled by the contract.

hashtag
πŸ”Ή Liquidity Provision

  • A dedicated $PORTAL/XLM liquidity pool is created on the Stellar DEX from a portion of the tokens from the CWA and APM phases.

  • Pool parameters (ratio, fee) are initialized by the Liquidity_Bootstrap contract and subsequently managed by Portal_DAO.

hashtag
πŸ”Ή Design Principles

  1. Separation of Game Points from Tokens: POINT is an internal, non-fungible metric. $PORTAL is an external, fungible Stellar asset. The connection is established through complex, non-linear transformation functions (sqrt, log) that prevent direct mapping.

  2. Priority of Public Proofs: Allocation is based on actions that leave a cryptographically verifiable trace on the public Stellar ledger (transactions, asset ownership, contract signatures).

  3. Progressive Complexity Verification: Each phase adds a new, more demanding vector for verification (activity -> financial support -> asset ownership/partnerships).

  4. DAO-Governed Post-Emission: Control over residual and future emission is decentralized and tied to objective ecosystem metrics.

This architecture creates a robust and verifiable distribution system where token rights emerge as a derivative of multifaceted, proven contribution to ecosystem growth, rather than simple capital allocation.

PreviousNFT IntegrationNextπŸ”Ί Mini App

Last updated