Crypto Trends How Decentralized Storage Seals Poker Hand Histories Owen Gaines Owen Gaines is a professional poker player and author who has played an estimated ten million hands and written four poker strategy books. November 12, 2026 Decentralized storage can make poker hand histories tamper-evident: once a record is stored or anchored, any later change to it becomes detectable by anyone holding a copy. The mechanism is cryptographic hashing, the same building block that secures cryptocurrency networks. A hand history’s hash acts as a seal: if a single character changes, the hash no longer matches. Today, most online poker hand histories live in an operator’s database. Players trust that the records they download, and the records used to settle disputes or investigate collusion, are the originals. Decentralized storage and on-chain anchoring offer a way to make that trust verifiable rather than assumed, without publishing private data. This guide explains how content-addressed storage and hash anchoring work, what they can and cannot prove, and the trade-offs around privacy, permanence, and cost. It describes an emerging architecture rather than a feature of any specific site, and it separates two questions that are often confused: whether a record was altered, and whether the game was fair. What Sealing a Hand History Actually Means A hand history is a short text record: seats, stacks, hole cards, board cards, every action, and the final pot distribution. Sealing it means producing cryptographic evidence that the record existed in a specific form at a specific time, so that any later edit can be detected. The evidence is a hash, typically SHA-256. Hashing the same file always produces the same 64-character output, while any change, even a single chip in one stack, produces a completely different one. If that hash is published somewhere the operator cannot rewrite, such as a public blockchain, the record is effectively sealed. The important limit is scope. A seal proves the record has not changed since it was sealed. It does not prove the record was accurate when it was created, or that the shuffle behind it was fair. Those require separate mechanisms, covered later in this guide. How Content Addressing and Hash Anchoring Work Two approaches are commonly combined: storing data in a content-addressed network, and anchoring hashes on a blockchain. Content-Addressed Storage Networks such as IPFS identify files by a content identifier (CID) derived from the file’s hash, not by a server location. Requesting a CID returns only data that hashes to that CID, so a modified file cannot be served under the original identifier. IPFS alone does not guarantee persistence; files stay available only while someone pins them. Filecoin adds paid storage agreements, and Arweave uses a one-time payment model designed for long-term permanence. Hash Anchoring and Merkle Trees Writing every hand to a blockchain would be expensive and unnecessary. Instead, thousands of hand hashes are combined into a Merkle tree, and only the single root hash is published in one transaction, for example on Bitcoin or Ethereum. To verify one hand later, you need only that hand, a short Merkle proof (a few dozen hashes even for very large batches), and the anchoring transaction. The block’s timestamp proves the batch existed no later than that time. What Sealed Hand Histories Mean for Players For players, the practical value is in disputes and audits. A disconnection during an all-in, a contested tournament result, or a collusion investigation all depend on hand records. With anchored hashes, a player can check independently that the record shown to them matches what was sealed at the time. Approach Tamper Evidence Persistence Privacy Relative Cost Operator database only None; trust required Operator-controlled Private Lowest On-chain hash anchoring, data off-chain Strong Hash permanent; data held by operator Private Very low with batching Encrypted data on IPFS or Filecoin Strong (CID) Depends on pinning or storage deals Private if encrypted Low to moderate Encrypted data on Arweave Strong Designed to be permanent Private if encrypted; erasure difficult One-time fee The table shows why hash anchoring with off-chain data is the most practical starting point: it delivers tamper evidence without putting any hand data in public. Common Mistakes in Thinking About Sealed Records Treating a sealed record as proof of a fair game. Sealing proves integrity after creation, not honesty at creation. Assuming data on IPFS is permanent. Unpinned files can disappear even though their CID remains valid. Publishing raw hand histories. Full records include opponents’ hole cards and strategy data that should never be public. Ignoring timestamp precision. A block timestamp proves existence by a certain time, not the exact second the hand ended. Advanced Integrity and Privacy Trade-Offs Privacy and Selective Disclosure Players normally see only their own hole cards and cards shown at showdown. A sealed archive must preserve that. Common designs hash each player’s view separately, or encrypt full records and anchor only the hash, so a player can verify their own hands without seeing anyone else’s private cards. Permanence Versus Data Protection Permanent storage conflicts with data protection rights such as erasure under GDPR. Storing only hashes or encrypted data reduces the conflict, and deleting the decryption key, known as crypto-shredding, can make stored ciphertext unreadable. Design choices here carry legal weight and need data security and compliance review. Proving Fairness Requires Shuffle Commitments To address fairness, the operator commits to a hash of the shuffle seed before the hand and reveals the seed afterward. Anyone can then regenerate the deck and confirm it matches the hand history. Combined with anchoring, this links a sealed record to a verifiable deal. More advanced research uses zero-knowledge proofs to verify shuffles without revealing the seed at all. Verifying a Disputed All-In Hand A player disconnects during an all-in in a tournament and later questions how the hand was recorded and how the resulting payouts were calculated. Record: the player’s view of the hand history, provided by support Proof: a Merkle proof linking that record’s hash to a published batch root Anchor: the transaction ID containing the root, confirmed in a block shortly after the hand Fairness data: the pre-committed seed hash and the revealed seed The Technical Process The player hashes the hand history locally with SHA-256, applies the Merkle proof step by step, and checks that the result equals the root in the anchoring transaction. They then hash the revealed seed, confirm it matches the commitment published before the hand, and regenerate the deck to confirm the board cards. The Outcome All checks match. The player now knows the record has not been edited since shortly after the hand and that the deal followed the committed seed. The dispute moves from trust to evidence, and the remaining question, how disconnect rules apply, can be settled on facts both sides can verify. How Professionals Protect Their Hand History Records Experienced players already treat hand histories as data worth protecting, because they feed tracking software, coaching, and dispute evidence. Technical Risk Management Professionals archive the hand histories available to them after each session and back them up off the playing device. Some hash daily archives and keep the hashes separately, creating a personal tamper-evidence trail that does not depend on any operator. System Optimization Where a site publishes seed commitments or verification tools, professionals spot-check hands periodically rather than only after a dispute. They also keep tracking databases encrypted, since a hand history archive reveals a great deal about a player’s strategy. Technical Evolution in Hand History Integrity The building blocks are mature: hashing, Merkle trees, content addressing, and blockchain timestamps are all well established. What remains open is standardization, including common hand history formats, interoperable verification tools, and privacy designs that satisfy regulators. Zero-knowledge shuffle proofs and cheaper data-availability layers could eventually make every hand verifiable by default. Until then, players using the ACR Poker software can apply the player-side part today: archive the hand histories available to them, hash them, and keep those records secure. Frequently Asked Questions What does it mean to seal a poker hand history? Sealing means publishing a cryptographic hash of the hand history somewhere the operator cannot change, such as a public blockchain. Because any edit to the record changes its hash, anyone holding the original can later prove whether the record was altered. It creates tamper evidence, not a guarantee that the record was accurate when created. Does decentralized storage prove a poker game was fair? No. Storage and anchoring prove that a record has not changed since it was sealed. Fairness requires separate mechanisms, such as committing to a hash of the shuffle seed before the hand and revealing the seed afterward, so anyone can regenerate the deck and confirm it matches the recorded cards. Would my hole cards become public? They should not. Well-designed systems anchor only hashes on-chain, encrypt any stored data, and keep each player’s view separate. Publishing raw hand histories would expose opponents’ private cards and strategy data. Tamper evidence works with hashes alone, so no hand content needs to be public. Is data stored on IPFS permanent? Not automatically. IPFS identifies files by their content hash, but files remain available only while at least one node pins them. Filecoin adds paid storage agreements, and Arweave uses a one-time payment designed for long-term storage. For integrity alone, an anchored hash is enough even if the data is held elsewhere. How can I verify a hand myself? You need the hand history, a Merkle proof, and the anchoring transaction ID. Hash the hand history with SHA-256, apply the proof to compute the root, and check it matches the root recorded on-chain. If a seed commitment is available, also confirm the revealed seed matches the committed hash and regenerates the same deck. Why not write every hand directly to a blockchain? Cost and privacy. Thousands of hands per minute would create heavy transaction fees and put data on a public ledger. Merkle trees let an operator anchor an entire batch with one transaction while still allowing any single hand to be verified with a short proof, and no hand content appears on-chain. This article is for educational purposes only and describes general technical approaches, not the systems of any specific operator. It does not constitute legal advice. Data protection and gambling regulations vary by jurisdiction.