A Token Engineering Process

The rapid development of the blockchain ecosystem has given rise to a new engineering discipline in the form of token engineering. What makes this discipline particularly complex is that we are dealing with the design of cyber-physical systems. The software (cyber) and social (physical) components in blockchain systems are inextricably linked. They operate on different time scales and interact differently depending on context. It is often assumed that understanding the rules of a system combined with the engineering know-how required to build the software is enough. But automated systems that interact with humans often behave in ways we don’t expect.

So how do we go about engineering these kind of systems?

Understand the whole system

Meddling with a small part of a complex system without first understanding how the whole system works is a recipe for unintended consequences. 

When dealing with these complex cyber-physical systems we have to take a systems approach. Systems thinking is a holistic approach to analysis that focuses on the way that a system’s parts interrelate, how systems work over time and how they operate within the context of larger systems. Much like natural systems, cyber-physical systems live in an ecosystem of actors and other systems that all influence each other.

There is a good introduction to systems thinking on the cadCAD community discord. For those who want to dig a bit deeper “Thinking in systems : A Primer” by Donella H Meadows and Diana Wright is a good place to start. Leyla Acaroglu also does a good job of outlining the fundamental concepts of systems thinking.

At this stage of the design process we are trying to do two things. Build stakeholder taxonomies by identifying stakeholder groups, their possible actions, and the form their incentives or individual utilities might take. Secondly we want to lay out the system dynamics and agent goals.

We call this system mapping. During system mapping we are trying to identify what concepts, constructs and stakeholders are relevant to our model and to begin to define their relationships to one another, as well as what the goals are for the system as a whole.

Tools for system mapping

There are a number of tools that help us take a step back and look at the dynamics and interconnections within the system we are trying to model. 

Ecosystem canvas

When filling out this canvas you are putting the purpose of the system at the centre and lay out the key players, contributors, and/or users in your ecosystem in the concentric circles radiating outwards.

Adapted from Simone Cicero’s platform design toolkit by Ville Eloranta.

Motivation matrix

Use the Motivation Matrix to see who creates value and who shares value with whom in the system.

Adapted from Simone Cicero’s platform design toolkit by Ville Eloranta.

Other useful tools include connected circles maps and brain dump maps.

This article barely scratches the surface of the theory and practice of systems thinking. For those interested in a deeper dive, here are some additional resources:

Formalising the design

Now that we have a sense for the overall design of the system we can start formalising our insights using causal loop diagrams and stock and flow diagrams.

Causal loop diagrams

A causal loop diagram (CLD) is a causal diagram that aids in visualising how different variables in a system are interrelated. They can be thought of as sentences that are constructed by identifying the key variables in a system (the “nouns”), and indicating the causal relationships between them via links (the “verbs”). By linking together several loops, you can create a concise story about a particular problem or issue. 

Causal loop diagram of Adoption model

Stock and flow diagrams

Stock and flow diagrams provide a richer visual language than causal loop diagrams. There are six main elements: stocks, flows, converters, connectors, sources and sinks. Below is an example stock and flow diagram as used by the token engineering community. For an in-depth explanation of this diagram see Abbey Titcomb’s article “Deep Dive : Augmented Bonding Curves

Causal loop diagram of Adoption model. Credit Michael Zargam

For a deeper understanding of this part of the process see the following resources:

Modularising the logic and building a model

Now that we have a more formal representation of our understanding we can start modelling our problem in cadCAD. cadCAD is an open-source Python package that assists in the processes of designing, testing and validating complex systems through simulation.

The first step in this process is producing a differential specification as in the example below. The differential specification syntax matches very closely with the code structure used in cadCAD models. Producing a specification in this format modularises the logic used to solve the problem. This allows us to swap out strategies and mechanisms easily as our understanding evolves.

Example differential specification. Credit Michael Zargam

Once this is done we can jump into coding our model. The best place to start is to set up a cadCAD development environment and work through the tutorials provided by BlockScience

Refining the models

Once we have a working model it’s time to refine. Our first model will most likely not be optimal, so we need to do quantitative and qualitative backtesting to refine the model. cadCAD also offers Monte Carlo simulations and parameter sweeping to help identify optimal parameter values and failure modes. 

Evaluate and improve the running system

Once a system has been designed and implemented cadCAD can serve as an invaluable tool in Computer Aided Governance (CAG) as proposed by Jeff Emmett and Michael Zargham. CAG is a decision support process that leverages a digital twin (modelled in cadCAD) of a running blockchain system.

The integration between the design and deployment loop. Credit Michael Zargam

Having a digital twin of a running system allows token engineers to :

  • evaluate proposed changes to the system
  • test parameter sensitivity
  • explore success criteria
  • explore failure modes
  • evaluate behaviours or polices
  • make recommendations to governing bodies

Acknowledgements

This process is just a start and is likely to evolve as the community deepens their understanding and experience. Much of the content for this article has come out of discussions on the cadCAD discord, the commons stack telegram group and personal input from Michal Zargham, Jeff Emmett and Sebnem Rusitschka, among many others.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s