A look at missions — from the codebase

Hey Martians!

Here’s another post in a series about the technical side of Mars Colony.

A while ago (in July '21) I started documenting some ideas, thoughts, solutions and technical scenarios, like: How we divide Mars territory

So, let’s continue.

Missions – how do they work and why is it impossible to cheat on xp? (spoiler – I don’t answer the last question directly, but you can share your guesses).

In our latest release, users take several steps while doing missions (not exactly in the current coding mission – we have made a bigger architecture for future much more complex missions and games).

Step 1: Prove Who You Are

User signs a Start mission message:

This message consists of a Mars Colony-specific header (Start mission), avatar id, land id, mission type and current timestamp. It is authorized in Metamask with your private key (of course nothing is disclosed – this is a standard Metamask mechanism) so our backend can be sure that the user who passes the mission is the true owner of the avatar.

A timestamp is used to verify that the signature is fresh (actually it can be reused within a small period of time, but I see no problem or vulnerability here).

Step 2: Play the Mission

To pass a mission, you play a game. Our coding mission is just a first step to something much greater.

while playing the game, the frontend (the app) communicates with the backend like with any game server. The only difference – each message has also a signature from step 1 to maintain a session. So, and this is the main thing, now we can create and integrate any game into our app (of course, any which can be run in a browser).

Step 3: End of Game

Only the server shall decide when the game ends. The client (our app, the frontend) can either do regular checks or can get this information with another response (which can be designed for each game individually).

Step 3a: Reward


The backend also decides about rewards. The reward amount can depend either on gameplay, xp, avatar characteristics, other active users, bitcoin price, Moon phase, and many other factors (we keep some of them secret). The human-facing data™ then appears in the form of the rewards message and signature in the data from server.

  • Human-facing data™ is used for the in-app dashboard, and informs what you see when you learn what rewards you’ve earned.
  • What’s behind the message is more interesting: there are
    • 32 random bytes
    • 5 bytes with an avatar id
    • confirmation of the previous 5 bytes (to easily check the validity of the message)
    • 5 bytes with land id
    • 8 bytes with earned xp amount
    • next bytes are reserved for other reward types, which will be added later
  • The signature. The backend has its own secret private key and signs the message

Note: used signatures are stored and can’t be reused

Step 4: Collecting the Reward

User clicks Collect and sends finishMission transaction to our GameManager contract. Transaction parameters include a message with reward data (see above) and its signature from the backend™.

Then our smart contract (GameManager) checks if the signature is valid (the signer should be the backend™), does several additional checks to the message and distributes fairly the rewards.

So, what’s been released is not only one very easy mission, but a stable and reliable architecture that can handle much more complex things like skill-based and multiplayer games, which are going to be fit into our mission system.

Fun fact: the code you generate in this first mission is that of our deployed and audited smart contracts.


From the land plot you can go back to the globe. But you can’t go back to the plot. Any way to fix that so you can go back to plot if thats where you entered the mission area from?

1 Like

Now just to make it run Doom…


great idea :slight_smile:

seems reasonable, thank you

Nice. So, if I’m understanding correctly, it is the use of asymmetric cryptography that gives the mission framework its security. When starting a mission, the message is signed with our private key to create a digital signature; this is a means of authentication because your back-end could validate our identity by decrypting the digital signature with our public key. If I’m correctly understanding “a timestamp is used to verify that the signature is fresh,” then perhaps the timestamp is included in the signature as a nonce for the session to also help protect against a replay attack.

The rewards message from the server is signed with the Mars back-end private key, which our client can then validate with the Mars public key. This could be useful, I believe, to authenticate the message came from Mars and validate its integrity, which ultimately could help protect against a Man in the Middle attack.

Finally, when the finishMission transaction is sent from the client, it includes the signature that was returned from the Mars back-end in the rewards message. My understanding is that the GameManager contract will decrypt the signature and use the included rewards data as arguments/parameters to distribute the rewards. This, to me (if I’m understanding correctly), sounds like a neat, stateless approach to managing the mission reward state: a Mars back-end doesn’t have to temporarily persist it in some session state; it is calculated by the Mars back-end, returned to the client, and then sent to the GameManager contract, with encryption and hashing being used for authentication, integrity, and confidentiality.

This helped me in my studies for a final exam tomorrow. lol.

Nice work – and thanks for sharing.



Durb gets it :fire:


You understand right, there are small additions below

The client doesn’t validate the message from server – there is no need for it. Maximum that the Man in the Middle attack is able to is to show some fake rewards in the interface.

And for finishMission in the contract: GameManager uses the byte message to get data, and signature is used to check the origin of the message, yes. For example a hacker could do such message with rewards and send it to the contract, but it isn’t possible for them to make a valid signature, so such transaction would fail

Good luck on your exam!




Just interesting - is this correct, that in decrypt missions, url for start is:


But start message is:

Start mission xxxxx:yyyyy:0:timestamp

Looks like bug report, thank you. We will fix and check this number on backend