Hashgraph Chess | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Hashgraph Chess technical Nov 17, 2021 by John Conway Community Member by John Conway Hashgraph Chess The motivation behind Hashgraph Chess was to develop a proof-of-concept application demonstrating how Hedera could be used to store a gamestate, in this case, chess. As the Hedera Consensus Service is designed to record immutable messages, it’s naturally well suited to act as a save file. Attempting to store a complex game's rolling save file in each message would likely hit the size limit. The game's history could be spread out across its topic instead. The architecture of the HCS log would need to be designed to facilitate this: passing the minimal information required in each message to track the gamestate. In addition, the game application would need to recreate the gamestate from this log in a timely fashion. In this regard, designing a game’s HCS log would be very similar to architecting a relational database service (RDS) -- it needs to contain the pertinent information in the appropriate format to succeed in its purpose. Furthermore, I wanted to demonstrate the concept using production-grade web architecture: NuxtJS containerized with Docker and hosted via AWS Elastic Beanstalk. Program Overview To develop a PoC, I would need a turn-based game with a ready-made Node module, as I did not want to spend time recreating the game's logic in Javascript. Chess was an obvious choice, as it had the popular chess.js module available. This module handles gamestate and retains additional features applicable to the PoC: move validation, turn history, and end conditions, to name a few. To use chess.js as the game's logical foundation, the app would need to send and retrieve players' moves from a Hedera topic. However, the chess.js module's Chess() gamestate was not intended to be decoupled in this manner. Therefore, a large portion of the development effort involved engineering a solution to decoupling the chess moves from their gamestate. The solution was for a Hedera topic to function as the match's canonical gamestate, while the NuxtJS front-end would store a dummy Chess() game object. Automated API calls to a mirror node would update this browser-side dummy with the latest, valid message data. And when a player submitted a chess move, instead of performing that move on the Chess() object in a typical fashion, it would be sent to the topic. The dummy gamestate would then be updated on the following API call. Because chess is a turn-based game with only two players, there was no risk of gamestate deviation if the application correctly validated the players' turn order. Initially, the intent was for players to submit individual chess moves to the match's topic. However, chess.js utilizes PGN (Portable Game Notation). This compressed notation for a chess match's history could easily fit within an HCS message. Therefore, the topic would store the match's rolling PGN instead of individual moves. For longer and more complex games, I would still resort to submitting unique moves -- or the results of turns, if the game's server needed to arbitrate their outcome (such as dice rolls). The result of this design was an application that allowed players to conduct chess matches on Hedera. The canonical gamestate being stored in a topic also meant that players could freely interact with the dummy gamestate without risking gamestate deviation. So, this allowed for a turn history browser function: players could scroll back and forth through their game's history with the confidence that they will always be interacting with the canonical gamestate for move submission. Storing each match's history in a topic also provided the durability and validity of that format. In addition, that same topic could be used to store chat messages between the players, and both the chat messages and chess moves would be available and synchronized so long as the topic remains. Topics as NuxtJS Dynamic Routes NuxtJS allows developers to populate dynamic routes from their URI. Things like rooms, menus, or chess matches can retain their dynamic route based on their URI parameters. This means that whenever a user wants to join an existing match, we can simply send them to a route like `~/matches/0.0.1234'. This URI is the ID of the topic where the match is stored. The dynamic match page uses that ID to load information about its match via the mirror node API call. NuxtJS also allows dynamic pages to have a parent page. So, in a more sophisticated version of the application, a URI like `~/matches/' could become a menu that allows users to browse their current and past matches. Subscribing to a Topic Subscribing to the match's topic is done through API calls that are repeated every 4 seconds. The API calls go out to a mirror node and perform a GET request for the message log of the page's topic. Messages the application hasn't seen before are then parsed for new data. Parsing Topic Messages Through Vuex The same topic is used to store information on chess moves, chat messages, and other game-related functions like resigning from a match. NuxtJS comes with a standard Vuex store that allows developers to utilize its mutations and actions from anywhere in their app without worrying about importing them into components. This Vuex store is where the app parses all the messages received from the API request. The message parsing method chain first determines the message's legitimacy: filtering out anything from one of the match's two players. It also filters out double moves and blank chat messages. The remaining validated messages are pushed into the appropriate array of the match’s Vuex object. The match’s game and chat panels are populated from those arrays. Learning Experiences While developing this PoC, there was a lot of trial-and-error involving subscribing to the topic. Initially, I had intended to use the gRPC API. This presented several problems: Each match would require a unique gRPC subscription A gRPC subscription can only be initialized from a server-side Hedera client I didn’t want to initialize the user’s Hedera client server-side, as this client contains sensitive account information that should be kept isolated and encrypted. Clients can be dynamically initialized server-side for the sole purpose of gRPC subscriptions, but each client has a limit of 5. So, the application would require a fleet of clients that scale in and out dynamically Creating this functionality was beyond the scope of this PoC. Eventually, I decided to make automated API calls to the mirror node instead of using a gRPC subscription. However, I still have a tentative solution for how this process might work. Possible Architecture for a Multi-User App The application would utilize socket.io's ‘Rooms’ feature. Every topic already has its dynamic Nuxt route. Each of these pages would also retain a socket.io room, where a gRPC subscription would be broadcast to all users visiting the page. The users’ browser clients would then translate these messages via a Vuex store in the same manner as it’s being accomplished now. This does not solve the issue of the subscription limit for Hedera clients. There are two ways we could organize the relationship between Hedera clients and gRPC subscriptions: The server could scale in and out a fleet of Hedera clients, whose purpose is to subscribe to topics and broadcast their information to the socket.io rooms. The server would then need to track its clients' active subscriptions and parcel out new subscriptions to inactive clients. When a room is emptied, its client will tear down the gRPC subscription. New clients would need to be initialized and destroyed as the application demands. Each socket.io room could initialize its own client, which would be torn down along with the room. This would be less efficient than keeping a fleet of clients that set up and teardown multiple subscriptions, but it would be easier to manage. Thankfully, topic subscriptions are a cost-free process so that these clients can be freely created without HBAR. The code is open-source and lives here. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy