♠️
RACE Protocol
NFT PresaleDiscord
  • ❤️Official Docs & Links
  • ⏳Progress Overview
  • RACE Protocol
    • 🏗️System Architecture
      • Components
      • On-chain Accounts
      • Synchronization
      • Randomization
      • Payment
    • 🎲Game Development
      • Game Handler
      • Effect
      • Event Handling
      • Race API
        • Arweave Integration
      • Race JS SDK
        • Installation and Setup
        • Key Components
          • AppClient
          • SubClient
          • Events
          • Game Context
          • Decryption Cache
        • Advanced Features
          • Getting Revealed Knowledge
          • Exiting and Detaching
          • Submitting Messages
          • Sub-game Interaction
        • Best Practices
        • API Reference
        • Troubleshooting
    • 🧪Testing
      • Race Test Kit
      • Unit Testing
      • Integration Testing
      • Additional Considerations
    • 🧱Modules & Features
      • Encryption Methods
      • Command-line Tools
      • Configuration Options
      • Blockchain Transport Implementations
    • 📃Smart Contract
      • Solana Program
    • 🔦Examples and Use Cases
      • Draw Card Game
      • Raffle Game
      • Other Examples
  • RACE Games
    • ♠️RACE Poker app
      • 🎮Start playing in minutes
        • 💰Cash and sit-n-go
        • 🏆Tournaments
      • 🎨Workshop
        • 🏆Create cash games
        • 🏨Create tourneys
      • 💡Concept introduction
      • 🏗️System architecture
      • 👾Game Flow
      • 🎲Cards shuffling
      • ☎️Communication
      • 🔐Key sharing/decryption
      • 💱Cash flow structure
    • ⚡Solfast
      • 🎲Game modes
  • RACE RESEARCH
    • 👾No-Code Development
      • Brainstorming
      • Implementation Approach
      • Project Status
    • 0️⃣Zero-Knowledge Proofs
      • Brainstorming
      • Integration steps
        • Verifiable Randomness Generation
        • Private Game State Updates
        • Verifiable Settlements
        • Private Player Actions
      • Project Status
    • 🛡️Security Audit Report
      • Executive summary
        • Introduction to Race Protocol
        • Audit Methodology
      • Findings
        • Smart Contract Security
        • WebAssembly Security
        • Client-side Security (Race SDK)
        • Server-side Security
        • Randomization and Encryption
        • On-chain Account Management
        • Synchronization Mechanisms
        • Payment Handling
      • Recommendations
      • Conclusion
  • RACE DAO
    • 😎About
    • 🫂Community
    • 🖼️NFT Collection [!]
Powered by GitBook
On this page
  • Recipient Accounts
  • Benefits of Recipient Accounts
  • Example: Tournament Payment Structure
  1. RACE Protocol
  2. System Architecture

Payment

Managing payments in blockchain games can be complex, especially when dealing with multiple recipients, commissions, and prize pools. Race Protocol introduces the concept of recipient accounts as an intermediate layer to simplify and streamline the payment process.

Recipient Accounts

A recipient account is an on-chain account that acts as a temporary holder for assets before they are distributed to the final recipients. It can have one or more wallets associated with it, each owning a predefined share of the assets held in the account. These associated wallets are referred to as receivers.

Here's how recipient accounts facilitate complex payments:

  1. Creation: The recipient account is created with a defined set of slots, each representing a portion of the assets to be distributed. Each slot can be assigned to a specific receiver or remain unassigned until later.

  2. Payment to Recipient Account: When a payment is made to the recipient account, the assets are automatically split and allocated to the designated slots according to their predefined shares.

  3. Claiming by Receivers: Individual receivers can then claim their share of the assets from the corresponding slots in the recipient account. This claiming process typically requires approval from all owners of the recipient account, ensuring that everyone agrees on the distribution.

Benefits of Recipient Accounts

Using recipient accounts offers several advantages for managing payments in Race games:

  • Simplified Complex Payments: Recipient accounts allow for the structuring of complex payment schemes with multiple destinations and varying shares. This simplifies the process for developers and ensures accurate and transparent distribution of assets.

  • Commission Management: Game owners or platforms can designate themselves as receivers with a specific share, allowing them to automatically collect commissions on game winnings or fees.

  • Prize Pool Distribution: In tournament games or crowdfunding scenarios, recipient accounts can be used to efficiently manage and distribute prize pools to multiple winners or contributors.

Example: Tournament Payment Structure

Consider a tournament game with a crowdfunded prize pool and multiple sponsors who contribute to the pool in exchange for a share of the game commission. A recipient account can be created with slots allocated to the sponsors and the tournament organizer according to their contribution and commission agreements. When players join the tournament and pay entry fees, the funds are sent to the recipient account and automatically distributed to the designated slots. After the tournament concludes, sponsors and organizers can claim their respective shares from the recipient account.

This example demonstrates how recipient accounts can streamline complex payment structures and ensure transparent and automated distribution of assets to multiple parties.

By leveraging recipient accounts, Race Protocol simplifies payment management for developers and provides a secure and transparent mechanism for handling complex payment scenarios in web3 games.

PreviousRandomizationNextGame Development

Last updated 1 year ago

🏗️