Introducing Treaty

We’re proud to present Treaty, our up-coming fully on-chain strategy game. Treaty includes a classic 4x core with multi-resource competition and a suite of new innovations. Most notably, players will participate in treaties — encoded social contracts that facilitate a wide range of meta-game behavior, from forming guilds or building in-game marketplaces that are directly plugged into the game itself.

We have tremendous conviction that treaties and broadly on-chain social contracts will explode in the next phaser of gaming, and empowering players with the right tools will be crucial. On-chain games promise composability that are more accessible than traditional games, yet not many have delivered. We see Treaty as the first step towards achieving just that. When building Treaty, we’ve reduced the barrier to contribute UGC through templates and forking, provided more clarity into the codebase and data structures, and overall gave contributors a guided way to create content through atomic pieces that will expand the “interestingness” of the game. Here's what we mean by all this ...

Treaty

Treaties are game-specific smart contracts that encode social contracts.

A treaty is many things. It can be a NATO-styled agreement where upon joining and membership payment you’re forbidden from attacking other committee members. It can be a national bank that issues USDC-backed tokens, forcing your trading partners who’ve signed to strictly use your national currency next time they swap in an in-game AMM. It can be a profit-sharing agreement, letting guild leaders tax guild members every time they harvest resource ERC20s while ensuring members’ safety by issuing them advanced weaponry. It can even be an AMM itself that restricts swap access to designated treaty members and awards special game-specific bonuses. There is no limit to what treaties can be.

Most importantly, rules defined in treaties are directly hooked into the core game functions. If you signed an alliance treaty such that you are forbidden from attacking other alliance members, this condition will be strictly enforced next time the base function attack is triggered. If you signed a guild treaty that includes a profit-sharing agreement, next time you harvest, the profit split is triggered and enforced. If you signed a trade embargo treaty, when you trigger the transfer function in a ERC20 in-game resource contract, the blacklist is checked against and blocks you from exchanging. Different treaties can compose and stack on top of each other.

Treaty meaningfully expands the metagame. Players can participate in crypto-native multiplayer experiences through inventing new treaties, whether that means a new way to organize your game DAO or issuing your nation’s own national reserve currency.

Ownership Layer - Smart Contract Wallets and Tokenization

Since inception we’ve known that the tokenization of in-game resources would be important for the game to reap benefits from being compatible with the plethora of DeFi innovations. To support such a game world, we’ve built a unified smart contract wallet layer that allows in-game items to hold tokens, aka inventories.

Here, certain game objects like buildings and armies are smart contract wallets, holding ERC20 tokens such as “Gold” or “Archers”. These smart contract wallets are then controlled by players, and they can act on their behalf exchanging tokens from one smart contract wallet to another. For instance, you can “transfer a sack of gold from the capital to a donkey’s back”, or “move 5000 units of archers from my squadron to yours for our clan war”.

This makes the 3rd party developer experience much more familiar as contributors can use the friendly ERC20 interface, using functions like transferFrom and approve. This unified inventory is also especially important for helping both players and developers to create an easy way to reason through how tokens can fluidly go from one place to another.

In addition to the vanilla ERC20 accounting checks when operating with tokens, they can obey additional rules such “only letting token transfers to happen if the sender and receiver are within 10 tiles from each other”, or soon even customized player conditions like “blacklisting the token transfer to the capital of a certain nation if there’s a trade embargo placed on them”.

Permissioning Layer - Delegation

A common behavior we envisioned for Treaty goes something like this: “I want to let my guild members control my armies when I’m offline, so they can coordinate a large-scaled battle easier”. or “I want to pay someone to manage my gold farms for me”. This is delegation - letting other players or smart contracts execute functions and play the game on your behalf.

We looked towards the ERC20 approve and delegation design pattern - because the authorization logic itself is built into the token standard, a series of many interesting design spaces opened up that let users delegate and spend on each other’s behalf.

In Treaty, we’ve baked in the delegation pattern for function calls. Players can delegate whether another address can call a function on their behalf such as “moveArmy” or “harvestGold”. Players can also delegate another address to be an additional delegator themselves. Maybe you’ve given a smart contract power to delegate additional permissions on your behalf such that when a player pays a certain amount of tokens to the smart contract, they are granted permission to access your empire’s treasury through the “withdraw” function.

This delegation layer working in tandem with treaties can enable complex behaviors in the metagame. When functions are called, the delegation layer checks whether you’ve been delegated the power to trigger the function. Of course, the delegation data is stored in our unified entity component data system such that players can view and re-use delegation details elsewhere if they wish.

Data Layer - ECS Game Engine

The entity component system is a common data structure and design pattern used in game development. Data is structured into entities (think an apple, a bullet, a goblin) and components which store data (think color, weight, height, attack damage). We recommend reading up on ECS here, here, and here.

In short, the Solidity entity component system automatically syncs with our indexer and client such that the engineering overhead of hardcoding structs, data encoders and decoders are minimized, letting us build crazier games even faster. A unified data store also allows developers to gain quicker understanding of it and therefore reuse data contributed by all other 3rd party developers.

Thank you

Over the coming weeks, we’ll be releasing a series of articles including technical deep dives, the theory of how we designed Treaty, and more details on the lore and rules of Treaty.

Once again, we want to thank everyone who played our summer demo and came out to our ETH SF event this fall. The feedback was instrumental in making our user experience smoother and game more enjoyable for all.

Treaty arrives January 2023. Make sure to join our Discord and say hi. Happy holidays!