*reposting Nina's post from Polkassembly*

DatDot team is building an autonomous hosting network for p2p data systems. Think of it as a Filecoin but for Hypercore protocol, built with Substrate.

Hypercore protocol (started in 2013) is a distributed ledger technology and set of data syncronization primitives with focus on immutable history.

Due to the P2P nature it's hard to have guarantees about the availability of p2p data systems. If we want to keep data available and up to date we have to keep our computer running or we have to rent a server.

Challenges: What if you want other people to help you host your data?

 * what incentives do they have?
 * how to find them and trust them?
 * how to verify they are ‘seeding’ your data?
Solution: A bridge between Hypercore Protocol and Substrate with a built-in incentive model which manages relationships between:

 * hypercore creators/publishers and
 * hosters (who keep data available/host the data)
Our team has been active in the blockchain space for many years. Nina Breznik and Alexander Praetorius have been contractors with the Ethereum Foundation for about 3 years and Joshua Mir has been working with Parity tech and is an active member of the web3 ecosystem, especially Kusama network.

[Please check out our full proposal](https://hackmd.io/@T6Wf5EsOQKe-6wyPjJPtuw/ryBEa-HcK) 

reposting Nina's post from Polkassembly

DatDot team is building an autonomous hosting network for p2p data systems. Think of it as a Filecoin but for Hypercore protocol, built with Substrate.

Hypercore protocol (started in 2013) is a distributed ledger technology and set of data syncronization...

Polkadot Treasury Proposal

JAM (human) 

I'm not yelling at you, I'm yelling at the egregore eating your mind.

DatDot

p2p solution for hosting files with Dat protocol

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](https://github.com/playproject-io/datdot-substrate/tree/wip/pallets/onboard/src)

`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](https://substrate.dev/rustdocs/v2.0.0/frame_support/traits/trait.LockableCurrency.html) 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](https://github.com/playproject-io/datdot-substrate/blob/9563cde44f2847b44a47249f8dd26c576e4867a1/pallets/onboard/src/lib.rs#L114).


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](https://github.com/playproject-io/datdot-substrate/blob/9563cde44f2847b44a47249f8dd26c576e4867a1/pallets/onboard/src/lib.rs#L148).


3) (OPTIONAL) once you earn some rewards onchain, you can choose to ["close" the "loan"](https://github.com/playproject-io/datdot-substrate/blob/9563cde44f2847b44a47249f8dd26c576e4867a1/pallets/onboard/src/lib.rs#L158) (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](https://github.com/playproject-io/datdot-substrate/tree/wip/pallets/orchard/src)

`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.](https://github.com/playproject-io/datdot-substrate/blob/617fe895d756617cb0de8c82a0ec629cbc297eb5/pallets/orchard/src/lib.rs#L46)

2) Abstract[ "Intercepts"](https://github.com/playproject-io/datdot-substrate/blob/617fe895d756617cb0de8c82a0ec629cbc297eb5/pallets/orchard/src/interception.rs#L9) 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](https://github.com/playproject-io/datdot-substrate/blob/617fe895d756617cb0de8c82a0ec629cbc297eb5/pallets/orchard/src/interception.rs#L24) and [Implementation](https://github.com/playproject-io/datdot-substrate/blob/617fe895d756617cb0de8c82a0ec629cbc297eb5/pallets/orchard/src/lib.rs#L129) 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](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L156-L274), 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](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L178-L189).

 * Using that information, we, in sequence,[ create a new default "destination" ](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L191-L202)to bring a user up to the chain-global minimum contribution, [immediately reward the user](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L204-L215) 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](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L217-L267), 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](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L269-L273)) 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](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L103-L117) having their reward distributed/[making a donation](https://github.com/playproject-io/datdot-substrate/blob/d1321e528440dcb984d80b182aabebcc93261c7c/pallets/orchard/src/lib.rs#L86).

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](https://substrate.dev/rustdocs/v2.0.0/frame_support/traits/trait.Currency.html) and [LockableCurrency](https://substrate.dev/rustdocs/v2.0.0/frame_support/traits/trait.LockableCurrency.html) 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





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...

DatDot Economics - A First Proposal

Hello World! 

This is Joshua writing, partially to test out Subsocial and partially to give a semi-informal public status update for people who aren't/haven't been following our other channels. 

DatDot is a set of tools (substrate pallets, a chain [wip], js libraries, and an app) intended to allow communities to create decentralized and automated pinning services for anything using the [Hypercore-protocol](https://hypercore-protocol.org/) (fka. [Dat](https://www.datprotocol.com/)). Dat acts similarly to IPFS, in that it is a distributed protocol for data, but intended for dynamic (instead of static) append-only logs  - which can be used to represent anything from [filesystems](https://github.com/hypercore-protocol/hyperdrive),  [decentralized chats](https://github.com/cabal-club/cabal-cli), and [other data structures](https://github.com/mafintosh/hyperbee)!

We are currently making good progress towards our second grant milestone - but the scope of DatDot has significantly evolved since definition of those milestones, and we're very near completion (as in the complete scope of the grant) on several fronts, especially in our JS service-side code which is already a pretty complete framework and already "just does" what it needs to do, thanks to my awesome teammates. 

What is mostly done:

 * Offchain service logic for hosting, encoding, and distributing hypercores (only pending some optimization and reliability fixes)

What remains of our second milestone:

 * the "milestone-2" version of our pallets and chain, to match [the current code-spec](https://github.com/playproject-io/datdot-service/blob/wip/lab/scenarios/chain.js) -> this is my (Joshua's) Job, so I'm the bottleneck now, yay!
 * simple/alpha-stage onchain "economics"/hosting statistics. -> the remaining parts of this are also mostly bottlenecked on me.
 * improving reliability of our hoster<->encoder communication.

What is being worked on outside of our official milestones:

* Further refinement of our applet interface
* Figuring out how to inject Dat support into any and all browsers securely without an extension (if you aren't using [Beaker](https://beakerbrowser.com/) or [Agregore](https://github.com/RangerMauve/agregore-browser/), among other options in our growing ecosystem)

What I'm doing when procrastinating:

* Hacking the [chain code-spec](https://github.com/playproject-io/datdot-service/blob/wip/lab/scenarios/chain.js) to act as an adaptor for pallet-identity as a key-value store, so we can start testing out the frontend portions of DatDot on any chain with pallet-identity, and give users of those chains access to pinning Dats

Hello World!

This is Joshua writing, partially to test out Subsocial and partially to give a semi-informal public status update for people who aren't/haven't been following our other channels.

DatDot is a set of tools (substrate pallets, a chain \[wip], js libraries, and an app) intended to...

DatDot Today! (tomorrow, and the future)

bafyreiha4wopyflf4hpje3y6zqajxjyv4v6j2ladb62u63tt2jfqwamx5u

bafyreibszje5npqw7t5esb3zlsn56kbqqels66x7m6x5ywwr3qacbchgdy

bafyreibzjaf4nki5dixaqezhkgaokutph4xotnruw3dfqg26ik5uvl76iq

bafyreiayk2b66pkkmodfptc6rjtvwzosjowg2s62iaiplzitcjb75xeyuy

bafyreigbde7nea7s5sbajskruct3ln5zcjd3de2vmy2phw7sg6k2zhaxhu