Incentive Mechanisms

The following chart summarizes the incentive mechanisms to be incorporated into the protocol’s design:

	Developers	Games	Container Nodes	Router Nodes	Validator nodes
Role	Creates microservices used in games and ecosystems.	Runs games that initiate connections to routers to request microservices for live game experiences.	Provides computational resources for running microservices and sets fees for services.	Acts as an API gateway that connects games to container nodes based on Quality of Service (QoS) requirements.	Ensures network integrity by validating availability and verifying service completion.
Motivations (Motives to Join)	Earn royalties for microservices created and used by game developers or public domain services.	Access scalable microservices for running games and flexible pricing models for required QoS.	Earn service fees and priority fees, and collect rewards for high availability even without workloads.	Earn rewards for routing games to appropriate container nodes based on service and QoS demands.	Earn rewards for validating proofs of availability and service, ensuring the integrity of network operations.
Desirable Actions	Develop widely used and reliable microservices for the ecosystem to promote usage and royalty earning.	Opt for services with suitable QoS for their games, maintain fair fee pricing, and prioritize efficient resource use.	Provide reliable, high-availability services and competitive fees for stable revenues.	Route games to container nodes based on accurate QoS matching, ensuring low latency and performance optimization.	Perform accurate and timely validation of container node availability and service delivery to maintain trust in the network.
Undesirable Actions	Producing low-quality or poorly maintained microservices that developers don’t adopt.	Underor over-bidding on QoS pricing, resulting in poor performance or inefficiency.	Offering unstable or unreliable container services, setting excessive fees, not maintaining availability.	Misrouting games to inadequate container nodes which leads to performance issues and unmet QoS expectations.	Failing to validate node performance accurately which could lead to trust issues and unfair reward allocation.
Important Factors	Royalties from microservice usage; enhanced reputation for creating top-tier services in the ecosystem.	Quality microservices for optimal game experiences; flexibility in service fees and prioritization of workload execution.	Service fees for computational workloads; rewards for maintaining high availability and handling demand spikes.	Network tokens for successful routing and providing key infrastructure for connecting games to containers.	Rewards for validating proofs, ensuring fair distribution of fees, and maintaining the integrity of the decentralized system.

Incentive Structuring

Beamable’s incentive structure includes staking requirements for nodes, slashing (penalty deductions) for misbehavior, and tiered rewards based on node performance. The model draws inspiration from existing DePIN staking mechanics and a tiered rewards approach.

Staking Dynamics

• The system is designed to require minimum staking for the nodes, complemented by delegated staking for broader community participation in network security and governance.

• Validator nodes receive rewards to ensure data integrity, with tiered rewards that adjust based on performance, maintaining high standards for service quality.

Additional Mechanisms

• Beamable developed a reputation system for nodes to encourage consistent performance. To this end, it offers bonuses or higher rewards to nodes with a proven track record.

• Reward Vesting and Lockup Periods: to reduce sell pressure initially, beamable will implement Rewards vesting for newly minted rewards to delay their distribution. This can be aligned with project milestones or specific compute performance metrics. Introducing early withdrawal penalties similar to Akash's model to discourage selling before rewards mature.

Compute credits

Credits are purchased with the project’s native token, creating continuous demand, as used in similar protocols such as Helium and Akash.