Today, our company starts the security token sale of Connex Coin, the first tokenised investment token compliant with EU regulations. In essence, Connex Coin represents a loan towards the managing entity of a fully leased, premium commercial property, named Connex, in...
Governance Tokens – The New Medium Of Power?
Money is not Power – Control Over it Is.
Uniswap, a Decentralized Exchange (DEX), generates every 24h around $3.5m in fees for liquidity providers of the protocol. A recent proposal suggests, taking 0.005% of the 0.03% fee to distribute it to the Uniswap DAO, to fund further development of the protocol. If implemented, holders of UNI, Uniswap’s governance token, are going to have control over these funding streams, $600k a day, $219m a year. Continue reading, to learn more about DAO governance tools, the use cases of governance tokens and the major DAO infrastructure providers.
What is Governance, and why do we need it?
Your friends and you need to make a decision to which bar to go (at least before corona). Multinational companies need to decide whether to put BTC on their balance sheet or not. And the United Nations need to reach agreement how to reduce CO2 emissions. Different types of organized groups require and use different governance tools to come to a collective decisions. Governance includes processes, like discussions and voting, tools, like laws and contracts, and structures, like democracies or hierarchies. While your friend and family language and informal hierarchies are sufficient to reach agreements, nation states require laws and formal voting processes. With the Bitcoin Network a new type of self-organized society arose, which don’t have a centralized entity responsible for decision-making. These novel types of organizations bring up their own governance primitives, which allows them governing and maintaining their underlying computer protocols.
Governance of Decentralized Autonomous Organizations
DAOs started with Bitcoin and developed since then. Today, we see different types of DAOs in the blockchain space. From people to come together to govern a layer one protocol, to Decentralized Application (dApp), to tokenized investment funds. In general, DAOs are stateless, open and not controlled by any single entity. The centre of DAOs are smart contract which control the funds of the organization. When it comes to DAO governance, you can differentiate between two main types, Off-Chain and On-Chain governance.
Off-Chain Governance
Bitcoin and Ethereum use an informal governance process. Proposals are made mainly by core developers and discussed in the community. When they reach consensus, miners, the entities which run the machines of the protocol, update the software of their nodes and thereby the underlying protocol. This process can be very time costly and can lead to hard forks if only a part of the network decides implementing the changes. A prominent example is the hard fork of Ethereum and Ethereum Classic, as a result of “The DAO” hack, or Bitcoin and Bitcoin Cash, which implemented a bigger block size.
On-Chain Governance
As the name indicates, the voting process of on-chain governance takes place on the blockchain, using some form of governance tokens.
Hereby, three different types are common.
1. Company Model
One governance token represents one vote. These tokens can be transferred and traded on open market.
2. Membership Model
Each member of an organization gets assigned only one vote via a membership token. These tokens are non-transferable and in most cases even revocable.
3. Reputation model
This system can be seen as a mix of the company and membership model. One reputation token represents one vote, like a company token. However, reputation tokens are not transferable, like membership tokens.
Governance tokens find application in modern layer 1 blockchain protocols, like Tezos, Cosmos and Polkadot. Further, blockchains built using the Pariy’s Substrate Framework facilitate on-chain voting. On-chain voting brings various advantages for layer 1 protocols since it significantly reduce the possibility of hard-forks and allow for faster turnaround time to implement changes. Further, governance tokens are extremely popular for Dapps, especially in decentralized finance (DeFi). One of the earliest examples is MKR, the governance token of the Maker DAO, which allows holders to vote on decisions on the protocol the stable coin DAI runs on. Today, most of the DeFi protocol have their governance tokens like COMP or AAVE, of the lending platforms Compound and Aave, or Automated Market Makers, Balancer (BAL) and Uniswap (UNI).
Governance tokens do not only find a utility in allowing voting rights on proposals. They prove as a very effective marketing tool to attract users to actively use DeFi protocol. A great example is, how Sushiswap, a Uniswap clone, attracted over $1b of liquidity by introducing their $SUSHI governance token as a reward for users providing liquidity. Much of this liquidity came from Uniswap and went back to Uniswap after their launch of their own governance token $UNI.

DAO Infrastructure Providers
But how does voting and governance now work in detail? Most DAOs are made of three layers. The first layer are often web2 primitives to discuss proposals, like forums and communication tools, like Discord or Slack. The second layer contains a voting mechanism, involving governance tokens. The third layer involves the fund management of the DAO.
Let’s have a look at major DAO infrastructure providers, which evolved in the space.
Aragon DAO & Snapshot, Moloch DAO, DAOStack and Community.xyz.
Aragon DAO is by far the most developed DAO infrastructure project. It hosts over 1700 DAOs which have around $900m crypto assets under management. Aragon offers a wide range of apps, for managing funds, projects, DAO specific governance tokens, permissions and voting. The sky’s the limit with Aragon. Custom apps can be developed using Aragon CLI. Further, Aragon offers the Aragon Court, a human based arbitration service. Aragon itself has two tokens, ART for voting on proposals and ANJ which need to be minted with ART and staked to become an Aragon Court judge. Aragon DAOs are only currently available on the Ethereum Mainnet. Since this made voting very expensive, Balancer Labs developed Snapshot, a gas-less off-chain voting tool, which leverages IPFS and Arweave to verifiable count votes. The latest integration of Aragon Agreement allows for off-chain voting on Snapshot with on-chain execution. Further, Aragon is developing an own blockchain, using the Cosmos SDKR, to migrate the platform risk caused by building on Ethereum.
Moloch DAO is a framework, which is used, for example, by MetaCartel DAO or The LAO. Moloch DAOs also have a proposal, voting and fund management template. This DAO framework features two types of tokens, Loots and Shares. Loots are economic shares in the funding pool of the DAO, without any voting rights. In contrast, Shares inherent also voting rights. The Pokemol app provides a frontend for Moloch DAOs and on DAOhaus you can find an overview on all Moloch DAOs. On special feature of Moloch DAOs is the “Ragequit” feature, which allows users to take their funds and leave a DAO if they not agree with decisions made by the community. Moloch DAOs can be launched on Ethereum Mainnet and also on xDai, a second layer solution with substantially lower fees.
DAOstack is used, for example, by The Genisis DAO and over 50 smaller organizations. Alchemy is the fund and proposal manager of the framework. The DAOstack introduced the GEN token to direct attention to the most relevant proposals. GEN can be bought by anyone and staked on any proposal of any DAO. However, GEN itself does not have any voting power, it is used as a signal for high quality proposals. Voting takes place using REP tokens of each DAO. When a proposal is passed, GEN stakers will be rewarded with GEN. This concept is called “Holographic Consensus”. Like a Moloch DAO, DAOstack is available on Ethereum Mainnet and the xDai network.
Community.xyz is the DAO framework of Arweave. Arweave itself is a new type of storage blockchain, which allows the creation of fully decentralized application. These dApps are governed by Profit Sharing Communities (PSCs) which can be created and managed using the Community.xyz dashboard. These DAOs leverage a super exciting token model, called Profit Sharing Tokens (PSTs). The utility of these tokens is two-fold:
1. Voting
Like other governance tokens, the PSTs can be used to vote on proposals. For example, to reward contributors with newly minted PSTs for accomplishing tasks, written out on the community.xyz job board.
2. Monetization
What makes PSTs especially interesting is, that they grant holders a share of the transaction fees (gas fees), paid by users while using the application. This model allows creators of dApps on the Arweave network to fund and continuously monetize on the usage of their applicaitons.
Conclusion
For the first time in history, Bitcoin granted mankind full control over their money. No centralized issuer. No single entity, which could hinder you from transferring your assets. This sovereignty is enabled by a new organizational form, often referred to as Decentralized Autonomous Organizations (DAOs). Modern DAOs come with governance tokens, which allow their holders to take part in the decision-making process of these organizations. DAOs and governance tokens form a new framework for organizing human collaboration. Most DAOs are open and operate boarderlessly. Anyone to join and to earn money for contributing to a common goal. Funds of these organizations are hold in Smart Contracts in a secure and transparent way. Currently, we are at the very beginning of this novel organization form. Time will tell how these communities will develop and integrate with existing legal frameworks.
Datarella Becomes Associate Partner of IDunion
We are happy to announce that Datarella is now an Associate Partner of the IDunion consortium. As an established blockchain solution provider Datarella adds expertise in blockchain development, system design and identity management.
IDunion develops a basic infrastructure for the verification of identity data. For this purpose, a distributed database will be jointly operated by a European cooperative. The network will be set up and managed by various actors consisting of private companies, associations, cooperatives, government institutions, educational institutions and other legal entities.
IDunion’s infrastructure is based on open standards and open source technology for Self-Sovereign Identity (SSI) and is particularly characterized by data economy and transparency. The solution gives users the opportunity to manage their identity information themselves and to decide when and with whom they want to share it.
Technical Deep Dive: M-ZONE – Efficient Smart Parking For Metropolitan Areas
Earlier this week, together with our partners at fetch.ai we released a driver walkthrough video that lets you come along for the ride during the M-Zone Field trials. For the first time, Datarella and Fetch.ai have field-tested an AI-powered Deep Parking solution installed at the Connex building complex in Munich. M-Zone provides automated incentives for efficient smart parking in metropolitan areas. It cuts C02 emissions by providing drivers with real-time options for parking and nudging them with tokenized incentives to park when and where demand is lowest without wasting time or energy driving in circles looking for a spot. Lots of people have asked for more details on how the system works so we decided to draft a technical deep-dive post explain how we built the system and what’s next for M-Zone.
First, let’s dive into a description of the hardware we used to make the M-Zone Smart Parking field trials possible. After that, we’ll delve into the software components and architecture as well as taking a look into how the fetch.ai agents interact with one another and what those interactions mean for cities, parking infrastructure providers, drivers, and the environment.
Edge Nodes

Two edge nodes powered up and scanning for plates. The display between them displays images captured during testing.
For the M-Zone field trials, we deployed two edge computers running computer vision software and fetch.ai autonomous economic agents to the Connex buildings at Frankfurter Ring 81 and 15. These edge computers have two main jobs. The first job is to monitor incoming and outgoing traffic and to read the license plates on incoming vehicles. The second job of the edge nodes is to keep track of the fill state of the parking lot and to publish data about available parking to their associated coordinator agent which is in turn registered on fetch.ai’s Simple Open Economic Framework.
Hardware
- Compute: Raspberry Pi 4 Model B
- Power: Uninterruptible Power Supply (Pi hat) and 1000 mAH Battery Pack
- Connectivity: 4G router with OpenWrt
- Cooling: Heat Sink with GPIO Risers and fans
- Optional Video Output: 7” Display attached to casing with magnets
- Enclosures: Waterproof aluminum boxes that have been modified for cable and camera routing as well as the addition of a plexiglass window for better LTE connectivity
- Various USB A, C, and Micro HDMI cables for routing power and video
The hardware used in the field trials is based on cheap and ubiquitous raspberry pi computers and is intended to provide a plug and play upgrade to “dumb” parking infrastructure. Deployment is as simple as mounting the waterproof enclosures in a position where they have a good view of the entrances and exits of the parking garage allowing them to compute the fill level of the lot by observing the comings and goings of autos on a constant basis. Our computer vision solution uses the OpenALPR libraries to accomplish plate detection, edge recognition, binarization, deskewing, character segmentation, and finally optical character recognition to read out the license plates. This enables the nodes to authenticate autos on-the-fly. Future versions will contain a few hardware upgrade options include ruggedized custom enclosures and an improved embedded connectivity solution. The current version performed admirably and passed the field trial with flying colors.
Software Architecture
The real secret sauce doesn’t really come from the hardware though but rather through the software. One of the most critical design choices we made with M-Zone is to host all the cloud-based portions of the system using a Kubernetes cluster for orchestration. This design choice allows the Postgres database and our swagger API to be deployed in a distributed fashion, running on multiple pods within the cluster. This has multiple long term advantages.
It provides options for redundancy at the data state and application layers across multiple nodes located in multiple geographies and using multiple centralized and decentralized cloud/storage options simultaneously. Currently, our K8 cluster is hosted on an AWS EC2 instance but it could be hosted simultaneously across a number of infrastructures in the future. Another key benefit of this approach is the built-in ability to do auto-scaling the database to match load and available resources within the cluster. Building out the system for the M-Zone field trials would have been a lot easier if we had used a less elaborate traditional architecture without orchestration but we believe the investment will really pay off especially regarding the deployment of the IoT nodes. In our field trial, we only had to manage two parking agent nodes but we plan to scale the system and open source it so that such systems can be scaled to cover entire cities. At that scale, it becomes really critical to have an industrial orchestration system that allows you to deploy devices as fast as you can flash SD cards and then never touch them again. Our use of Kubernetes means that we can push updates to the nodes anytime we need to via an “over the air” 4G connection eliminating the need to interact with nodes physically once they’re deployed.

Your micro incentives and real-time parking lot states visualized.
Software Components (from Architecture Diagram above)
- Parking Agents: The parking agent is responsible for the edge processing. Each one runs as a fetch.ai autonomous economic agent inside a docker container running on a Kubernetes pod which is registered as part of the same cluster. The Parking Agents are responsible for identifying the autos that enter and exit the lot by their license plate and matching those plates against the accounts of registered drivers in a privacy-preserving manner. All the image data remains at the edge to eliminate any possibility for centralized malfeasance and prevents data siloization by design. You can check out our privacy design concept for M-Zone here.
- Coordinator Agent: The coordinator registers as a service on fetch.ai’s search and discovery mechanism for autonomous economic agents (SOEF). This allows for the parking agents to find the coordinator. The agent also has responsibility for dynamically calculating the incentive payments due to the registered vehicles and executing these payments on the fetch.ai V2 Testnet. It also has the responsibility of periodically converting the issued V2 Testnet micro incentives into FET and sending settlement transactions out to wallet holders.
- Settlement Wallet: We built a custom version of our XSC Smart Wallet to handle the receipt of FET settlement transactions.
- Fetch V2 Testnet CLI Wallet & Account Visualization Web App: In order to handle the micro incentives on the Fetch V2 testnet we utilized a CLI wallet and visualized inputs from both our API and from the current wallet state to provide drivers with a real-time view of which parking lots have the most space and provide the best incentives.
- Dashboard: Just for fun we also built a dashboard that provides an overview of the overall system. This is connected directly to the Postgres Database hosted within the cluster.
- API: A swagger API provides the information consumed by the Account Visualization Web App.
High-Level Sequence Diagram

In the above sequence diagram, you can see that the Parking Agent edge nodes continually look for new images provided by our Kubernetes cluster. Next, they search for available agents on fetch.ai’s Open Economic Forum (OEF), the search and discovery mechanism for autonomous economic agents. The OEF returns the Coordinator Agent address to the Parking Agents after which the Parking Agents are able to register themselves with the coordinator. At that point, these agents start scanning for license plates. When they recognize the entry or exit of vehicles, they send a parking event to the Coordinator Agent which acts on the information by updating parking availability broadcast to the wallet via API and also dynamically adjusting the reward ratios and sending the rewards as needed (micro incentives & settlement transactions).
Parking Agent Skills

The parking agents are responsible for all the edge processing. License plate recognition is handled by the third-party library Open Alpr Upon agent instantiation. After the agent starts it performs an OEF search to locate the coordinator node. Once the agent has successfully located the coordinator agent, the agent sends an event packet to the coordinator agent. There are 2 types of events that parking agents can currently trigger.
- Parking events: This event type provides information to link the entrance or exit of autos in the parking agent field of view to timestamps and map those autos to registered user addresses on the fetch blockchain.
- Agent Update: This event type contains a status update from the parking agent. Within its main act function, the agent checks the most recent image saved from the raspberry camera. Any license plates are temporarily stored within the agent memory and deleted following processing. The size of the license plate detected relevant to the frame is also temporarily stored on the edge. Based on whether this frame size is increasing between snapshots or decreasing we can calculate whether a car is entering or exiting the garage. On each iteration, this memory bank is compared with the current image and if the agent detects a new plate, it sends an event update to the coordinator.
Coordinator Agent Skills

The coordinator registers as a service on the OEF which allows for the parking agents to find the coordinator. The agent also has responsibility for calculating the incentive payments due to the registered vehicles. Payments are incrementally made using the Fetchai v2 ledger due to low transaction costs and speed of settlement. Settlement payments are then periodically aggregated at a pre-determined interval to be batched and sent. Through this process, drivers receive payments of FET that are directly driven by their recent driving and parking behavior.
What’s the Economic Theory at Work?
Neoclassical economic models make a great of assumptions that often don’t hold up in the real world. Particularly under conditions of information asymmetry and in areas where public goods and externalities are present, “perfect competition” usually breaks down and inefficient markets are the outcome. This is what we currently observe in the parking market and it’s a big part of the reason why parking in cities is so annoying.
Public goods are defined as goods that are both non-excludable and non-rivalrous. Externalities are costs or benefits that are imposed on a third party who did not agree to incur that cost or benefit as part of an economic transaction. Market-based economies struggle to contain negative externalities like pollution and struggle to allocate public goods such as physical infrastructure because the assumptions of “perfect competition” don’t hold in the real world and markets don’t lead to efficient outcomes in the presence of these real-world issues.
At the risk of glossing over too much economic detail, essentially, in order for anything close to an efficient market for parking to exist, we need much better information. The M-Zone parking liquidity protocol is at its core a machine for improving market information levels and providing market participants on both the demand and supply sides of the parking equation with appropriate nudges to incentivize market participants toward more efficient market outcomes. The result is less CO2 emissions, better utilization of existing parking infrastructure, more efficient permitting processes and less time spent driving in circles looking for parking.
What’s Next for M-Zone Technically?
We’re currently in the process of defining the roadmap for building out M-Zone. The exact steps aren’t yet locked-in but there are some major topical areas that we can say are on the agenda.
- Self Sovereign Identity-based Authentication
- Payment gateways
- Reservation pathways
- Multichain search and discovery
- Hardware “in the car”
- More strategies for mobile agents and wallets
- Improved UI and driver registration processes
Stay tuned over the next few months. There’s much more to come!
M-ZONE: Efficient Smart Parking For Metropolitan Areas
We’ve all been there. It seems like every time you go downtown you end up stuck in traffic and then have to drive in circles for ten minutes searching blindly for a parking spot. Even if you have one of the “digital” parking apps you can only park in a limited number of “in-network” spots. We think we’ve got a solution for this mess. In the video, above you’ll ride along with a real driver during one of our field tests leveraging fetch.ai autonomous economic agents and AI-enabled smart parking garages. Further down in this article we’ll examine the environmental, social, and technical aspects of our “M-Zone Parking Liquidity Protocol” approach to solving the parking riddle in cities.
Currently, Parking is Like Flying Half Empty Planes
Today, the vast majority of parking spaces in cities are locked up in various forms of reserved parking. Much of this capacity is reserved 100% of the time regardless of whether it is needed which leads to parking spaces sitting unoccupied mere meters away from where demand for parking is very high. High demand leads to more parking infrastructure being built. This in turn causes massive CO2 emissions for the building materials required (namely cement which requires 900 kg of CO2 per ton to produce). Cement is the source of about 8% of the world’s carbon dioxide (CO2) emissions. In addition drivers Just in Germany, drivers spend an average of 41 hours a year searching for the elusive parking spot at a cost of €896 per driver in wasted time, fuel, and emissions and the country as a whole €40.4 billion. One of our basic assumptions is that if parking infrastructure must be built it should be used as intensively and efficiently as possible to prevent additional unnecessary infrastructure from being constructed. For this to be possible we need intelligent parking systems that provide the correct incentives and nearly perfect information about usage without sacrificing privacy.
Most people wouldn’t compare parking infrastructure to airplanes but it’s actually a relatively good comparison. We all know that aviation is a major contributor to C02 emissions and airlines make every effort to ensure that every flight is as full as possible including “codesharing” where two airlines sell tickets on the same plane to ensure the flight doesn’t fly empty. They also use dynamic pricing to alter customers’ demand curves for particular flights at a particular time and price. What we’re proposing is analogous in the world of parking. Currently, the world of parking could be compared to flying all the planes half empty all the time and adding more capacity constantly despite increasing costs and environmental impact.
In this context, we can define waste as being any time that parking spaces are empty despite there being demand for those spots. Our Parking Liquidity Protocol allows us to recycle already existing capacity to meet current and future expected demand for parking instead of building new parking infrastructure and capacity.
Bringing the Vision of a Parking Liquidity Protocol to Life
Parking lots need to become aware of their full state and become able to communicate their fill state to users directly over a mobile wallet app AND to automatically incentivize these users to drive and park less by rewarding behaviors that are more sustainable. This vision led us to leverage the fetch.ai blockchain. The fetch blockchain includes “autonomous economic agents” which are essentially AI-powered programs that make economic decisions on behalf of users or machines and then execute economic transactions without human intervention on the blockchain. In partnership with the fetch.ai team, we conceived and built a number of edge computing devices with integrated uninterruptable power supplies, 4G modems for connectivity, and high-resolution cameras that can be deployed quickly and easily at parking garage entrances and exits.

Here we’re preparing the Autonomous Economic Agents for deployment on-site at the Connex buildings.
These edge computing devices (raspberry pi – based) are running computer vision algorithms that allow them to identify license plates on incoming and outgoing vehicles and to calculate how full the parking lot itself is. They are networked together with one another and with a “coordinator” agent which aggregates the information from daughter nodes and determines dynamically which micro-incentives should be sent to any individual driver at any one time. We’ve also built a web app that allows drivers to see the fill status of the lots how much their earned micro incentives, reward rate, and how much this earning rate will be reduced by parking in a particular lot at a particular time. Not parking at all is rewarded most but parking where and when parking demand is low also gets some rewards. Last but not least there is a settlement layer that sums up the micro-incentives that a driver has earned through parking less and parking more efficiently and makes payments in FET tokens to the driver wallet. These tokens are tradeable on the open market and are directly exchangeable for Euros or USD. It goes without saying that privacy by design is at the core of our system architechture.
Critically, these edge nodes are managed by a Kubernetes-based container orchestration system which allows us to do over-the-air updates to the hardware without retrieving it from the field. This greatly increases the scalability of our system because it allows us to install the hardware which provides intelligence to the parking garages once and never touch it again unless physical maintenance is required.
A two-node system has been field-tested successfully at the Connex building complex in Munich. These buildings are owned by Datarella Partner Hammer AG with whom we ready partnered to execute one of the first regulatory-compliant real estate tokenization projects last year (ConnexCoin). The money for the driver micro-incentives comes from the savings of both commercial real estate developers like Hammer AG and their tenants. Now with our system, they have the means to share parking capacity across nearby buildings. Hammer AG alone has 5 buildings on the same street in Munich within the Connex complex so it’s really realistic to encourage drivers to distribute parking load across the neighborhood and walk a few minutes further to reach their end destination.
What’s next?
We’ve got a lot on our plate for the next months. We’re looking to build on the success of the field trials to augment the parking liquidity protocol with a bunch of new components. We’re working on integrating a self-sovereign identity framework to beef up the privacy of our authentication methods. Parallel to this, we’re building out the user interfaces and onboarding processes working with our partners to expand the M-Zone parking liquidity protocol for payment and reservation. On top of that, we’re designing an open protocol tech stack to enable the search and discovery of parking lot ID’s and states in a chain agnostic manner. Keep an eye out for a technical deep dive in the coming days where we’ll get into the nitty-gritty of how the system works!
Building Custom Blockchains – Parity Substrate
Today, we trust Instagram, to keep track of our followers, likes, and chat histories. We trust banks, to document our balances and depots. We rely on Amazon, to maintain the lists of our past purchases. However, by trusting them we give up control and privacy. Slowly we are seeing adoption in Blockchain Technology as a decentralized and user-controlled trust machine. Similar to how banking software doesn’t keep track of your Instagram followers, it is likely that we will see a multi-chain future, in which use-case-specific blockchain networks are used to keep track of domain-specific states. Substrate by Parity Technologies allows for a first principle approach to creating these state machines.
Blockchain As State Machine
How much money did refugees spend in the markets of Jordanian refugee camps last month? #BuildingBlocks
Which stakeholder within the long and complex humanitarian supply currently has custody of the emergency medical supplies? #Track&Trust
Which parking credentials have been issued to my wallet, allowing me to park at the airport car park? #M-Zone
Blockchain technology allows answering the above-stated questions in a trustless manner. Various components are required to allow individual participants of a decentralized computer network to reach an agreement over the state of a system. However, depending on the use case slightly different requirements arise for their underlying components. Some Blockchains need to be more secure, some faster, some more decentralized, some more private, and so on. Developing custom blockchains from scratch, with use-case optimized components, is very expensive. Imagine the costs for finding and bringing together experts of various computer science fields such as distributed databases, P2P networking, cryptography, and so on, to create a new Blockchain.
So wouldn’t it be great if there would a “Blockchain Kit”, which allows building custom, use-case optimized blockchain, using existing building blocks?
Substrate by Parity Technologies
And it turns out, there is Substrate by Parity Technologies, a modular and extensible framework for building blockchains from performant composable modules, called Pallets.
But let’s dive into the history of Party Technologies to get a better understanding of how Substrate evolved. Parity Technologies was founded by Dr Gavin Wood. Gavin is well known in the blockchain space for being the CTO and Co-Founder of Ethereum, cocreator of Ethereum’s Smart Contract programming language, Solidity, as well as its corresponding runtime environment, the Ethereum Virtual Machine (EVM). Since 2015 Parity Technologies built various blockchain clients, like parity Bitcoin, for Bitcoin (BTC) and Bitcoin Cash (BTH) mining, parity Zcash for the privacy blockchain Zcash, and OpenEthereum.
In 2017 Gavin published the Polkadot white paper stating the ambitions to create a heterogeneous multi-chain network, which connects various blockchains. During the development of the Polkadot Network, the engineers at Party Technologies noticed, that blockchains share many components and only some are unique. As a result, the Polkadot GitHub repo was forked to create a framework called Substrate.
So what is Substrate?
Substrate can be described as an open-source community, a modular software development framework, and a developer platform. The substrate framework allows the modular development of fast, secure, and socially scalable blockchains using substrate pallets.
1. Fast
Blockchains build on substrate reached up to 15k transactions per second.
2. Secure
The code of the framework is audited by top-tier blockchain auditing companies.
3. Socially Scalable
One major advantage of Blockchains build on the Substrate Framework is that they are upgradable without causing a hard fork. This is what’s meant by “socially Scaleable”. Hard forks are slow, inefficient, and costly since they require tremendous “cat herding” of node operators. Let’s take Bitcoin as an example. To update the network, the majority node operators, aka. Miners, need to be, first, convinced and, second, install the software update manually to their machines. In contrast, using Substrate, the business logic, which defines the behavior of a blockchain, is stored on-chain in the binary instruction format called WebAssembly, short Wasm. This allows automatically updating the whole network at a certain block height. So, let’s say some supervillain gets his hands on a Quantum Computer and you need to exchange the hashing algorithm of your blockchain for a quantum-proof one. The update can be done by sending a transaction. All the nodes will be updated automatically at a certain block height if they did not choose to leave the network.
The second benefit of using Wasm is that it can be run hardware-agnostic, which is a major benefit for node operators.
Last but not least, Substrate Blockchains are interoperable with each other, as well as with other blockchain networks, like Ethereum, since they can be connected via the Polkadot Relay Chain.
4. Substrate Pallets
Substrate Pallets are the atomic building blocks of each Substrate Blockchain. A collection of pallets result in what is called runtime or simply the business logic of a blockchain. Each Pallet itself contains a domain-specific logic. The cool thing is, developers can discover, use and create Pallets on the Substrate Marketplace. Here are some Pallet examples from different categories you can use for building your own blockchain.
| Category | Pallet |
| Accounts |
|
| Assets |
|
| Consensus |
|
| Governance |
|
| Identity |
|
| Smart Contracts |
|
Conclusion
Substrate drastically reduces the costs of developing use-case optimized Blockchain infrastructure. Polkadot Network, which itself is mainly based on the substrate framework allows connecting these specialized blockchains, granting interoperability. Only time will tell how many Blockchains we will need in the end, but Substrate seems like a promising bridge to a decentralized state-keeping future.
Christmas Countdown with the SmartAid Adventskalender 2020
Admittedly, it’s a German original: The “Adventskalender”. Every year on December 1st, children’s eyes in Germany start to shine – the Christmas countdown starts! This tradition has been going on on for decades. In the last few years, advent calendars have grown more and more elaborate, heating up the greed for consumption.
This year at SmartAid, the team thinks it’s time for an advent calendar that grounds us all in the Christmas frenzy and lets us rediscover the essentials of the Advent season.

As a result, you find here SmartAid Advent Calendar: Every day, starting December 1st to December 24th, you can perform a good deed. With a small contribution you have the opportunity to make the world a little better – by donating for food, school materials, medicine or hygiene.
This is how it works:
- Download the advent calendar as a PDF here
- Print out the pages with the cards and cut out the 24 project cards along the dotted line (optional).
- By scanning the QR code of the respective card with your smartphone (e.g. with the camera app), you will be taken directly to the project page.
- Now you can find out more about the project, set your desired amount with the controller and donate comfortably via PayPal or credit card.

The nice thing about donating with SmartAid: With the blockchain based donation tracker, you can precisely track your donation. You can adjust the amount of your donation yourself!
So, get ready for December 1st – we wish you lots of fun donating!
Ask Datarella: What Are Token Contracts?
The term “Token” is frequently used in the blockchain space. Shermin Voshmgir, the director of the Research Institute for Cryptoeconomics at the Vienna University of Economics, calls them even “the killer application of Blockchains“. This blog post aims to give you a better understanding of what a Token/Token Contract is.
A Token Contract is a special type of Smart Contract, which maps blockchain addresses to balances of value units – aka tokens. These software programs hold code, which specifies a set of functions and attributes of the value units, created and managed by the contract. Just like other Smart Contracts, Token Contracts are:
1. Censorship-resistant and Tamperproof
These computer programs are hosted on Smart Contract platforms, like Ethereum. Therefore, they are maintained and executed by all nodes of the blockchain network at the same time, which makes them censorship-resistant and tamperproof. Once they are deployed to the network, they cannot be changed.
2. Reactive
Smart contracts cannot initiate transactions themselves, they need to be called by an External Owned Account (EOA) or another Smart Contract. Therefore, they are mostly created by EOAs, which are controlled by private keys. However, Smart Contracts can send messages to call functions of other contracts, which allows creating a Smart Contract with another Smart Contract.
3. Controlled by their Code
Unlike EOAs, Smart Contracts do not have a private key. These programs are solely controlled by the code they hold in their persistent internal storage. Their code specifies functions, from which they can read and write to.
Read functions: allow retrieving information from the contract, for example, the balanceOf(account) function, which allows reading the balance of a certain address, or the name() function, which provides the name of a token.
Write functions: enable, surprise, to write new information to a Smart Contract. Most common is probably the transferFrom () function, which allows subtracting from the balance of the sender’s address and add to the balance of the recipient. Another interesting write function is mint(account, amount) which allows, when called, to create new tokens and send them to a specific address, respectively, the burn(account, amount) function, to destroy tokens. Calling these functions can be restricted, so that, for example, only the address which deployed the contract can call the mint() function.
Have a look at Etherescan to check out token contracts deployed to the Ethereum Blockchain. For example, the Smart Contract of the popular stable coin Tether (USDT). As you can see in the image below you can read from the contract, e.g. to see which addresses hold USDT or write to the contract to send tokens.

Types of Token Contracts
In general, you can differentiate between two major groups of token contracts by the properties of the value units they create and keep track of, fungible tokens and non-fungible tokens (NFTs).
1. Fungible Tokens
The value units of these smart contracts are interchangeable. Further, the Token Contract specifies the number of decimals – thus the divisibility of a token. For example, 1.000000 USDT is, divisible to six decimal places. However, one might argue that the fungibility of value units recorded on public blockchains is reduced if the transaction history is publicly available. For example, if certain tokens are sent from an address, which is known for being related to criminal activity, like a hack, they might not be accepted by exchanges anymore and therefore are not fully fungible. Therefore, only privacy tokens, like Monero (XMR), which transaction history is not traceable, can be seen as fully fungible. Another example of fungible value units created by Token Contracts, next to the monetary use case, are equal voting rights represented by tokens.
2. Non-fungible Token Contracts
These token contracts create unique – thus clearly distinguishable value units, which are not divisible. Each token created by such a program has a unique tokenID, which makes it identifiable. Non-fungible tokens (NFT) are often used to represent real-world assets, like art or real estate. Further, popular use cases for this token type are digital collectibles, like crypto kitties, digital art or digital land. Also, an interesting use case is Blockchain Domains, like Unstoppable Domains, which use NFTs to represent “.crypto” domains on the Ethereum blockchain.
ERC – Token Standards
With the rise of Ethereum, Token Contract Standards have been established, which enable wallet applications to hold and manage any type of tokens, complying with the standard. Therefore, the rise of standards allowed for great usability advancements. Ethereum’s standards are titled as “ERC” which stands for Ethereum Request for Comments and refers to a document that specifies rules Ethereum-based tokens must comply with.
ERC20 Standard
The most popular token standard is probably the ERC20, which creates fungible tokens, mostly used most initial coin offerings (ICOs). It is fairly easy to create an on ERC20 contract since it only requires a couple of lines of code. By today, over 333,500 ERC20 contracts are listed on Etherescan.
These Smart Contracts have optional functions, like a Name, Symbol or Decimal, and 6 mandatory functions:
| totalSupply() | Can be fixed or variable. If it is variable it can be calculated and return the total amount |
| balanceOf(address _owner) | Shows amount of tokens held by a provided address |
| approve() | Authorizes a contract to do something e.g. withdraw tokens |
| transfer(address _to, uint256 _amount) | Sends tokens from the total supply to address |
| transferFrom(address _from, address _to, uint256 _amount) | Sends tokens between two accounts |
| allowance(address _owner, address _spender) | Similar like approve but checks for sufficient balance of an address |
ERC721
The predominant standard for Non-Fungible Tokens is the ERC-721 standard. Over 7,500 contracts emitting this type of tokens are listed on Etherscan.
Popular tokens created by ERC-721 are, for example, digital football player cards of sorare, blockchain domains of unstoppable, and also the famous cryptokitties as mentioned above.
Conclusion
Token Contracts are computer programs, which create and manage value units and are deployed to Smart Contract Platforms. These code snippets are at-will programmable and can be designed to fit any kind of use case, from digital currency to collectible. Further, they can be programmed to create self-reinforcing positive feedback loops to bootstrap Web3 platforms and are the basis of any Token Economy. Stay tuned!
M-ZONE Smart City Infrastructure Solution – Open, Decentralized, Self-Sovereign
Datarella, in partnership with Fetch.ai, a Cambridge-based artificial intelligence lab building an open-access decentralized machine learning network for smart infrastructure, announced today the launch of M-ZONE, their smart city zoning infrastructure trials in Munich, Germany. Using their AI-powered software agents to optimize resource usage and reduce the city’s carbon footprint Datarella and Fetch.ai predict mass implementation of smart city infrastructure will result in 34,000t annual CO2 emission reduction.
M-ZONE will be launched in the Connex Buildings and will utilize multi-agent blockchain-based AI digitization services to unlock data and provide smart mobility solutions in its commercial real estate properties in the city center.
“Landlords, as well as the City Council, are interested in optimizing the parking space management, to allow for available parking for all employees of corporate tenants while organizing the traffic flow and preventing commuter traffic jams,” said Michael Reuter, CEO of Datarella. “Our system incentivizes community use of public transport through a tokenized incentive system while reducing the congestion that accounts for a great deal of Munich’s CO2 emissions.”
M-ZONE will solve the needs of various stakeholders:
-
Individual commuters and drivers: save time, money, and reduces driver stress
-
Property owners: simplified approval for new development projects
-
Tenants: lower rent through dynamic parking spot sharing
-
City Council: optimized traffic flows
-
Environment: less negative impact through saved CO2
Upon implementation, AEAs (Autonomous Economic Agents) will support the sustainable and efficient use of city infrastructure in Munich through an application where they will autonomously negotiate the ‘price’ of parking spaces between the holders of parking spots, and those looking for parking spaces. Users can earn rewards in the digital currency if they choose less popular or in-demand parking spaces (or do not use the parking lot at all on some days). The Carpark AEA determines the reward levels to maximize resource usage.
“Fetch.ai provides a decentralized framework for building and customizing autonomous AI agents to carry out complex coordination tasks,” said Humayun Sheikh, CEO of Fetch.ai. “Our vision is to connect digital and real-life economies in order to enable automation over a decentralized network and change the way we use data.”
Users are incentivized to reduce their number of car trips to the Connex and adjacent corporate offices through a reward system which is measured by the utilization of parking spaces. Each registered user who is a regular car park user will be rewarded with a certain amount of tokens per minute for not parking at the parking lot. As soon as a car or its related wallet address is registered as parked by the Carpark AEA, the token airdrops to this wallet stop/slow. The number of tokens rewarded per wallet and minute depends on the current utilization of the parking lot.
“Assuming there is a 10% reduction in car usage across Munich alone, the city would see a 34.000 tonnes annual CO2 emission reduction,” continued Reuter. “Scaled up to cover all of Germany, that equates to 1.7 million tonnes CO2 reduction, annually. This smart city solution has the potential to penetrate huge markets simply by tapping into wasted data and utilizing it efficiently.”
For more information, please contact us!
How to Upgrade an MVP to the Market-Ready Product Track & Trust with the support of BlockStart
Track and Trust successfully completed the BlockStart accelerator program, which initially started in March 2020. We want to look back on the last six months and share how we upgraded Track & Trust from an MVP to a market-ready product.
It all started at the ideation Kick-Off in March, where many startups presented their innovative products and solutions. It was an excellent chance for us to see how so many different companies intend to use blockchain for their services and gave us the opportunity to talk to startups that could be interested in testing our blockchain-based supply chain solution. As it turned out, we would see three of them back in September during the Pilot Stage.
Scope and Implementation Phase
Our goal during the BlockStart accelerator program was ambitious – we wanted to upgrade Track & Trust from an MVP to a market-ready product. After we successfully made it to the next round, we defined our four KPIs:
- Implement an onboarding process in which users can self-register. During the MVP, we created the Keystore files by ourselves and sent it to our test-users. A self-registration process is one of the main requirements in a decentralized system. In addition to that, we also created profiles that are linked to a specific address.
- Enable Multi-tenancy in the system. We want to limit the accessibility of information to only the respective users and their respective data. This increases privacy, security, and provides a clearer and smoother user-journey.
- Make the Track and Trust interface dynamic. There were many hard-coded processes and interface-artifacts developed for the MVP. The contents on the different interfaces should dynamically show the data for the respective shipment.
- Enable mobile-signing. In order to reduce data load and improve usability, we need a mobile app that contains the identity information as well as the private keys of the actor. As a result, handovers can be processed by scanning QR-Codes of the shipment without the need to document this on a computer.
During the implementation phase, we talked with many potential adopters that could perform tests with us in the pilot stage. These talks and the progress of implementation were the main topics in frequent calls with our mentor Joao Fernandes.
Testing with Adopters
After we successfully finished the implementation stage, we had the chance to test Track and Trust together with three adopters that we talked to during the implementation phase. This was Albicchiere, an Italy-based startup that runs a supply chain for refill packages of their wine dispenser, Go Limpets, a Portuguese-based company that sells sea food to the gastronomy, and Zelena Tocka, a Slovenian company whose supply chains manage the production and selling of local agriculture goods.
The objectives of the test were to perform a test with all three adopters through every stage of Track and Trust. As a result, we were very happy to see that they had no issues in testing Track and Trust and that the system would bring an advantage over their competitors. Another main takeaway for us was recognizing the versatility of the use cases Track and Trust can apply.
Take a look at our newest product video of Track & Trust:
The BlockStart accelerator program gave us the best chances to improve our product, get to know potential adopters, and receive valuable feedback that we will implement in the future. We thank the BlockStart organizers, and especially our mentor, Joao, for the smooth and successful guidance and communication during the program, as well as the three adopters for testing Track and Trust.















