1/13 As it seems that social graphs are in fashion again in Web3, I would like to share a few of the experiments we've done or observed over the years and the learnings that led to cdf.works and drips.network.

2/13 In 2017, we realized there was potential to use blockchain networks to programmatically share on-chain revenue, either block rewards or fees, with a wider set of participants rather than just block producers. We were not the first ones. @Dashpay was already on it, and @zcash was already doing something similar to fund its core team.

3/13 Our passion for FOSS - the original digital public goods - led us to think that FOSS needs a new sustainable funding model inspired by the above. @cloudhead and I saw an opportunity to introduce a different model to reward software dependencies natively on the internet and we naturally gravitated towards social graphs.

4/13 We shared a manifesto [oscoin.io] and eventually published a paper in 2019 (https://twitter.com/monadic_xyz/status/1108717905527623680) that gathered a lot of attention, praise and criticisms within the Web3 and FOSS communities. The core idea back then was to design a new currency where block rewards would be split between block producers and FOSS projects through a pagerank / trustrank system.

5/13 After running numerous simulations [add link], **we realized that it's extremely difficult to design a permissionless system at scale unless you degrade significantly the user experience**. You either 1. depend on semi-trusted/secure enclave schemes, which I'm not a big fan of, or 2. introduce a trusted set of participants within the network to review projects that are eligible for funding.

The latter is likely ok for some, but beyond theoretical debates about trust minimization, it comes with another very real downside. In a world of increased regulatory scrutiny the trusted set of participants of such a service runs the risk of being classified as the "operators" of the network, which comes with a lot of risk and legal consequences. I am not a lawyer and have no interest to make legal arguments, but that made us move away from similar schemes.

6/13 **Another realization early on was that developers don't want another currency for FOSS.** Most FOSS developers don't enjoy dealing with volatile currencies (unless very established ones like Bitcoin or Ethereum), and that applies to both their income and their expenses. In fact developers don't want to pay with a volatile currency even for a service that they are buying, as **they want predictability on their monthly income and expenses**. As a result, designing a system centered on a volatile currency became a no go for us.

7/13 Additionally, while building a system on a speculative currency has potential benefits, such as the possibility of increased returns, it also requires you to carefully think about the demand drivers of the currency, *especially* if its linked to the security of the overall system. This is something that many smart folks called out on the original paper. I remember specifically the comments of https://twitter.com/milenius and https://twitter.com/MihailoBjelic/ and in retrospect they were right.

[add link to Mihailo's tweet]

8/13 Luckily, we realized that there is a way to design a system where you can support many currencies (stable or volatile), without forcing any volatile currency to the end user. For instance see @ProtocolGuild 1% Pledge which is amazing and I am really happy that it exists!

**Optionality is awesome, forcing developers to a volatile currency for their monthly income or expenses is a bad design decision.**

[add link to 1% Pledge]

9/13 So at some point in 2020 we realized that we needed to follow a different approach. Instead of algorithmic curation of payouts within a graph of participants, **we decided to bring to market what we think is the simplest but also most scalable and decentralized solution to the problem**.

What we did was to design a system where:

✍️ Org members collaboratively curate a list(s) of critical dependencies.

💸 They choose a % of their revenue or assets to be continuously allocated to this list(s) over time.

🏛️ They can modify or adjust the list(s) with any form of governance or curation they want.

🖇️ As dependencies are onboarded to the system, they create their own lists for their dependencies, forming a network of dependencies, curated by people in real-time.

[add visual]

10/13 It's our belief that humans naturally want to collaborate, so what we had to do was to create a mechanism to encourage and protect that. Operating on a transparent and permanent ledger by design enhances transparency and accountability, as projects engaging in selfish or manipulative behavior risk losing legitimacy and, consequently, their financial support.

This is where the core functionality of Drips came from. Projects specify their dependencies on chain. These dependencies form an on-chain graph where capital flows through.

11/13 **The final learning we had was that the word dependency should be used loosely.** Through numerous user tests, we discovered that the dependency view provided by package managers often falls short of reality. It's helpful when it's supporting your decision making but falls short if it's the only view.

Developers rely on a plethora of tools beyond those specified on a package manager. Therefore, a system must accommodate this diversity instead of rigidly tying rewards to a package manager specific file. Rewarding dependencies solely based on a package manager isn't inherently flawed, it inherently restricts reward opportunities, imposes arbitrary decisions, and struggles to scale across languages.

12/13 That's how we landed on CDF and drips.network and this idea seems to resonate with people. [add link to wagmi]

13/13 Finally, a word on attribution: if you are passionate about public goods, giving credit where it's due is more than just good practice—it's essential for fostering trust and recognition within this community. I've been noticing an increasing trend in Web3 where attribution is overlooked when financial interests are challenged. So if you are leveraging someone's work for your project or your "thought leaderhip" don't forget to attribute. Legitimacy matters ;).