Don't mind the janky sketch :) we'll have more tidy graphics in this post!

This is a living document - expect updates!

21/01/2021

Over the past several weeks, the team has continued to work hard on many components for DatDot - before we get into the meat of this post, I will attempt to summarize what the team has been working on:

• Adding additional factors for our matching engine including:
• "logical"/network latency based location and distance - working on how to solve trust in a hoster’s declared location using latency triangulation. (Nina)
• storage capacity. (Nina + Alex)
• provider quality of service + reputation. (Nina + Alex)
• Working on app frontend/backend tooling around hyper*. (Alex)
• Solving process-cluster management for running simulations. (Alex)
• Building loads of visual components. (Fiona)

and lastly

• Pallet for PoW based Faucet, Referral, and "Onboarding" system. (JAM)
• Pallet for supporting dynamic "trees" of value/reward distribution. (JAM)

... which form a core component, and the "heart", respectively, of our plans for the economic design of the DatDot network.

DatDot Cryptoeconomics

Goals

As a team we strongly believe that technologies are not "morally neutral" and encode the values of their creators, as such we've envisioned an economic design that we want to encourage and incentivise certain behaviours within our ecosystem, specifically -

We want users and service providers in our ecosystem to understand the value of common interests and responsibilities; to have solidarity with one another, and to inherently support one another in everything they do.

We want things that are usually uncompensated, but are in the common good, to be compensated - and we want this compensation to be sustainable and reliable, so that there is reason for people to work towards this common good.

We do not want to encourage monopolistic or rent-seeking behavior, and instead want to encourage generosity and positive-sum behaviour.

We began our design by considering the problem of compensation within the open source ecosystem - the lack of which has led to certain properties of the modern day open-source ecosystem:

• The creation of projects with large scope and impact are generally restricted to being funded by large corporate entities or in exchange for equity and decision-making power given to for-profit entities.
• Popular dependencies are generally undercompensated for their maintainance work, and there is little incentive to continue doing so; there are many offers to purchase ownership of widely used dependencies, which has in some cases led to malware being injected into the dependency tree of a significant number of projects.
• There is generally little incentive to create small dependencies for the purpose of wide reuse - for the reasons outlined above - this favors large projects and teams spinning out dependencies out of their goodwill over hobbyists, for better or worse.

Concept

So we decided that we would create a system with a few properties to allow projects to be directly supported by their users, and pass that support onto their dependencies, with some properties:

• All projects define their own dependencies.
• All projects define how much they want to support their dependencies
• The total amount of support a project can give it's dependencies may be limited, but may also be renewed over time or unlimited.
• The value tree between projects, their dependencies, and contributors, should all be public and available to public scrutiny.

Components

• Streaming Rewards, as an alternative to Deposits & Slashing

All Rewards in the DatDot chain are given directly in response to submitted proof of a successful "job", rewarded after confirmation that your stage in a given process has been successfully completed. There should be no/minimal cost to do these jobs, as any onchain deposit can become an insurmountable barrier to those with no financial access.

Instead we aim to build emergent reputation scores over time (in an as-of-yet undetermined way, but our matching engine is starting to become clearer and will include these scores as a factor) and allow people to onboard more easily by making them do redundant work, which increases network resilience until their reputation has been built.

• Voluntary Solidarity Tax

All cryptoeconomic systems have transaction fees to support the continued operation of the network, but we also recognise that the health of the network is not exclusively a matter of supporting block producers - you need to support the developers of the underlying software, tooling, and ecosystem in order to have a chance of long-term sustainability.

Other projects in the wider system have seemingly settled on a council+treasury model to solve this problem.

We decided against a treasury model as that would neccesitate a privileged class of decision makers determining the direction of funding, and instead we have a model in which users have a mandatory Solidarity Tax that is levied on all of their rewards (they are allowed to go higher than the mandatory rate if they so wish) which is distributed to projects and individuals of their own choosing - as opposed to projects and individuals chosen globally for the entire network.

At some stage we intend to provide APIs to application developers to see their support and tailor experiences to their supporters.

• The Value Distribution Tree

The Aforementioned Solidarity Tax is distributed directly from a projects supporters to it's contributors - at no point in time is value "held" within the value tree by abstract projects* (although, potentially, the weak guarantee of future income coming from supporters can be considered a form of "value" or "wealth" - we instead consider it a form of reputation, and having many supporters is well-earned).

As projects define their dependencies and contributors ahead of time, this value can be routed throughout the tree "depth-first" (so the real contributors are favored over collectives and projects) in a way that still respects the computational restrictions of a blockchain environment.

As will be expanded upon in the implementation section, every reward recipient immediately receives the reward they have not reserved for their dependencies/value tree, and then value is split and propagated down their tree, with limits set on the minimum useful transfer (which is "swept up" and propagates back up the tree).

• Onboarding and Referrals

Onboarding in the blockchain ecosystem is difficult in any case, but is more difficult when the only way to participate in an ecosystem is having to first make a purchase of that ecosystem's currency. There's a fine line between having users onboard via a centralized exchange or DEX, and being beholden to those entities for users participating in your ecosystem.

The alternative is to go back to the roots of the blockchain ecosystem and allow users to do some verifiable work in exchange for currency - this is the entire concept behind our philosophy of streaming rewards, but we still require a mechanism to prevent the chain, which has limited resources, from being overrun by sybil attacks and fake participants.

In order to make sure that any Proof of Work mechanism on our chain is used exclusively for onboarding where there is no other path to do so - we intentionally set the "difficulty" of the work high enough so that it is effectively a waste of time and resources to do so, as a contrast to contemporary PoW systems which must be profitable for the longevity of the ecosystem - we also additionally restrict any tokens created by this mechanism to be non-transferrable and only usable to pay for transaction fees within the ecosystem, ie, for user and service provider registration.

Currently, as will be elaborated in the implementation section, the work done in this process is not "useful" work, but we can make sure that our design is generic over any type of verifiable work, which allows us to change the type of work required on the fly to avoid economies of scale developing around wasteful work (see the Bitcoin and Ethereum networks' environmental and economic externalities as examples of why this is undesirable) and also to change the type of work required to "useful" work.

We also make it easy for people to onboard their own networks by performing work on behalf of users who wish to be onboarded in exchange for an interest-free "loan" that is repaid transparently from a small portion of the onboarded user's rewards via the value distribution system. This gives users who may not have the ability to participate in the other economic activities on the chain the ability to earn some income by finding other users who may be able to productively participate as service providers on the chain.

(And no, it's not "pyramid shaped" because each "referral" in this system is a fixed amount of work and is compensated - albeit gradually over time, and only from earnings of their referred - additionally, the referred also get the same amount of (locked) currency, so it is more similar to the types of referral system you see in fintech, ie, "refer a friend and you both get $50").

• Wealth demurrage

or in other words, a "wealth tax" - the purpose of the wealth tax is twofold, to disincentivise hoarding of our native tokens which would distort their value, which is meant to be directly based on the price of the service provided, and to act as a deterrent for sybil attacks on the value distribution tree - you can set yourself as a dependency, referrer, etc, as much as you want, but you will not "dodge" the solidarity tax by paying it to yourself.

In fact, if projects decide to give rewards to their supporters in the value distribution tree, you will be losing out by not supporting them.

This wealth tax is meant to support the entire network, so should be directly burned.

In economic terms, this benefits active participants and users over those who intend to accumulate wealth over time within the system - in pragmatic terms however, we will likely not restrict users from exiting to external systems, and will most likely even have an onchain AMM-based DEX pairing with a currency that can act as a store of wealth (ie, on parachain deployments of DatDot, this would be the relay chain's native currency) or a currency that can be used to interface with external chains that expect certain behaviours.

and maybe

• Patronage and subscriptions

You know what this is - think Patreon, Twitch, OpenCollective, and OnlyFans - but it would be fascinating to see how recurring subscriptions would interact with our value distribution tree and wealth tax.

"At some stage we intend to provide APIs to application developers to see their support and tailor experiences to their supporters." and this could be generalized over any type of supporter for any kind of enterprise.

Implementation

Current Status

Implemented, pending tests and benchmarks:

• Onboarding

pallet-onboard is a simple and minimal runtime pallet that provides a framework for building what is effectively "collateral free" chain-granted microloans for service providers to onboarding onto the chain.

It can be described as a microloan due to the semantics of the LockableCurrency Trait we use to ensure liquidity/transfer restrictions on tokens provided to users onboarded via the pallet, where locks have a fixed value even if the underlying balance increases or reduces:

1. You Perform PoW as a new user or Referrer and submit it using the create_user extrinsic.

2. You immediately gain some locked tokens, these tokens have restrictions on their use, and can be used for any in-network purpose EXCEPT transferral.

3. (OPTIONAL) once you earn some rewards onchain, you can choose to "close" the "loan" (just to be nice and reduce state onchain) - this will mean your account will no longer have a locked component and your entire balance will be transferrable.

4. (OPTIONAL) if you are a referrer, you will only receive your referral reward over time based on a proportion of your referee's rewards via the value distribution tree. This is to ensure that the refered user is real (from the perspective of providing real value to the chain) and not an attempt by the referrer to perform a sybil attack on the chain.

• Value Distribution Tree

pallet-orchard (as in, "lots of trees") only implements three primitives:

1. "Value Distribution Trees" in the form of "Branches" of destinations that behave like a queue.

2. Abstract "Intercepts" which directly represent a single user, project, or some onchain entity or flow (ie, validator rewards, transaction fees, etc.) - these are the entities that have "Value Distribution Trees".

3. A Trait and Implementation for Interceptable Rewards - the input of value for the "Value Distribution Tree" and API for other pallets to use when interacting with it in most scenarios.

The pallet is used as a base upon which other mechanisms (ie, our solidarity tax and onboarding referral system) are built.

The core of the existing orchard implementation is the value distribution logic, which operates by first:

• "Take"ing Reward destinations from an account's "Branch"es until either 100% of their rewards are accounted for, or all/a maximum number of destinations are accounted for; code.

• Using that information, we, in sequence, create a new default "destination" to bring a user up to the chain-global minimum contribution, immediately reward the user with any percentage that isn't going towards a destination, and then recursively call this method, do_reward, with the destinations as the "user" being rewarded, with their proportion of the reward - reducing the amount reserved for them and removing them as a destination if neccesary.

• Error handling occurs by accumulating failed value distributions (this should only occur if a distribution is smaller than the minimum amount) and passing it back "up" the recursive tree - it then gets redistributed if it is large enough to do so, or continues "up" until it returns to the original user having their reward distributed/making a donation.

Known Potential Issues: Currently, checking for cycles is unimplimented, and recursion is only limited by the minimum size of a distribution.

Skeletons and Specs

• Wealth Tax/Demurrage

A wealth tax can be implemented reasonably by creating a UTXO (unspent transaction output) based token which still implements with FRAME's Currency and LockableCurrency traits.

The wealth tax would then be implemented as a fee, charged on token transfer, which scales based on the age of the input UTXOs of the transaction - ie, the "usable" value of your UTXOs reduce over time based on how long they are "held" - the output UTXOs would then have a new age based on when the transaction executes.

UTXOs should be spent in a "FIFO" manner, ie, the first UTXOs to be created should be the first UTXOs to be spent - although there may be benefits to other approaches, like "spend smallest inputs first".

• Solidarity Tax

Ideation

• Streaming Rewards
• Patronage and Subscription