Program architecture
The program is structured into several key modules:- lib.rs - Program entrypoint definition
- processor.rs - Main instruction processing logic
- instructions/ - Individual instruction handlers (CreateGame, PlaceBid)
- state.rs - Account data structures (GameState, PlayerState, Bid)
- utils.rs - PDA derivation and helper functions
- error.rs - Custom error definitions
Program ID
The program ID is determined at deployment time. When deploying to devnet or mainnet, the program ID will be generated based on the keypair used during deployment.The program ID must be updated in your client SDK configuration after deployment.
Deployment information
The program can be deployed to any Solana cluster:- Localnet - For local development and testing
- Devnet - For public testing and integration
- Mainnet-beta - For production use
Build and deploy
To build the program:Core functionality
Game creation
The program allows users to create new bidding games by invoking the CreateGame instruction. This initializes:- A GameState account (96 bytes)
- An initial PlayerState account (32 bytes)
- An initial Bid account (48 bytes)
instructions/create_game.rs:22-145 for implementation details.
Bid placement
Players can place bids on active games using the PlaceBid instruction. Each bid must be at least double the previous highest bid. The program enforces:- Minimum bid amount (2x current highest bid)
- 10-minute timeout window
- Automatic game ending when timeout expires
instructions/place_bid.rs:16-151 for implementation details.
Prize distribution
When a game ends (either due to timeout or explicit end), the program:- Collects a 10% platform fee from the prize pool
- Distributes royalties to earlier bidders (if 5+ bids exist)
- Awards remaining balance to the last bidder
- Marks affected PlayerState accounts as “safe”
Account rent
All program-owned accounts must maintain rent-exempt balance:- GameState: 96 bytes + rent
- PlayerState: 32 bytes + rent
- Bid: 48 bytes + rent
Security considerations
PDA verification
All accounts are verified against expected PDAs before use. This prevents:- Account substitution attacks
- Unauthorized account access
- Invalid account ownership
Bid validation
The program enforces strict bid validation:- Bid amount must be ≥ 2x current highest bid
- Bid count must match expected sequence number
- Game must not have ended
- Timeout window must not have expired
Transfer safety
All SOL transfers use thetransfer_from_pda utility function which:
- Checks account balance before transfer
- Uses checked arithmetic to prevent overflow
- Maintains rent-exempt balance in program accounts
utils.rs:83-95 for implementation.