mevcube

mevcube was a blockchain Rubik's cube puzzle. There was a single shared cube, anyone could turn it, and its state was managed by the smart contract. The rules were simple: solve the cube if it needs solving, or scramble it if it's already solved.

This project was an experiment with game mechanics and player incentives. I made this shortly after learning about MEV: the world of bots scanning the blockchain for arbitrage and frontrunning opportunities. If there were any value to be extracted I knew the bots would come. The question was, could this be put to any use?

The idea was to balance the incentives by having players pay to solve the puzzle. In exchange they would get the clout of solving a puzzle in public. On the other side were the bots who would seize the chance to grab a fee by scrambling the cube as soon as they saw a solution come through.

Wouldn't the players just scramble the cube immediately after solving it to take their fee back? My hypothesis was that MEV bots wouldn't allow this. MEV bots at the time had their fingers on the pulse of Ethereum blockchains and could reorder most transactions if it were profitable to do so. If someone solved the cube and immediately submitted a scramble transaction, a bot could reorder them to insert their own scramble.

The whole puzzle is represented by a 54-byte string in contract storage, with one byte per sticker and six faces of nine stickers. A solved cube looks like this:

UUUUUUUUURRRRRRRRRFFFFFFFFFDDDDDDDDDLLLLLLLLLBBBBBBBBB

Every turn of a layer is just a permutation of this string. The contract handles each move as a sequence of 4-cycles and applies them in place. An uppercase letter turns a layer one way and lowercase turns it back, so a player submits a whole sequence as one string:

move("RUrURUUr")

The move sequence is what the pending transaction panel under the cube is building. The original front end let you build a set of moves and then submit the whole sequence as one call.

A puzzle that stays solved isn't much fun, so the game needed a reason for someone to reset the puzzle. Every call to move() required a fixed solver fee (0.1 MATIC), which stayed in the contract. scramble() could only be called on a solved cube; it applied 30 pseudo-random turns and paid out the entire contract balance to whoever called it.

So I wanted to create a push-pull mechanism. Solvers pay to play and get nothing for it except a Solved event and a spot on the leaderboard. Scramblers get paid, and they're competing for a pot that grows with every attempt. Scrambling takes no skill other than vigilance, which made it exactly the kind of job I expected bots to take: watch for a solved cube, race to call scramble(), profit.

A blockchain is deterministic. Every node/validator replays every transaction and has to agree on the updates to the global state. That rules out real randomness. What some contracts do is hash inputs that are hard to know in advance and treat the output like a random seed. scramble() uses things like the caller's address and the current block number, to build pseudorandom moves scrambling the cube:

seed = encode(4, msg.sender, block.number)
for i in 0..29:
    layer = uniform(keccak256(seed, i), 9)
    turn(layer)

The uniform step is a small library by Brendan Asselstine that produces a uniform distribution over the cube layers.

To get true randomness, the solution is to use a verifiable randomness oracle such as Chainlink VRF, which returns a random value and a proof that it wasn't tampered with. I was working with VRF on a separate project, an NFT collection whose rarity was locked in by a VRF reveal, but never brought that into mevcube. For the cube, predictable scrambles are mostly harmless, since incentives should be orthogonal.