Privacy-Preserving Airdrops through Decentralized Autonomous Organizations

The Bootstrapping Problem

In blockchain, as in the startup space, every project necessarily faces a bootstrapping problem.

Lacking scalable business models for startups that operate in open-source is also prevalent in the blockchain sector. The only model that has worked in the past has been the ICO model, where teams would sell tokens in exchange for capital. Past that, however, they lack every means to monetize the public goods that they produce in the open. Which means, the only way that open-source projects have made money, thus far, has been through holding some allocation of their own token and through the value accrual of said token.

But how does a token accrue and capture the value that’s generated from its platform? Preceding an efficient market where price discovery is an accurate function of a project’s true valuation, cryptocurrency prices have historically been divorced from fundamentals. But there is something to be said about usage and perceived usefulness of a platform.

So how do blockchain platforms gain the necessary traction needed in order for network effects to occur such that usage develops into a compelling value-capture story for its native token? It comes down to building the right community during a blockchain project’s formative years.

The following is a blog post that aims to find solutions to the Great Bootstrapping Problem of Every Crypto Project There Ever Was.

A Proposed Mechanism for Bootstrapping Early User Adoption

At the outset of every new project’s lifecycle, there is a moment in time when its core team members must arrive at a token supply and break down what percentage of its tokens should go to whom and for what purpose.

The above is an example breakdown of a project’s token distribution.

Notice that in this example, a project chooses to airdrop 80% of its token supply to an existing set of coin holders (e.g. ATOM holders). It’s an extreme example, but this serves as an illustration of how an existing coin holder (e.g. ATOM holder) might double as both A) an initial investor of your ICO/IEO, and B) an airdrop recipient.

Let’s say that a new project wants to raise capital and onboard a mix of investors, some of which are already holders of existing coins (e.g. bitcoin). By committing to airdrop to bitcoin holders before you do a sale, you might sweeten the deal to potential investors who hold bitcoin by offering a variant of—to borrow conventional retail-speak—a “buy-one-get-one-free” model. By virtue of committing to airdrop your tokens to bitcoin holders, where, as it happens, your potential investor holds a lot of, you may attract your earliest investors.

Now extend that reasoning beyond just holders of one coin to holders of multiple different coins. You clearly want to airdrop to the largest and highest quality communities, so let’s now say that your project commits to airdropping to bitcoin, ether, and atom holders before you do a sale. Now what you’re offering is a BOGO deal to holders of each of those coins, of which some potential investors may hold all three. You get the idea.

Fast forward 3 years into the future, and imagine that your community has grown large enough such that it becomes attractive for new projects to airdrop their tokens to your token holders! You then find your token accruing in value because, by this point, the value of your community (i.e. users) has gotten priced into your token.

Airdrops are a spectacularly effective means to attain your earliest believers. And they should largely come from the communities that make the most sense for each project, depending on the landscape of your competitors.

Supernova chain

Supernova chain is a community bootstrapping mechanism that integrates the BOGO model just described through airdrops. It replaces an aspect of a role usually filled by project foundations (e.g. Interchain/Ethereum/Tezos Foundation) with a blockchain that’s secured by a 200-slot set of Proof-of-Stake (PoS) validators.

It takes the act of airdropping to the extreme by dynamically executing airdrops for newly onboarded projects persistently across time. New and already-onboarded projects have the option to commit to airdrops pre-genesis and even post-genesis and do as many airdrops as they want, whenever they want.

See, in detail, what Supernova chain does: supernova.community

Watch a presentation about how Supernova works: https://youtu.be/kwdiGlay5Zs

The Supernova chain works with two types of chains:

The first type is what’s known as a supported chain. A supported chain is any blockchain that the Supernova chain validators must run either lite clients or full nodes for in order to witness events—such as locking—that occur on those chains. The second type is what’s known as a client chain. A client chain is any blockchain project that seeks to use Supernova chain to airdrop tokens to token holders of supported chains.

But why does this necessitate a chain?

The Problem with Airdrops in 2019

The problem with airdrops is, now that the SEC has explicitly outlined guidelines for objectively evaluating the act of airdropping, we know that it can be considered a sale of securities even if there was no investment of money.

“…the lack of monetary consideration for digital assets, such as those distributed via a so-called ‘air drop,’ does not mean that the investment of money prong is not satisfied; therefore, an airdrop may constitute a sale or distribution of securities.”—Securities & Exchange Commission, Framework for “Investment Contract” Analysis of Digital Assets

Despite this, airdrops are still one of the most effective means for bootstrapping an early community of adopters for many decentralized applications.

The Justification for Zero-Knowledge Airdrops

The Handshake Naming System pioneered this notion of privacy-preserving airdrops and really demonstrates the need for providing a buffer between the identities of airdrop recipients and their public keys which may correspond to the tokens that they hold. Handshake does this through GooSig, a new kind of zero-knowledge proof that was developed by Dan Boneh and Riad Wahby (Stanford PhD who works with Dan) for Handshake’s particular airdrop to GitHub users.

The high-level idea of GooSig applies to both elliptic curve-based (EC) signatures and RSA-based signatures. For our purposes on Supernova, we’re only focusing on EC keys. For EC-based signatures, the solution is very similar to Hierarchical Deterministic (HD) keys, which is a magical thing that’s used in Bitcoin to derive a new key from an existing key, deterministically.

To demonstrate how GooSig works, imagine if you have a key and you want to generate a signature using that key, but you don’t want the person who validates the signature to learn anything about you except the fact that you are the owner of a valid key. Then, you need a third party to validate that key. In this case, that third party is Supernova chain.

Because Supernova chain talks to client chains, it can know all of the key holders who are allowed to claim airdrops, as designated by its “clients”. And when key holders go to claim the airdrops, they don’t need to reveal anything about who they are; they only need to prove that they’re allowed to claim the airdrop.

The part where GooSig comes into play is, key holders can only claim airdrops if they own the key that is hidden by this privacy-preserving signature scheme. Which means, nobody has to trust Supernova chain not to go behind-the-scenes and start taking other peoples’ money. In this manner, Supernova lends itself to distributing airdrops in an accountable way such that people can observe and attest that the chain is behaving honestly. But no one can point to who’s claiming the airdrop.

Handshake library for every type of key: https://github.com/handshake-org/hs-airdrop/blob/master/lib/key.js

There are two good ways of doing airdrops that Supernova could adopt (that you are henceforth being asked to provide feedback for). We’ll describe:

Good way, Better way.

A Fork in the Road: Ways to do Privacy-Preserving Airdrops

Good Way: PoA

One good way in which we could implement airdrops in a privacy-preserving manner on Supernova is the easier-to-implement-now yet harder-to-coordinate-in-the-future way. It’s sort of done through Proof-of-Authority (PoA), in which each new client chain’s core dev team must be trusted and must manually instantiate the following 3-step process every time they wish to do a new airdrop.

The Process

The person who’s sending the airdrop generates a token, whereby the “token” is really this hierarchically derived public key. To generate this token, the person must take users’ public keys, process them, and what comes out are anonymous tokens. Nobody looking at the anonymous tokens can learn about the corresponding public key, yet the user who wants to claim the airdrop can prove that they’re the owner. The person who owns the public key corresponding to some token—who subsequently has the secret key—can generate a signature against that token. (Verification) Anyone can take just the signature and the token in order to verify that the signature is correct. In particular, you don’t need the public key that was used to generate the token in the first place. You could run that token generation step (step 1) multiple times and generate one set of tokens to allow people to claim airdrops based on this set. Later, you can generate a whole new set of tokens which cannot be linked at all to the original tokens or to the public key.

This process describes the way in which you could implement the GooSig scheme.

Each project does have to decide ahead of time, before doing any airdrop, who will be involved in that airdrop. This is the part of the process that is very much trusted and very much manual.

Better Way: Decentralized

A better way of implementing privacy-preserving airdrops on Supernova would be the harder-to-implement-now and harder-to-censor-in-the-future way. This way allows the validators of the chain to actually act as a Decentralized Autonomous Organization (DAO) without incurring high coordination costs every time a new client chain wants to do an airdrop. A caveat to this method is that the cost to running a validator becomes incrementally more expensive as more supported chains are added. Say you want to support the Bitcoin blockchain. Due to having to parse Bitcoin script and verify that a user has kept their BTC locked in an outpoint for the entire duration of the lock contract, you must run a full node or else you can’t verify this.

For Ethereum 1.0 and Tendermint chains, fortunately, Supernova validators can run SPV and lite clients, respectively. But if we want to onboard another UTXO-based blockchain such as Handshake, for example, validators will have to run a second full node for Handshake on top of running a full node for Bitcoin.

In implementing airdrops on Supernova in this decentralized way, instead of trusting a person, such as an engineer of a client project, we rely on the machinery that the chain operators could run passively.

The Machinery

Bitcoin locks (draft)

Bitcoin Tx

Output #1

Outpoint: txid/1

Value

Timelock P2SH script

Supernova Tx

Input #1

Outpoint from Bitcoin chain + preimage

Signature

Output

Airdrop value

Eth locks

TODO

Atom locks

TODO

Why a Blockchain for Airdrops?!

Centralized services, by default, always outperform their decentralized counterparts. But when does something necessitate a blockchain, particularly when it’s something so simple as an airdrop?

At the end of the day, you must ask yourself: Do I want guarantees that I could do what I want done without being censored?

If the answer is Yes, then you would start thinking in terms of decentralized solutions.

That is what the Supernova chain provides: censorship-resistance for reaching early adopters through privacy-preserving airdrops.

As such, the argument for on-chain airdropping-as-a-service is really to benefit from the censorship-resistant properties of having a distributed network of unaffiliated operators allocate airdrops for third-party decentralized applications (i.e. client chains).

The key thing is, before a project is capable of establishing a decentralized network, it usually starts out with a core team who acts as the AP, or Active Participant, in US regulator-speak. But over time, this managerial role gets extended to a larger community and the network will decentralize eventually.

However, every decentralized application that is just starting out carries a lot of risk before it ever gets the chance to grow decentralized. TON and Libra are example cases where the SEC intervened with C&Ds in attempts to stop them from launching those networks.

In light of those actions, the Good Way could be potentially…entirely censorable. The SEC could issue C&Ds to client chains which operate within its jurisdiction and stop said projects from performing the manual processing that’s needed before they can issue airdrops through a bootstrapping chain like Supernova.

That leaves us with the Better Way. But since we’re in the early stages of specification, I’d love to hear your preferences after weighing the considerations outlined in this post. Please leave a comment in the thread and your feedback will be factored into the design decisions for Supernova chain.