TL;DR - Burn Signal is an experiment in distributed preference signaling where users burn ETH to signal their opinion, results sorted according to a weighted social graph.

Burn Signal uses quadratic voting to minimize the impact of plutocracy, BrightID to limit the impact of sybils, and a simple voting method (burning ETH) so anyone can participate. It is intended to help the EIP process but is being built as a general-purpose signaling mechanism that could be used to gauge the Ethereum community's preference for just about anything.

Why?

Because watching people shout at each other on Twitter is probably not that helpful in understanding the Ethereum community’s collective opinion.

Original image: https://www.facebook.com/FrederickJayIllustration/posts/1827426637378969

Ethereum core client development is an informal governance process; ultimately, there are a relatively small number of people with commit access to the core client repositories and they have the unilateral power to commit whatever code they want. The best we can do is try to influence their decision or use different implementations if they make decisions we disagree with.

That being said, several of the core devs have repeatedly stated that they do not want to govern Ethereum roadmap, rather they would prefer to implement the roadmap that the Ethereum community wants. This is particularly pronounced in the case of EIPs that may result in a contentious hard fork with the potential for a chain split.

Outside of the EIP process, there are many other people and projects building products, infrastructure, and standards on Ethereum that could benefit from a clean signal of (dis)approval from the Ethereum community.

The signalling method that has most often been resorted to in the past is coin weighted voting. But most people keep their largest amounts saved in cold storage and are not willing to expose themselves to the risk on continuous internet connections to "vote" in non-binding signalling. Burn Signal side steps this by allowing any mobile or web wallet (including air-gapped wallets) to signal support for initiatives, even with a tiny amount of ETH while maintaining sybil resistance and avoiding the pitfalls of plutocracy.

What Kind of Questions?

You could make a Burn Signal poll for anything you like. But, given that you vote by burning ETH, there is an important consideration; utility.

Rational actors will burn ETH proportional to their value from changing the outcome.

What do participants stand to gain by voting in your poll?

In the case of an EIP, the utility of a poll on whether or not it should be implemented is proportional to these (and likely other) factors:

  • If/how the EIP will affect the value of their assets
  • If/how the EIP will impact things that they find valuable or important
  • If/how much the Burn Signal poll will influence the decisions of the core devs with regards to the EIP

Participation in the poll will involve a trade-off between the predicted utility from a particular outcome vs their predicted utility in utilizing funds elsewhere.

So, perhaps with the exception of those users who derive some disproportionate satisfaction purely from participating, Burn Signal polls will be best suited for questions where participants value changing and outcome that the poll might meaningfully influence. EIPs are a great example of this, since every member of the Ethereum community has some value at stake in the outcome (assuming that core devs take the Burn Signal results into consideration when making implementation decisions).

How will it work?

Contracts

Under the hood, Burn Signal is a very simple application; it is essentially a factory contract. Whenever someone creates a new poll on Burn Signal, the contract spins up a child contract representing the poll. This contract, in turn, spins up several more child contracts representing the options in the poll.

Burn Signal (0x...)
    ↳ Poll (0x...)
        ↳ Yes (0x...)
        ↳ No (0x...)

The reason for each of the child contracts is simply to provide a receiving address for each of the options in the poll. The reduces the friction for participating, since casting your vote in a poll is as simple and cheap as sending any amount of ETH to the corresponding address for your preference.

To make this more user-friendly, we will use ENS domains with the following format so that you can easily cast your vote on any poll from any user-controlled wallet.

Burn Signal (burnsignal.eth)
    ↳ Poll ({pollID}.burnsignal.eth)
        ↳ Yes (yes.{pollID}.burnsignal.eth)
        ↳ No (no.({pollID}.burnsignal.eth)

The receiving addresses for each option have almost no code (they just emit an event) and no upgrade path, so any ETH or tokens received are effectively burned.

function () external payable {
    emit AnonymousDeposit(msg.sender, msg.value, name, option);
}

Application

The Burn Signal application will look like a stripped back version of twitter polls. But rather than user simply hitting the yes or no button, they’ll have to burn some ETH to cast their vote. We will take the on-chain burn signals and interpret them using quadratic voting. Meaning that each individual has rapidly diminishing returns by voting with more ETH.

Aside from the contracts, there are a few core pieces that we will make use of for the application.

The Graph

Our contract contains several events that emit information on the polls being created and their associated voting activity. Since we want all of this to run client-side, our subgraph will allow each client to independently request the data for feeds and polls trustlessly via The Graph.

Thanks to the The Graph's mappings, we should be able to minimize the amount of computation that happens client-side, resulting in a relatively light client.

And finally, The Graph's subscriptions should allow us to create feeds and results that update in real-time without the need to host our own central server or have the client poll for data.

BrightID

To make the quadratic weighting valid, we need to be reasonably confident that each address corresponds to a unique individual. We don't care about or want your personal information, we just need to make sure that no individual can directly control armies of voting accounts.

BrightID uses a modified pagerank algorithm called GroupSybilRank to analyze a connection graph and provide a probability that any user in the context of a system represents a unique individual. This will provide us with a trustless proof-of-uniqueness for voting accounts. All votes (ETH burned at one of a poll’s receiving addresses) that come from accounts without acceptable BrightID scores will be discounted from the quadratic weighted results.

Each voter will need to set up a BrightID profile and make some connections to other users they know and trust. Once they have made enough connections for BrightIDs algorithm to verify them as unique and they have set up an association between their BrightID account and their Ethereum address, their votes will be counted.

IPFS

The frontend will be a React application hosted on IPFS. So Burn Signal will be available throughout the galaxy to anyone with access to the Interplanetary File System!
You will also be able to run the application locally.

3Box

3Box has done a ton of work creating portable profiles and feeds. Where possible, we'll use 3Box profiles and feeds so that we don't have to roll our own.

How will you build it?

As with many projects in the Ethereum space (along with many young projects as a whole), we are somewhat constrained by an uncertain amount of future funding. After winning The Graph and Dapper prizes at ETHNewYork (under the name Zaqar), Burn Signal received a small batch of funding (~$3,000) from Gitcoin Grants Round 3.

Since then, we have applied for grants from the Ethereum Foundation and ConsenSys, and plan to apply for Moloch and Metacartel grants also.

But how do you reward contributors to a project when you are strapped for cash and have no idea if, when, or how much future funding the project will have?

In our case, we have decided to experiment with a novel organization model. Using a colony, all contributions are rewarded with non-transferable 🔥🧧 tokens on a 1:1 ratio with the equivalent USD value of their work.

Upon hitting milestones, the first of which is the MVP launch, the Burn Signal colony will deposit some predefined percentage of its working capital into its rewards pot. It will then distribute the contents of its rewards pot to members, proportional to their 🔥🧧 and reputation balances, using Colony's rewards distribution mechanism.

In this way, participants can be sure that they are getting a relatively fair share of future funding, without Burn Signal needing capital on hand to pay people upfront or having to know precisely how much future funding it will receive.

How can I help?

Burn Signal is a totally open project, anyone is welcome to contribute and earn rewards!

If you want to pitch in:

We are open to all kinds of contributions, not just development work. So please reach out if you can and want to add something to the project.

Thank you Trent Van Epps, Griffin Hotchkiss, and Jack Laing for your comments and review of this post.