Part 1: Lessons from Catan 

I want to talk about an important distinction that we make in the Agoric smart contract platform, but first I want to talk about Settlers of Catan. Of course, trade is essential to Settlers of Catan — it’s part of the fun — so this isn’t an esoteric connection I’m making. 

If you’ve played the game — and if you’re reading a blog post about the coding of blockchain platforms, it’s quite likely you have — then you know the following situation. Pat and Terry are two players in a game, and it’s Pat’s turn:

Pat: “I’d like to trade 3 sheep for 4 bricks. Is anyone up for that?”

Terry: “Sure thing. I’ve got 3 sheep. Would you give me 5 bricks for them?” Pat: “No, no. I have sheep. I’m looking for bricks. I’m sorry I wasn’t clear.”

This lack of clarity is a natural occurrence in Catan. When I host a Catan session, I learned a while back to point this out at the start of a game: “Let’s be clear during trades. When you are looking to make a trade, it works better to say ‘I have X and I want Y.’” This probably sounds obvious, but again, if you’ve played Catan, you know how Abbott and Costello these conversations can get if players aren’t specific in the words they use and the sequence in which they use those words. 

In a game that I’m hosting, the conversation above is more likely to play out as follows: Pat: “I have 3 sheep and I’m looking for 4 bricks. Would someone be up for this trade?”

Terry: “I have 3 bricks. Does that work for you?”

Pat: “Sure thing. It’s a deal.”

Clearing up this sort of confusion was an important lesson for me, and it plays a role in my thinking about how to manage conversations between pieces of software. Playing Catan face-to-face gives you a vocabulary that includes voice and gestures. In contrast, as software designers we have to make similar distinctions in a different way between software agents.

Part 2: How Clarity Matters

Confusions like what I describe above force us to be clear about the terms of our offers, and that comes down to a simple rhetorical rule: clearly distinguish between what you have and what you want. If you abide by such a structure, you’re almost certain to be understood in Catan.

Notice that in the game, the players always explicitly said which kind of card. Amazingly, a lot of longstanding financial systems do not consistently make this distinction. If it’s a hassle in a board game, you can only imagine the ramifications when serious finance is the setting. 

If you wrote banking software in the 1970s in Manhattan, you assumed you were working in dollars. Then, imagine, one day the CEO of the company where you worked decided to expand your bank’s market to include yen: suddenly your system wasn’t up to the task. This was a confusion that, in retrospect, you needed to correct for. Today, we can more naturally include the type as part of the amount. 

Agoric is building a blockchain-based platform for economic activity, which means we need to send and describe payments. In the Agoric platform, we send payments to other users, and we describe “how much and of what” using amounts. Both payments and amounts are JavaScript objects, and they’re passed around the same way, but payments and amounts represent very different things. Let’s now dig into that.

Part 3: A Useful Distinction 

Here’s how the Catan lesson applies to software. In Catan, you use cards that represent something useful, such as the sheep and bricks in Pat and Terry’s interaction. Including a payment in a proposal would be like handing someone three sheep cards in order to tell them how much you can afford to pay. In software, the physical cues don’t exist. When you’re face-to-face, you can tell the difference between describing an amount versus handing over the cards. In software development, we needed to build that distinction into the code itself.

We do this by including amounts in proposals, and payments in offers. Zoe, our contract framework, treats proposals as a description of how much you want and how much you agree to give in return. An offer is the way you actually put up your side of the deal to enact the trade. (The fact that the payment in an offer constitutes an actual transfer of value is possible because of the magic of OCaps. For further background on OCaps, see the explanation written by Chip Morningstar. (Chip is also an engineer at Agoric.)

This is as simple as it sounds: In an object language like JavaScript the payments and amounts are ordinary objects sent in ordinary messages.

This distinction lets us send amounts with proposals. Amounts describe an asset without conveying rights to it. When we then write the offer, we include the payment of the token (in Catan this would be when we hand the other player the card), which actually transfers the token (in our platform, that means transferring to Zoe, which will then escrow it before transferring to the eventual recipient).

Part 4: Do You Want to Play?

The distinction between payments and purses, which convey and hold actual assets, and amounts, which merely describe them is fundamental to Zoe. This has implications like the fact that anyone can create an arbitrary amount for a particular brand since holding or sharing the amount conveys no rights. The ability to create or transfer payments is closely guarded. This distinction is at the core of what makes Agoric special in the world of blockchain and smart contracts. If you want to learn more about how to build on our chain, then the documentation on ERTP is the best place to take the next step.

Thanks for reading! You can join the Agoric community on Twitter, Telegram, LinkedIn, and catch us at these upcoming events.