A solicitation for early community feedback for Supernova chain

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:

  1. 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.
  2. 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:

  1. Good way,
  2. 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

  1. 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.
  2. The person who owns the public key corresponding to some token—who subsequently has the secret key—can generate a signature against that token.
  3. (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.

5 Likes

By talking about “good way” and “better way” you already indicate what is your preference …

Questions :

  • the “better way” does not seem to be entirely specified yet. How much effort would be required to finish the specifications and get an implementation working ?
  • is the “good way”, on the contrary, already specified and/or implemented ? I understand this is the scenario that would be available at Q1 2020 ?
  • is there a migration scenario possible from “good way” to “better way” ? If not, why ? If yes, is there any significant effort required to go from “good way” to “better way”, compared to starting directly with “better way” ?

The point is that both ways are fine; it’s mostly a question of whether people want more censorship-resistance (but longer implementation time) or more reliance on trusted third-parties (and faster implementation time).

And migrations are possible, as long as people are fine with hard-forks in the future. Based on observing sentiments in the Ethereum and Cosmos communities, people tend to be fine with hard-forks. But in the Bitcoin community, people are averse to HFs (for good reason, for Bitcoin).

Interesting idea.

How does it solve the regulatory problem? Even if a group does a privacy preserving airdrop, the SEC can still come after them? What does privacy protection have to do with solving the regulatory problem?

As a potential ecosystem project, I want more simplicity than complexity such that I can focus back to my real works. Using lock-drop to facilitate early community building is just one of the many things the project has to do and I may prefer the good way if the better way will increase so much our time cost which may not be justified.

1 Like

Interesting idea.
How does it solve the regulatory problem? Even if a group does a privacy preserving airdrop, the SEC can still come after them? What does privacy protection have to do with solving the regulatory problem?

If we do it the PoA way, regulators could still step in and tell that third-party (Supernova chain validators) to stop operations and shut down the ones in US jurisdiction. Because in the PoA way, the dev team (in this case, Commonwealth, a US company) will need to manually create new lists of “tokens” to do airdrop for and then generate a new Merkle root for every airdrop instance, and this part is censorable.

Doing it the decentralized way, because validators are running full nodes/lite nodes of each supported chain, the protocol would then be doing the above automatically, and they can’t stop this.

As a potential ecosystem project, I want more simplicity than complexity such that I can focus back to my real works. Using lock-drop to facilitate early community building is just one of the many things the project has to do and I may prefer the good way if the better way will increase so much our time cost which may not be justified.

Definitely. Thanks for your feedback. There’s potentially a simpler way of architecting this chain that I’m thinking about which would only entail the client chain running what’s essentially a SPV in order to utilize Supernova. Gonna write a follow-up post when I have something more concrete.

1 Like

I just watched the Supernova YouTube presentation: https://youtu.be/kwdiGlay5Zs. Highly recommended to understand Supernova!

Great idea - look forward to Stardust.

I am curious about the legal opinion presented on YouTube - that the act of lock dropping won’t create unregistered security. Essentially, it amounts to:

  1. I can start a project, and create a token. Sell some supply, Y tokens, to investors for $X.
  2. Build a team and work on the codebase using the $X raised from investors.
  3. Appear on Stardust Live and promote the project. Promise some supply, Z tokens, as a lock drop on Stardust.
  4. Go live with the chain. People that locked tokens for my project get a supply of Z tokens.

And the tokens are either not a US security OR exempt from the US registration requirements. This is the key hypothesis behind Supernova.

Is there a proper legal analysis of lock drops we could read somewhere?

I would support the maximally decentralized method, since it plays to crypto’s true strengths.
There should be no entity that can interfere with the airdrop process.

Also, Tuckermint will be an early adopter of Supernova, regardless of which route you follow.

Thanks!

1 Like

I have a suggestion on an improvement to the privacy preservation scheme.

So the handshake airdrop scheme works because all Github users are receiving an identical allocation, but if you want to make allocations proportional the amount of coins held on the source chain, then you leak the relationships between the source account on the origin chain and the destination airdrop.

If airdrops are instead packetized, each “packet” can be of fix size and separately blinded from the source chain public key then you can retain privacy while allowing for proportional allocations.

The other thought I had was individually encrypting the random blinding factors for the source public keys. This would allow for non-interactive airdrops. The biggest challenge I see is hardware wallets don’t support doing decryptions with users public keys. This might necessitate choosing blinding factors via user interactions.

Another thing I’m seeing is that instead of GooSig style blinding, BIP44 paths could be used to blind keys in a way that is compatible with existing hardware wallets.

2 Likes

This is really conditional on what else was done with a token. Basically, the idea is you can’t airdrop your way into being a commodity. But if your token is a commodity, then airdropping doesn’t create a security.

2 Likes

Supernova will be an excellent addition to Cosmos Ecosystem. I suggest to divide implementation in two phases. In Phase 1, go with easy implementation and build community. In Phase 2, go for complex implementation which will definitely will take some time.
Cosmos ecosystem have around 100 projects and it will be good for them to have lock drop as early as possible.
Moreover, RNS Solutions is organising Blockchain Olympiad and bringing more developers to the Cosmos ecosystem. We may give challenge to developers for implementation of supernova as well.