How to work collaboratively on token economies? How to leverage multidisciplinary expertise, and integrate team members with most diverse backgrounds? How to apply this expertise and create value for real-world token engineering cases?
The TokenEngineering Community seeks to create an ecosystem of collaborators, funding partners and projects to ideate, explore and verify the building blocks of future token economies. Diffusion 2019 showcases a hackathon as a platform to produce actual outcomes.
Diffusion 2019 setup:
- one dedicated TokenEngineering track
- an industry application case and hackathon challenge from the energy sector, provided by Siemens AG
- 70+ hackathon participants to make first steps in Token Engineering (with backgrounds in computer science, natural science, finance, economics, design thinking, UX…)
- 21 hackers and 6 project submissions (hacking time around 16 hours)
- 2 prize winners
The industry application case: connect2evolve — energy for rural areas
#connect2evolve is an innovation project driven by a team of Siemens AG employees. The aim of the project is to enable socio-economic development in rural villages by providing energy supply. The next step is to conduct a crowdfunding campaign for a Solartainer® — a mobile solar power unit with battery storage and a micro grid — to provide energy for a village in Senegal. Solartainers® are powering communities of more than 100,000 people in Mali already.
The challenge for the hackathon was to offer value for both crowdfunding contributors and future energy consumers, and to „design a mechanism to transfer ownership of the Solartainer® and its future energy production to the broader ecosystem and measuring the effects of doing so.“
Here are the hackathon results:
LastWatt — Smart routing of energy
LastWatt introduces a system to distribute the energy to the most efficient businesses. The challenge: How to incentivize the most productive utilization of energy. In other words, how to maximize the productive output of a limited amount of electricity available to a community.
- Businesses (energy consumers)
- Stakers (community members)
Distributing energy to the most „efficient“ businesses
The “efficiency” of business is a very subjective indicator. The task is to choose the subset of I efficient business from the set of N overall businesses.
If every i-th business gets energy supply Ei and produces a result for community Ri, then the aim of our system is to maximize the total R for the given E. LastWatt modeled this on the basis of the Livepeer dPoS staking model.
Each of the households gets one token and can use this token for staking on behalf of one business.
So, for each step of the simulation (or round), stakers make their choice by placing stakes. For example, one business gets 5% of stakes, the other one 1% of stakes, etc. Each business gets a share of electricity according to the stakes. If a staker stakes his tokens on behalf of a business that (a) provided positive output for the community and (b) was selected as an I-subset of N businesses, he gets part of the business revenue as a reward. If the staker makes the wrong decision, his stake is partially slashed. A staker can change his selection each round.
Model building blocks
- Weather — an input trigger (stochastic variable) that triggers the exact amount of produced energy.
- Business input conditions — a stochastic variable based on random normal distribution indicating the performance of the business.
- The business cycle of the business itself is out of scope in this model.
- Staker’s decision: stakers can select only one business to stake their token. However, a staker can also miss a round.
- Reward/penalty policy (see Staking)
LastWatt was awarded 2nd prize in the Token Engineering track competition — congratulations!
MVP Workshop — impact tokens reflecting energy usage for a rural community
MVP Workshop introduces a model for financing sustainable energy produced by a Solartainer® and for providing value to donors by displaying impact and granting voting rights on a funding pool.
- Contributors/donors (to fund Solartainers®)
- Users (consuming energy)
- Contractors, operators (maintenance)
By donating, a donor is qualified to receive Impact Tokens based on the ratio between his own donation and the sum of all donations. The tokens provide a transparent overview of the impact a donation will have during the lifecycle of the Solartainer®.
Energy consumption, revenue pool and impact tokens
Once a container is installed, energy is produced, and users start purchasing electricity. Users can prepay for electricity by using FIAT or crypto and once they consume electricity, the paid amount will be converted into the DAI and will be saved as Deposited Funds. The amount of electricity that is used by a specific user is tracked by a Smart Meter. The data is automatically sent to the Solartainer®, and based on the kWh used and the price of the kWh (depending on demand/supply) an adequate amount of Deposited Funds (DAI) will be sent to the Revenue pool. Revenue pool shares will be allocated to the Grant Pool and shared between the Contractor and Operator.
In the meantime, while energy is being used and DAI tokens are transferred to the Revenue Pool, an additional process of minting the Impact Token is happening. Based on the Smart Minter data and kWh that are spent, Impact tokens will be minted and distributed to the users and donators (1 kWh = w IT — impact token). The user consuming electricity will receive half of the IT tokens, while the other tokens are distributed to the donors, based on the amount of their donation.
- Enables investors to view the real impact of their donation, while also allowing them to take part in a voting system (incl. MVP on a donation interface)
- Enables users to purchase electricity based on the real-time demand/supply and to decide how collected funds will be distributed (spend)
- The system model (GitHub) explains the flows of value created through energy consumption (information, energy, money) that maximize the usage of the container.
P2P Solar Power Decentralized Exchange
This project introduces a stock market for trading energy between businesses and private consumers in order to encourage productive and sustainable energy usage.
- Hospitals (consuming energy)
- Habitants (consuming and trading energy)
- Businesses (consuming and trading energy)
Priority access for hospitals
In this model, hospitals get priority access to the electricity produced. The remaining electricity is distributed equally among all habitants in the city through a token system. They then have the choice of either using all the electricity themselves or selling the energy surplus to businesses in the community.
Stock market for energy distribution
The goal of this project is not only to provide affordable and reliable energy, but also to help the habitants help themselves by doing business with businesses in the community. Habitants exchange their tokens for money with the businesses on a stock market. In the simulated model, the businesses’ revenues of depend on their number of employees and the percentage of energy needs covered.
The bid-ask between the businesses and villagers regulates itself through the villagers’ ask and the businesses’ bid. Thus, the bid-ask price is defined by supply and demand, as in the real stock market. Since most villagers might not have economic knowledge, automated transactions at the end of every month avoid inactive traders taking up all the storage.
Commissions to fund maintenance and additional production
To pay for the maintenance of the solar panel, the system charges a given commission for every token transaction. If maintenance costs can’t be covered, the money needed will come from donations. If there is money left from commissions, additional solar containers can be set up.
Carbon Credits Club
Carbon Credits Club presents a solution for creating an efficient carbon credit environment where entities worldwide can fairly and transparently showcase that they are carbon neutral entities.
How it works:
1. A South African Karoo farmer easily creates a Spekboom plantation with surplus arid land.
2. The spekboom plantation is represented as a Non-Fungible token (NFT)
3. The spekboom NFT is always for sale. Any entity or person can buy it at any time.
4. Holding a spekboom NFT generates carbon credits.
5. Carbon credits are traded or burned as proof of carbon offset.
6. The Harberger tax received from the entities holding the always for sale NFTs flows directly to the farmers as income and for the upkeep of the spekboom plantations.
7. The farmer generates extra income through the use of their idle land.
(First?) implementation of a smart contract with always for sale NFTs that generate ERC20 tokens over time, sent to the user who holds these tokens.
CommonDEX — minimizing slippage with balancing feedback loops
CommonDEX introduces a balancing mechanism for token exchanges that minimizes average slippage by automatically balancing reserve ratios.
- market makers
Increasing the reserve, reducing slippage for pairs
Market makers deposit tokens (“supported tokens“) that are added to the reserve. For every token deposited, internal Common tokens (CMN) are minted in an amount proportional to the size of the deposit. Every market maker (i.e. every holder of CMN tokens) has a right to vote for the target reserve ratios of the supported tokens.
Higher target reserve ratios causes the exchange rate of supported tokens (eg. token X) to increase. Incentivized by the preferential (exchange) rates of token X, arbitrageurs sell more tokens to the system. Due to the higher amount in reserve, slippage for pairs containing token X decreases.
Rewards for market makers
Every market maker (i.e. every holder of CMN tokens) has the right to vote for a supported token X, thus increasing the target reserve ratio of the supported token.
Each trade is subject to a fee proportional to the traded amount (say 0.3% of the trade, as in Uniswap). Fees from each trade are distributed to market makers who voted on the traded tokens. The amount of fees allocated to a certain market maker is proportional to the votes. If some token X has a higher fees/votes ratio than others, market makers are incentivized to allocate more votes in order to maximize their returns from fees.
A market maker’s overall voting power is equal to the amount of CMN possessed, and votes can be arbitrarily distributed among supported tokens.
Reducing overall slippage
As the mechanism decreases the slippage of pairs with the highest volume/actual reserve ratio, the system converges to the situation where the amount of each token in reserve is proportional to its traded volume – which in turn minimizes the average slippage over all trades. This hypothesis was proven by simulations.
The balancing is based purely on incentive mechanisms, hence it does not rely on external price or volume oracles. In addition, the proposed balancing mechanism is independent from price equations, so it could be used with any market maker model.
Nevertheless, the model needs additional iterations in order to find good mechanisms for listing new tokens, and restricting putting an unreasonably high fraction of its reserves in highly traded tokens with very unstable prices.
TrojanDAO’s mission is to is to create a platform to support decentralised artistic creation. At its core, it offers a continuously minted community currency with a built-in redistributive mechanism governed through a DAO (Moloch Fork): DAICO funding mechanism for a Moloch DAO.
The hackathon challenge was to develop a funding mechanism and verify the underlying assumptions with cadCAD simulations.
- Investors (supplying financial means)
- Artists (supplying work/artistic creation)
- Trojan DAO share holders
Funding through fees on mint, burn and transfer transactions
TrojanToken.sol is an ERC20-compliant token contract with a built-in bonding curve. This token is used as the “approved token” for the Trojan DAO main contract. TROJ tokens can be minted through the contract, which uses a bonding curve as an automated market maker.
The minting process is subject to a 2% DAO tax, where the tax amount is deposited into the Trojan Pool, a follow-on funding contract that mirrors the investments in Trojan DAO. Burning tokens is similarly taxed at 3% to the DAO. Transfers of the token are subject to a 1% “redistribution” tax, whereby the tax is redistributed to all token holders.
Investors provide ETH in exchange for tokens. The number of tokens they get is worth less than their investment in ETH as two fees are applied: a DAO pool tax of 2%, which goes towards replenishing the DAO pool, and a redistribution tax of 1%, which is redistributed to all existing token holders in proportion to the number of tokens held by each holder.
Token holders can burn their tokens to get back an equivalent amount of ETH minus a DAO pool tax of 3%.
Members willing to acquire stakes in the company by supplying work/artistic creation or financial means can acquire shares.
The project demonstrates that the bonding curve based tokens can be used to automatically grant the DAO with funding when it is minted and burned.
The key achievements in the hackathon were:
- to design a system which integrates various processes based on behavioral models and algorithms,
- to describe the funding and governance mechanisms of Trojan DAO in differential equations and set up a model for simulations, and
- to understand the redistributive effects of applying proportional tax rates.
TrojanDAO was awarded 1st prize in the Token Engineering track competition and Silver award Winner of the Winners — congratulations!
Congratulations to all teams for creating amazing results!
A big shout-out to all contributors, mentors and judges for this hackathon: Michael Zargham, Sebnem Rusitschka, Colin Andrews, Billy Rennekamp, Tanja Romahn and Sylvia Niewiem (SiemensAG), the BlockScience team, Onur Solmaz, Stephen Young, Ravi Patel, Jeff Emmett, Griff Green, Geoff LeFevre, Kris Is — and Outlier Ventures, who invited us to hack at Diffusion 2019 and sponsored the TokenEngineering prize!
Our aim is to iteratively work on key building blocks of token economies.
If you are interested in
a) hosting a Token Engineering track at your hackathon,
b) collaborating with token engineers on a specific application case,
c) iterating on building blocks like bonding curves, TCRs, voting mechanisms and decision making processes,