Public Artifacts is a social technology studio exploring community dynamics and public goods.

This project builds upon our previous initiative, Codebacks, with the aim of using simple attribution methods to create better social dynamics between web3 developers, products, users, and communities.

Decentralized Frontends

There are a number ideologically aligned and practical reasons why decentralized frontends are necessary in web3. Primarily, they reinforce a core promise of blockchains - resilience - against censorship, single points of failure, performance bottlenecks, malicious actors, and even decaying projects and teams.

But frontends are also the experience layer of applications, with the ability to introduce decentralized applications to new audiences and users with experiences customized for them.

And yet, most decentralized frontends are developed out of crisis, not opportunity.

Incentivizing Community Frontends for Distribution & Discovery

Open Affiliates is a mechanism that allows dApps to reward community members who bring in new users. It borrows from now standard web1 growth paradigms of referral systems which incentivize users and the new entrants they bring in with benefits, and affiliate programs which reward 3rd party publishers for driving a sale, click or registration through their own audiences.

Here's how it works:

• dApps launch a rewards pool: Any dApp, NFT project, marketplace, or DAO can maintain a rewards pool, which can be funded with ETH or any ERC-20 token.

• Optional referrer parameter: The incentivized contract function like deposit, mint, etc. would have an optional referrer parameter.

• Anyone can stake to self-register as a referrer: Any Ethereum address can register itself as a referrer for a dApp. The stake can be slashed for misuse.

• Referrers drive traffic from their own frontends: Referrers host and distribute mirrored or custom interfaces, and build the end user transactions with the referrer parameter set to their registered address.

• On-chain rewards: If a referrer is specified on a transaction and is registered, they receive a reward from a dedicated rewards pool.

See the Github repo here for technical implementation.

Here is a generic example for a DeFi application enabling Open Affiliate deposit referrals:

   function deposit(uint256 amount) external {
        vault.deposit(msg.sender, amount);
    }

    function depositWithReferrer(uint256 amount, address referrer) external {
        vault.deposit(msg.sender, amount);
        uint256 reward = calculateReward(amount);
        referralRewardsPool -= reward;
        referrerRewards[referrer] += reward;
    }

    function calculateReward(uint256 amount, address referrer) internal view returns (uint256) {
        if (!registeredReferrers[referrer]) {
            return 0;
        }
        // Example: 1% reward
        return amount / 100;
    }

The first function shows that deposits can still work as expected, without a referrer.

The second function shows that, if a deposit specifies a referrer, it verifies that referrer is registered, and, if so, moves tokens from the rewards pool to the referrer’s claimable balance.

Versatility Across Web3 Applications

The Open Affiliates system is versatile enough to drive new experiences and adoption through various web3 applications. For example:

• DeFi: Incentivize alternate frontends, aggregators like Idle Finance, and structured products that drive new deposits for underlying protocols.

• NFTs: Curators and other tastemaker sites, like Dave Krugman’s Allships publication, can earn rewards for listing NFTs for mint on their sites

• Marketplaces: Reward users for referring sales or new product listings.

• DAOs: Encourage member referrals to grow on-chain communities like Seed Club and SheFi

• Decentralized Social and Consumer Apps: Reward alternate registration sites that bring new members to your platform.

Addressing Potential Abuse

One challenge with such systems is the potential for abuse, especially Sybil attacks where one entity can act as both referrer and end user. dApps that reward temporary or reversible actions (like deposits) should be aware of potential abuse. Future implementations could incorporate lock periods, periodic snapshots, and other safeguards that have been developed to prevent rewards farming abuse. However, for permanent actions like mints and purchases, this shouldn’t be an issue.

Community-Aligned Growth

Open Affiliates offers a powerful tool for dApps looking to incentivize community-aligned, and led, growth. By rewarding those who bring in new users, we can drive the decentralization and proliferation of web3 apps and experiences.

If you’re interested in testing an implementation, or in exploring these kinds of community dynamics, please reach us in our DM’s.

Public Artifacts is a social technology studio exploring community dynamics and public goods.

This project demonstrates a new primitive for abstracting, monitoring, and rewarding open-source software through citations, inspired by Toby Shorin & Tom Critchlow’s Quotebacks.

TLDR; Codebacks is a simple implementation standard for creating a single global abstraction for reusable blocks of code that enables on-chain attribution, monitoring, and the ability to tip/reward the original author.

Codebacks is an experiment to minimally address some of these challenges in Web3:

1. Increasing smart contract composability

2. Attributing function-level code to original sources and authors

3. Monitoring and measuring the usage and impact of open source code

4. Providing an easy, flexible mechanism for the community to reward the source authors

You can find the proof-of-concept repo here.

You can see the first codeback deployed on mainnet here.

You can reach us in our DM’s.

Composability

Composability is one of Web3’s primary advantages - the ability to use combinations of existing resources as building blocks for new applications. Composability allows developers to do more with less, experiment faster on new ideas, and lean on the collective shoulders of the ecosystem.

When we think of composability in Web3, and open-source software in general, it’s often at the protocol, application, or ERC level. Standards define agreed on behaviors and designs. Protocols and application files are forked and copied to create new code. But even these are built using smaller pieces of code that often appear again and again, reproduced and redeployed by wide swaths of developers.

If open protocols are the “lego blocks” that give Web3 its innovation advantage, these smaller pieces of function-level code are the material that create new blocks.

Abstractions

Abstractions expand available components for composition. In traditional software development, the use of abstractions has driven the increase in the availability, and simplicity, of using existing code to create new programs.

Package managers like npm, yarn, pypi, and functions-as-a-service providers like AWS Lambda have made function-level code widely accessible, but with their own limits. These platforms have enabled the open-source community’s growth tremendously, but, in Web3, smart contract developers regularly resort to ad-hoc methods of reusing open source code, often deploying many instances of the same code to the same blockchain.

With FaaS providers, each function relies on a single operator to maintain its server, usage is often permissioned and usage data is inaccessible, and there is rarely a standard to discover such functions. When traditional package managers are used, they provide useful visibility into developer adoption through downloads, dependents, and forks, but we have never had a clear sight of their end user impact.

None of these systems are built to leverage the benefits of smart contract platforms, like the Ethereum Virtual Machine, with permissionless code on public servers, and accessible, public data.

Citation as a Web3 Primitive for a Global Abstraction Layer

Codebacks provides a design and implementation standard to further the introduction of function-level components on-chain, and the citation standard for usage among Web3 applications.

To start, it’s three things:

1. A citation standard for function-level code use and attribution. Anyone can create a codeback where they would have copied-and-pasted code. By creating a codeback, they create a global resource for future applications. By invoking that codeback from their application, they give explicit recognition to both the code and its original author as a dependency of their own application.

2. An event emitter for each codeback. Each codeback emits events every time its function is called, allowing the community to see a global view of the applications built with each function, and how often that function is used - visualized via event monitoring tools like Dune Analytics.

3. An option to reward the original author. Codebacks accept optional tips in ETH or any ERC20 or ERC721 token, which can only be withdrawn by the trustee address designated by the codeback creator. The Trustee is meant to be the original publisher of the function.

Codebacks’ basis on the EVM provide a number of benefits:

• Like package managers, anyone can compose with a codeback, with the added benefit of allowing a component to live as a single instance, without needing to be downloaded and installed with each application that invokes it.

• On-chain usage data can be publicly used and monitored by everyone, making it easy to see how small bits of code propagate through the open-source ecosystem, and recognize impactful pieces of code.

• A standard event naming and structure make them publicly discoverable and indexable, creating a compendium of useful code for the ecosystem.

• By having public data on usage, and the original author/source as a defined trustee, it creates a strong mechanism for attributing and rewarding open source developers for the end user impact of their creations.

How it works

At a high level, Codebacks works by breaking a reusable block of code out into its own smart contract with a series of helper functions that let it work as a public function-as-a-service contract on-chain.

In practice, it looks like this (see code examples here):

1. A developer finds a function in another project’s contract that they’d like to use.

2. They create a new codeback contract for that function, creating a global abstraction which can now be called from their application and from other applications by other developers.

3. To invoke it, they use a codeback citation in their project code via an import declaration pointing to the new contract (instead of a copy/paste of the function itself)

4. Some projects may make money, and may choose to give a small fee/tip to the sources of their code, or they may simply wish to reward the work done by the developers. Codebacks enable an optional mechanism for reward via a programmable tip to the source author’s wallet.

Finally, since Codebacks are on-chain and have standard naming conventions for their event emissions, public usage monitoring is available for each codeback, and all codebacks can be indexed together for better discovery and use through tools like Dune Analytics.

Codebacks is an experiment in community-led development. If you have any thoughts, we’d love to hear from you. If you’re building something new in Web3, consider contributing to the community codebase with Codebacks.

https://twitter.com/publicartifacts