Solana Program
This section provides detailed explanations of each instruction available in the Race Protocol's Solana program.
Create Game Account
Purpose: This instruction creates a new game account on the blockchain, representing a specific game room and storing its initial state.
Permission: Anyone can invoke this instruction.
Typical Sender: The host or creator of the game typically sends this instruction.
Accounts Expected:
Signer: The account of the transaction sender (usually the host).
Writable: The newly created game account.
Writable: A temporary stake account used for token transfers during game creation.
Readonly: The mint account of the token used for gameplay.
Readonly: The SPL Token program account.
Readonly: The game bundle account (NFT) associated with the game.
Readonly: The recipient account that will receive payments from the game (optional).
Close Game Account
Purpose: This instruction closes an existing game account, provided it is empty (no players remaining). It retrieves any remaining assets from the game's stake account and removes the game account from the blockchain.
Permission: Only the owner of the game account can invoke this instruction.
Typical Sender: The host or creator of the game typically sends this instruction.
Accounts Expected:
Signer: The account of the game owner.
Writable: The game account to be closed.
Writable: The stake account associated with the game, holding the players' buy-in assets.
Readonly: A PDA account derived from the game account address.
Readonly: The SPL Token program account.
Create Registry
Purpose: This instruction creates a new registration account on the blockchain. This account acts as a lobby where games can be registered and discovered by players and servers.
Permission: Anyone can invoke this instruction to create a public registration account. For private registrations, only the designated owner can create the account.
Typical Sender: A player or platform operator typically sends this instruction.
Accounts Expected:
Signer: The account of the transaction sender.
Writable: The newly created registration account.
Create Player Profile
Purpose: This instruction allows players to create their on-chain profiles, storing information such as their nickname and avatar NFT.
Permission: Anyone can invoke this instruction to create their own player profile.
Typical Sender: A player sends this instruction to create their profile.
Accounts Expected:
Signer: The player's wallet account.
Writable: The newly created player profile account.
Readonly: The NFT account representing the player's avatar (optional).
Register Server
Purpose: This instruction registers a server account on the blockchain, allowing it to serve Race games.
Permission: Anyone can invoke this instruction to register their server.
Typical Sender: A server operator sends this instruction to register their server.
Accounts Expected:
Signer: The server owner's wallet account.
Writable: The newly created server account.
Settle
Purpose: This instruction handles the finalization of a game, processing settlements for players, distributing winnings, handling player exits, and updating the game account with the final state and checkpoint data.
Permission: Typically, only the Transactor server can invoke this instruction. However, other servers or players can send this instruction if they have gathered enough votes to indicate Transactor inactivity or misbehavior.
Typical Sender: The Transactor server usually sends this instruction after a game concludes.
Accounts Expected:
Signer: The game Transactor account.
Writable: The game account to be settled.
Writable: The stake account associated with the game, holding the players' buy-in assets.
Readonly: A PDA account derived from the game account address.
Readonly: The recipient account associated with the game.
Readonly: The SPL Token program account.
Readonly: The System program account.
Additional Readonly/Writable: The accounts of leaving players and recipient slots involved in the settlement process.
Vote
Purpose: This instruction allows players and servers to vote on the Transactor's inactivity or misbehavior. When enough votes are collected, the game is halted, and intervention is required to resolve the issue.
Permission: Any participant in the game (player or server) can invoke this instruction.
Typical Sender: A server or player sends this instruction when they suspect the Transactor is not functioning correctly.
Accounts Expected:
Signer: The voter's account (player wallet or server account).
Writable: The game account where the vote is being cast.
Readonly: The account of the Transactor being voted on.
Serve Game
Purpose: This instruction allows a server to declare its intention to serve a specific game. The server's address is written into the game account, and it potentially becomes the Transactor if it is the first server to join.
Permission: Any server can invoke this instruction.
Typical Sender: A server sends this instruction when it wants to serve a specific game.
Accounts Expected:
Signer: The server's wallet account.
Writable: The game account to be served.
Readonly: The server account.
Register Game
Purpose: This instruction registers a game account with a specific registration account, making the game discoverable by players and servers through that lobby.
Permission: For public registration accounts, anyone can invoke this instruction. For private registrations, only the owner of the registration account can register games.
Typical Sender: The host or creator of the game typically sends this instruction.
Accounts Expected:
Signer: The payer account (usually the game owner).
Writable: The registration account where the game will be registered.
Readonly: The game account to be registered.
Unregister Game
Purpose: This instruction removes a game account from its associated registration account.
Permission: The owner of the game account or the owner of the registration account can invoke this instruction.
Typical Sender: The host or creator of the game, or the platform operator managing the registration account, typically sends this instruction.
Accounts Expected:
Signer: The payer account (usually the game owner or registration owner).
Writable: The registration account from which the game will be unregistered.
Readonly: The game account to be unregistered.
Join Game
Purpose: This instruction allows a player to join a game by depositing the required tokens into the game's stake account.
Permission: Anyone can invoke this instruction to join a game, provided they meet the entry requirements and the game is not full.
Typical Sender: A player sends this instruction when they want to join a game.
Accounts Expected:
Signer: The player's wallet account.
Readonly: The player's profile account.
Writable: A temporary account used for token transfers during the join process.
Writable: The game account being joined.
Readonly: The mint account of the token used for gameplay.
Writable: The stake account holding the players' buy-in assets.
Writable: A PDA account derived from the game account address.
Readonly: The SPL Token program account.
Publish Game
Purpose: This instruction publishes a game bundle as an NFT on the blockchain, allowing developers to establish ownership and control access to the game logic.
Permission: Anyone can invoke this instruction to publish a game bundle.
Typical Sender: A game developer sends this instruction to publish their game.
Accounts Expected:
Signer: The payer account (usually the developer).
Writable: The newly created mint account for the game bundle NFT.
Writable: The associated token account for the payer and the game bundle NFT.
Readonly: The metadata PDA associated with the game bundle NFT.
Readonly: The edition PDA associated with the game bundle NFT.
Readonly: The SPL Token program account.
Readonly: The Metaplex program account.
Readonly: The System program account.
Readonly: The Rent sysvar account.
Create Recipient
Purpose: This instruction creates a recipient account on the blockchain. This account acts as an intermediate holder for assets before they are distributed to the final recipients according to their predefined shares.
Permission: Anyone can invoke this instruction to create a recipient account.
Typical Sender: A game developer or platform operator typically sends this instruction.\
Accounts Expected:
Signer: The payer account (usually the game owner or platform operator).
Readonly: The capability account that has permission to modify the recipient account (optional).
Writable: The newly created recipient account.
Readonly: The SPL Token program account.
Additional Readonly: The stake accounts associated with the recipient slots.
Assign Recipient
Purpose: This instruction grants an address a share of a specific slot within a recipient account.
Permission: Only the capability account (if defined) or the payer account can invoke this instruction.
Typical Sender: The game owner or platform operator typically sends this instruction.
Accounts Expected:
Signer: The payer account, which should be the capability account of the recipient (if defined).
Writable: The recipient account being modified.
Readonly: The account to be assigned as the owner of the slot.
These detailed descriptions provide a deeper understanding of the functionalities offered by the Race Protocol smart contract and how different components interact with it through various instructions.
Last updated