Decentralized Video Game Crates

How to create trustless randomness on a blockchain.

Ben Stokman
OneTwentyEight Blog
4 min readAug 18, 2017


I’ve been making an effort to make the images on my posts at least somewhat related to the post itself. Here are some crates… Those are kind of related.
Listen to the audio version

In my original whitepaper, I explained how crates would work. Crates in a decentralized video game work by the client contacting a server, and receiving a number determined by the server, and both the server and the client know what item was rewarded.

Anything decentralized does not have any way of having someone neutrally decide something like that.

However, there is a way to fix this: hashing. Hashing is a way to take any data, and make it into a specified amount of bits. The standard hash function is SHA-256, which outputs 256 bits of data. The output of a hash function will always be the same, as long as the input is the same, changing a single bit of the input will completely change the data beyond recognition. A good hash function keeps people from modifying data to get a specified output.

Hash functions are used to verify that data is genuine without having to sign a whole file, so instead, a hash of a file is signed, and is verifiable with any client with ease.

However, hash functions can be broken if coded improperly, Google has broken SHA-1. However, the hash function that is used by most blockchains (SHA-256) is considered secure.

Types of Crates

For my decentralized video game idea, there shall be two types of crates: block unlock crates, and normal crates.

Both crates will be the same thing, but the block unlock crates will have its number weight reversed (more on this later)


To keep things simple, I will refer to the random number generated as a seed. This seed will always be a hash of some data.

For normal crate unlocks, things are tricky. The seed, I originally planned, was going to be simply the hash of the transaction. While people [currently] cannot break SHA-256, they can guess and check.

Crates do not have a lot of items, even if there are a lot of possibilities, it is still feasible for a client to create many possibilities of the same transaction (a crate unlock is a transaction), and simply release the one that hashes to a seed that yields their desired item.

To stop this, you must incorporate some orderly randomness.

A block hash is random enough. Even though the target does limit the number range of a hash, it does allow for a lot of numbers, hashes are very long.

For a normal crate unlock, the block hash shall be added to the end of the transaction and then hashed. The seed is created.

Each block unlock shall also award the account who unlocked it with an item. With blocks, the block hash will be good enough for a seed. Unlike a simple transaction, it is not feasible (or efficient) to guess and check to get a desired item; you might as well promote the block you unlocked, and get the free item that comes along with it. There is no extra cost to promote a block that yields you an item that you do not prefer, then to not, and keep guessing.

Interpreting the Seed

A hash yields a number. Most hashes are in binary, but that can very easily be converted into a number; it is literally the same thing for a computer.

For each crate, items are assigned to a certain number or numbers. (again, more on this later) The item awarded will be the reminder of a division equation.

Allocating Numbers to Items for a Crate

I think that it would be nice to have a crate for each update. In the update vote for a block, the miner who unlocked it can vote on items to be included in the crate for the update, and separately vote for the tier for an item, inclusively, exclusively, a mix of the two, or just on its own.


Like every other item, items in a crate have a tier number of one through three, three being the rarest. At the end of each update, the blockchain will take all of the items that passed for the crate, and hash all of their data separately, the item with the lowest number hash comes first. Each item with tier ine shall be allocated three numbers (starting with zero), and each tier two item allocated two numbers, and each tier three item allocated one number in the order of the hashes; this way, the entire blockchain is able to instantly know what a crate will be

Block crates

The block crates shall be created the exact same way, with the excepton that a tier three item gets three numbers, a tier two, two numbers, and a tier one, one number.


The price of a crate in a normal video game is usually defined by the free market, which is affected by supply and demand. Usually the supply of crates is fixed, or unlimited, so demand is the major factor.

The blockchain shall give out crates via purchasing them.

Remember that tokens are destroyed when something is crafted, or bought, but there is no diminishing rate of token award for a block.

All crates, no matter what items are in them, shall have the flowing formula.

cost in tokens = (5 * <#addresses in the past 64 blocks> *  <the constant I mentioned in another post>) * (<amount of that specific crate bought in past 64 blocks> / 4,000)

In other words: if the amount of a certain crate bought in the past 64 blocks equals 256,000; the amount of tokens required will be five times the cost of crafting a tier one item.