Here we drill down into the details and the ending:

The Fairdrop was a portion of the quarter of 100 Million $BRIGHT that made up the initial minted supply (25 million). High level composition of the Initial minted supply consists of allocations for Bright DAO, Past actions, and Initial Incentives.

The Fairdrop consisted particularly of the Past actions allocation (6.85 million).

Starting on September 16, 2021, Fairdrop took place in 8 rounds. Claims could be made on either of the two networks — Main-net or Gnosis Chain (formerly xDAI).

89.4% was successfully claimed. Of the remaining 10.6%, most were allocations to Gitcoin projects(non-individuals) that benefited in trust bonus matching due to BrightID enabled donors. Some of the remaining were those who missed linking their BrightID with the fairdrop DApp in time.

These missed claims will be swept to BrightDAO common pool and will be spent on funding future tasks and projects proposed and passed by the community.

Considering the size of successful claims, the fairdrop was a great success. This is just the beginning and we hope to achieve similar or better success in the future.

Fairdrop DApp

The Fairdrop DApp used in the fairdrop is one of the many strong use cases of BrightID. It had been in development on the side for some time prior to the fairdrop as a generic product for any individual, project, or community to use for their airdrop.

The term fairdrop simply means that an airdrop is per individual rather than per address.

We learnt a lot about improving it through the BrightDAO fairdrop experience and it has been very encouraging to see how well it performed as intended in its earliest form.

Further development of the product will now be in the hands of the BrightDAO community. We heartily welcome any individuals, projects and communities that wish to further develop and utilize it.

Among the possibilities, it would be wonderful if we could make it the portal for perpetual airdrops, and it would be a game changer especially in terms of fair and wide distribution for onboarding new users to web3.

The project is open source on Github:

• https://github.com/BrightID/fairdrop
• https://github.com/BrightID/fairdrop-backend

BrightDAO Fairdrop 1 Retrospective was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

BrightID tackles the problem of Sybil (duplicate account) attacks. By developing a public graph, BrightID has brought about an infrastructure in which different algorithms can be tried to counteract such attacks. Applications will choose what algorithms suit them best to verify their users.

Bitu is the first graph-analysis-based verification method that BrightID offers. The nodes inside the main regions of the graph get verified by Bitu. It recognizes nodes outside the borders of those regions as Sybil accounts. This verification method is based on the fact that when a graph is drawn using Force-directed algorithms, Sybil accounts are pushed away from the main, dense regions to the borders. The reason is that Sybil accounts can not make a significant number of connections with honest ones and can only make connections with each other. That is why they get pushed away from the main regions to the surrounding districts.

In current seed-based algorithms, there is a small number of highly trusted nodes called seeds which have the power of verifying users. Because nodes are verified on the basis of their proximity to the seeds in the graph, such algorithms are very vulnerable to attacks from seeds.

In Bitu, however, there is no seed. In fact, every node is a seed and can verify others as long as they remain in the main regions of the graph. While seed-based methods rely on a minority of highly trusted seeds, Bitu relies on a low-trusted majority.

Can BrightID scale while maintaining security against Sybil attacks? We have been frequently asked, as Vitalik Buterin did in “Gitcoin Grants Round 7 Retrospective”:

BrightID is going to face a tough challenge making it reasonably easy for regular users to join but at the same time resist attacks from fake and duplicate accounts. I look forward to seeing them try to meet the challenge!

Verification based on the help of a small number of highly trusted seeds gives users a hard time getting verified. On the other hand, increasing the number of seeds decreases the security of the network against attacks.

Relying on a majority of low trusted nodes instead of a minority of high trusted ones known as seeds enables Bitu to maintain scalability while ensuring security. Bitu enables users to get verified easily through making a single connection with one of the users in the main regions. Thus BrightID can scale its network. And if a user in the main regions tends to create a significant number of fake accounts to verify them by making connections with them, the fake accounts get pushed away from the main regions and even the attacker will get unverified. This prevents large-scale Sybil attacks and guarantees security.

Moreover, Bitu can tackle small-scale Sybil attacks; it enables apps to verify users based on the number of connections. For instance, Gitcoin may require users to have at least 10 “Already known” connections in Bitu. So the higher the required number of connections is, the more secure the app gets. This makes it too hard for Sybil accounts to make enough connections without getting out of the main regions.

An example helps clarify how it works. User X wants to create 10 fake accounts in order to use them in the Gitcoin application. If Gitcoin requires only one “Already known” connection for verification, user X with strong connections to the main regions of the graph can drag those ten accounts into the main regions without the risk of getting out of the main regions. However, if Gitcoin requires ten or more “Already known” connections for verification, user X needs to either connect these ten fake accounts to honest users or connect these ten accounts to each other to reach the minimum required number of connections. Note that honest users don’t make connections with unknown accounts as “Already known” and connecting those ten accounts to each other causes all these ten accounts to get pushed away from the main regions of the graph and get unverified.

Bitu is the first method that tries to tell bots and fake users from real ones through the viewing of the graph. The BrightID graph is available to the public, and everyone can easily distinguish the main regions and the borders by looking at the graph. You can log in to the BrightID explorer and see your own and your connections’ location in the graph. Refer to our Gitbook for more information on how to get verified in Bitu.

What is Bitu Verification? was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

Reaching the Next Milestone in Counteracting Sybil Attackers

The development of BrightID began three years ago with the goal of providing a decentralized platform for applications to ensure the uniqueness of their users and counteract the attack of bots on their applications. We believe that the only decentralized, scalable, and reliable way to detect humans from bots in the future of cyberspace is to rely on the social relations of humans.

From the beginning, BrightID was supposed to distinguish real users from bots and verify them by analyzing the graph formed by connections that users make with their friends and family members. However, the graph-analysis-based verification methods can only be used if there is enough data covering them. It is not possible to use such verification methods unless a graph of a significant number of users who have connected with at least a small number of friends exists. That is why BrightID had to make use of another verification method to verify its early users in the initial stage although that method was not reliable and scalable.

Joining connection parties and making connections with a trusted person who hosts the call was the initial verification method that BrightID used. In this stage, BrightID was like a newborn fed on milk. As milk is the only suitable food for a newborn to grow in the first stages of growth, the only healthy way that BrightID could grow enough was to rely on the Stars in connection parties to verify users. And just as milk is not enough for newborns to grow as they age, BrightID cannot grow by only relying on stars. And just as humans always use milk as nutritious food, using stars can always be a basic verification method in BrightID.

Today, we are proud to announce that BrightID has grown enough to start using graph-analysis-based verification methods. BrightID has more than 30,000 active users, 10,000 of whom have made 4 connections on average with the people they know in person. That is why BrightID can now start to use other verification methods. Soon BrightID will be making use of various verification methods, the first ones are Aura and Bitu.

BrightID Verification Story was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve grown. At 30,000 sponsored users, we need to imagine more clearly how a decentralized proof of unique human system can manage itself.

We need to imagine our movement as a collection of teams self-organizing and rallying to contribute: verification helpers, anti-sybil researchers, user-experience experts, and many more.

A DAO powered by 1Hive Gardens and Aragon technologies is the best structure to achieve this.

$BRIGHT is the token that makes BrightDAO work.

A fairdrop and ongoing fair distribution mechanisms (think BrightID-enabled faucets) are the best ways to allocate $BRIGHT. (A “fairdrop” simply means some or all rewards are given per person instead of per address.)

We’ve written several guides to help explain $BRIGHT, BrightDAO, and the BrightID-enabled fairdrop process.

• $BRIGHT guide
• BrightDAO
• $BRIGHT fairdrop

Launch Party / AMA

Still have questions?

Today at 11:00 a.m. Pacific, CurlyBracketEffect of RabbitHole and DAOnToEarth podcast fame will be our MC to introduce us to the wonders of BrightDAO and $BRIGHT.

Join us on our discord stage for this epic gathering.
* BrightID discord

BrightDAO is Here! was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s go into each of the six milestones in a little more detail.

🔬 Node discovery. How does a client (for example the BrightID app on your mobile device) know which node in the BrightID network to connect to? After this milestone, clients will be able to find out about other nodes from a small list of hard-coded “seed” nodes. If seed nodes trust other nodes, they’ll be added to the list. Then clients can use a “promise race” and other data to find the best node to connect to.

👩‍🔬 Anti-Sybil: Stronger connection types. You may have noticed there are different connection levels in BrightID. Different connection levels create different graphs of users. The goal is to have a verification that uses the very strong “recovery” connection level, which real people only assign to others they trust enough to help guard their BrightID against theft or loss.

🕵🏽‍♀️ Blind signatures. Currently, BrightID nodes store mappings between anonymous identifiers used by apps and BrightID identifiers so that an app can query about someone’s unique verification using their own identifiers. (BrightIDs are not shared with apps.) While this structure makes it less likely that a data leak could reveal information from one app to another, we can do even better. With blind signatures, we can remove this mapping completely. This simplifies the architecture and makes the system even more immune to data leaks.

📲 Client portability. We’ve already created the necessary features in the node API for a user to install BrightID on multiple devices and backup or recover their BrightID using another device, but would be hard to implement this without an example. We’re going to build a web version of BrightID that supports these features so that others can use it as an example to make their own BrightID clients.

💉 Anti-Sybil: attack modeling and injection. We’ve already created a great platform for modeling sybil attacks and comparing the results of different algorithms or parameters. In some approaches to sybil-resistance in social networks, there is a manual review step, and the algorithm is used to prioritize accounts to review. As a pseudonymous network, BrightID prefers an automated way to define the line between sybil and honest users. We can do this by automatically injecting modeled attacks into the real graph and measuring their rank against previously measured nodes.

🛡️Node Security. BrightID nodes have already gone through a hardening process, with sensible rate limits in place by default, but we want to take another pass at this. We also want to create API contract tests to make sure our node API and reference docs match. We will also audit the use of digital signatures and secure message passing.

BrightID 2021 Q2 Roadmap was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

We created IDChain to synchronize BrightID node operations, but its unique qualities make it an attractive platform for other projects. We’ve been using it for several months, and it’s ready for other projects to use.

Features

• Short block intervals.
• Every verified unique human gets a lifetime supply (average) of gas.
• Validators (the proof-of-authority equivalent to miners) can be democratically elected. The top proposal is to use delegated proof-of-stake with quadratic voting to lessen the voting power of whales. This is possible with BrightID.
• Validators get paid a modest salary by BrightID Main DAO, instead of gas fees (which are instead burned). This ensures that validators are aligned with making IDChain usable by the masses, not making a profit.

Start using IDChain

IDChain is ready to use right now. Follow these steps to receive your free supply of Eidi (the native gas token) and start using IDChain with Metamask.

Eidi

Eidi is the native gas token on IDChain (similar to Ether on Ethereum). The lifetime supply is designated by validators to match what they believe an average user will spend on transaction fees. If a user spends more, they need to buy Eidi from a user that spends less.

What can I do with IDChain?

Launch a cheap Aragon DAO

BrightID and IDChain itself use DAOs on IDChain for governance. You can start making Aragon DAOs at aragon.idchain.one with your lifetime supply of Eidi.

Move tokens between Mainnet and IDChain

We’ve implemented the excellent bridge from PoA to create a way to move tokens between Mainnet and IDChain. The bridge is at omni.idchain.one.

Easily run a node with DappNode

IDChain is in the public registry in DappNode, so go ahead and spin up a node with DappNode!

Explore blocks and contracts

IDChain comes with the excellent open-source block explorer by PoA called blockscout, which you can check out at explorer.idchain.one. Just like etherscan, blockscout lets you view and interact with verified smart contracts, such as the one that distributes Eidi.

What is proof-of-authority?

A proof-of-authority blockchain uses authorized individuals to sign blocks and stake their real-world reputation. This approach was pioneered by Parity, which created the Aura algorithm. A lot of great tooling was created by PoA Network. (We are using blockscout and PoA bridge.) They have also written great articles on proof-of-authority, such as this one.

Future Plans

Anyone can port DApps and contracts they like from Mainnet to IDChain. Some features we’d like to see:

• Bridges for other tokens besides DAI. Arbitrary message bridges.✔️ BrightID now has AMB and a token omnibridge.
• Various ways to vote: liquid democracy, ranked choice, quadratic voting, conviction voting. Citizens of IDChain should have many options for democratic participation.
• Decentralized exchanges. Update: Swap on IDChain 🦄.
• Other DAO-like platforms, such as Colony.
• Anything you want!

IDChain Governance plans: request for comments.

**UPDATE**
Moloch DAOs can now be created with a simple GUI interface via Daohaus. Simply connect your wallet to IDChain and summon a DAO. It will suggest WEIDI (wrapped EIDI — the gas token on IDChain) as the primary token.

Please see our github repo for more information.

Get In Touch

• Discord (chat)
• Twitter
• Web form

Introducing IDChain was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

We’ve explored Sponsorships in three articles (1, 2, 3). In this one we’ll look at Sponsorships and Subscriptions in terms of the value they offer applications integrating with BrightID.

According to the BrightID whitepaper, there are two main reasons an application would want to buy Sponsorships:

1. To acquire new users.

One of first tasks for new BrightID users is to link their BrightID with applications. They do this from the “Apps” tab. Since the first app they link with will need to sponsor them, apps that have Sponsorships will be listed at the top.

We’re also creating an apps site to display the growth of BrightID in terms of users and applications. We want to show which applications have the largest influence on the network. Here also, applications with the most Sponsorships will rise to the top.

2. To decide how BrightID funds are used.

BrightID’s funds come from the sale of Sponsorships and are governed by BrightID Main DAO.

There’s no expectation of profit from Sponsorships or governing BrightID (BrightID Main DAO managers are unpaid); it’s a matter of deciding how the money is spent. Obviously, there’s potential for conflicts of interest, which is why the managers should represent many projects that can keep each other in check. Indeed, the constitution of BrightID Main DAO mandates that no group of managers with a shared external affiliation should compose nearly half of the managers.

Because the price of Sponsorships is capped, there’s a lot of potential value in unique verifications that isn’t captured. An application that pays for a small portion of that value can help decide how to direct money to improve the verification process in the future.

Subscriptions explained

Now that we know why an app would want to buy Sponsorships, we can understand why it would want to buy Subscriptions. One Subscription produces 252 Sponsorships over six years. The rate of production increases every year according to the chart below. Since the first 400,000 Subscriptions are on sale for $1 DAI each (the same cost as one Sponsorship), this represents a large savings.

Many apps have aspirations to grow rapidly, but don’t have up-front money to pay for the users they intend bring in. This is exactly where Subscriptions can help. Subscriptions generate a stream of Sponsorships that matches the exponential growth pattern to which a new application aspires.

In the future, there will be enough large, well-liked, and well-funded apps integrated with BrightID that users should have an easy time finding one they’re already using to sponsor them. BrightID will no longer serve as an advertising channel for smaller apps — only apps with many users will be able to garner the top spots in BrightID lists. Smaller apps that have unactivated Subscriptions or unassigned Sponsorships from Subscriptions can resell them to larger apps.

Since BrightID Main DAO only plans to sell 900,000 Subscriptions, future applications won’t have the option to buy them, but those with aspirations to grow quickly won’t face the same challenge of finding Sponsorships because there will then be plenty of large apps willing to sponsor new users. (Users only need one sponsorship per lifetime and it’s good across all apps.)

Subscriptions are therefore meant to attract apps that aspire to grow rapidly and want to take advantage of large discounts for being first.

Both Sponsorships and Subscriptions are on sale via the Sponsorships Dashboard. More information about the sale and the dashboard is available on this page.

Get In Touch

• Web form
• Discord (chat)
• Twitter

What value do Subscriptions (Subs) have for applications? was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

Overview

An application using BrightID can choose at most one of the following for its users.

1. Anonymity within a group of participants. (No one — not even BrightID node operators — knows which BrightID maps to which participant.)

2. The ability to re-register with an application; i.e. if an account becomes unrecoverable, a user can register to use the application again. To avoid abuse, there is a permanent link between the lost account and the new account.

In this article, we’ll focus on the first option and show how to use BrightID with applications that provide anonymity within a set of participants. In these cases, participants perform one or more unconnected actions (for example, votes), and there’s no need for an “account” or “profile” to provide a history of connected actions. In such cases, the possibility of re-registering with a new account connected to one’s previous account isn’t useful — and by disallowing it, anonymous participation becomes possible.

The solution uses Ethereum and a privacy mixer that accepts custom smart-contract-based (e.g. ERC-20) tokens. The use of MACI to provide privacy and collusion resistance is briefly discussed.

BrightID nodes do not store any personally identifiable information, only unique identifiers (i.e. BrightIDs). This article shows how to keep users anonymous even if third-party applications leak information.

Setting up Anonymous Participation

Create a Context

An application can have its own context with its own set of unique users, or it can share its context (and user registry — see below) with other applications.

To create a context, an application chooses which BrightID nodes will administer the context and provides them with the following:

• Name of the context
• linkAESKey (32 bytes). Used by nodes serving the context to privately share information with each other when a user links their BrightID to a contextId.

Create a User Registry

All users that will take part in anonymous actions within the new context should now link their BrightIDs to a previously unused Ethereum address as the contextId. This is as simple as creating a deep-link of the formbrightid://link-verification/<node url>/<context>/<ethereum address> for users to open in their mobile browser. The link is stored on BrightID nodes serving the context.

Distribute Action Tokens

The context creator should create and deploy a smart contract that implements the IBrightID interface. We’ve provided an example smart contract. Users can submit signed verifications obtained from a BrightID node’s /verifications endpoint to the smart contract. If a submitted address hasn’t been used (i.e. there are no previous addresses in the signed array, and no matching address in the smart contract storage), an action token should be minted for that address.

Mix Action Tokens

Although contextIds provide a middle layer to limit the visibility of BrightIDs, there is still a privacy weakness: BrightID nodes serving the context know which BrightIDs correspond to the newly created Ethereum addresses (contextIds). If an action token holder were to now use their token, BrightID nodes serving the context would see which BrightID is associated with each action.

To strengthen the privacy further, the tokens should be sent through a mixer and received into fresh Ethereum addresses. Now users can complete actions — limited to one per unique human — without associating them (even indirectly) to a specific BrightID. Not even BrightID nodes serving the context can tell which BrightID is associated with an action; they only know the set of action-takers (i.e. which BrightID are registered in the context).

Reusing Action Tokens

An action token can be reused for multiple actions with the following caveats:

• A user’s “unique” status in BrightID may have changed between actions. (They may have been flagged as “fake,” “duplicate,” or “deceased” and removed from their primary group.)
• The actions of a single participant will be anonymously linked to each other unless a mixer is used between actions.
• A user that loses access to their action token will be unable to participate until old action tokens are retired and new ones issued.

Collusion Resistance

Mixing action tokens helps with privacy within a set of participants, but is not immune to collusion (e.g. vote buying). MACI (Minimal Anti-Collusion Infrastructure) precludes many forms of vote buying by giving a person being bribed a way to generate fake proofs that are indistinguishable from real ones. Because of the possibility of receiving a fake proof, a briber can’t know whether or not a bribe succeeded.

MACI conceals the links between actions and actors using zero-knowledge proofs. It could therefore take the place of action tokens and mixers while providing extra defenses against collusion.

Thanks to Aleeza Howitt for the suggestion of using a privacy mixer to simplify the integration of zero-knowledge proofs, and to Barry Whitehat, Koh Wei Jie, and Vitalik Buterin for chats on privacy and MACI.

Contact

* BrightID
* Discord (chat)

Anonymous Participation (e.g. voting) using BrightID was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

Update: The latest guide to Social Recovery is here.

Social Recovery is Easy

BrightID uses social connections to prove your uniqueness to applications — and to recover your account to a new phone.

We’ve made setting up social recovery easy because it’s important that everyone does it. It’s the way to recover your BrightID if it’s lost or stolen. For now, it’s also the way to move your BrightID to a new phone.

This article will walk through how to use this important feature.

Setting up Recovery

Choose your Trusted Connections

Once you’ve made three connections in BrightID, you’ll see a notification.

Tap it and you’ll be able to select three or more “Trusted Connections.”

You can choose anyone among the connections you’ve already made. Make sure to choose people you can trust to be in charge of your BrightID.

Backup Names and Photos

The next step is to choose a password you can remember. This step only backs up the names and photos of your connections. The password encrypts the backup so that only you can recover it.

Recovering your BrightID

If you need to restore your BrightID to a new phone for whatever reason, follow these steps.

Start Recovery

When you first install BrightID, you have two options. In this case, you’ll choose Recover BrightID.

Trusted Connections

You’ll need two of your trusted connections to scan the code. After the second successful scan, your BrightID and connection photos and names will be restored.

The BrightID on your old phone will now be blocked from performing any actions on your behalf.

Get More Help

To get help and meet other users, register for a BrightID meet or pop into our discord or telegram.

BrightID’s Social Recovery was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.

In a previous article, we saw how Aleeza, Philip, I, and others arrived at “sponsorships” as the preferred sustainable method for funding BrightID. Now I’ll add my thoughts on why we’re using sponsorships precisely the way we are.

First — as a recap — what are “sponsorships?” A sponsorship entitles a user to share their proof-of-uniqueness with applications. It’s paid once — by an application — and is good for the lifetime of the user across all applications. We set the price at $1 DAI (subject to increases to keep the true cost stable, as approved by BrightID Main DAO). We set the cost low enough to not be a burden to anyone while allowing BrightID as a public good to be continuously funded. It’s not burdensome to users because it’s paid by the apps they use. It’s not burdensome to apps because it has a value for apps that I’ll discuss later.

Why Opt-in?

The sponsorship system is opt-in. If an application doesn’t find sponsorships valuable, it can choose to create its own front-end for managing users’ BrightID keys, and run its own nodes to analyze the BrightID social graph. Funds collected through the sale of sponsorships go to BrightID Main DAO, which uses its budget to grow the BrightID network, research new graph analysis and privacy methods (including subsidizing users who run nodes), and develop new front-ends and use-cases for BrightID. An application that doesn’t opt-in can’t be funded through this method; it has to figure out how to fund itself.

Besides being eligible for funding through the BrightID Main DAO, applications that opt into the sponsorship system can benefit more from the network effect of other apps that bring in users. A person that started using BrightID to gain access to a certain app will soon find an array of other apps they’re already verified to use. If a certain application didn’t have the funds to buy enough sponsorships for its users, it can simply send them to another application that does. This benefits both applications: the first receives the benefit of having its users verified through BrightID for free and the second receives the benefit of new users trying it out for a very low user acquisition cost ($1 DAI).

Where to Collect?

Now that I’ve recapped how sponsorships work and why it’s a useful and valuable system, let’s talk about how we arrived at the current implementation. As a public good, BrightID should thrive on donations from those who benefit. There are two possible levels of beneficiaries: apps and users. All users are on the BrightID platform to use apps, and apps seem a simpler target since they are more likely to have funds on hand. Of the possible action or transaction points where funds can be collected, let’s consider “making a connection” and “sharing a verification with an app.” The benefit of collecting funds at the time a user shares a verification as opposed to at connection-time is that the app doesn’t waste money paying for users that may turn out to be sybils and therefore won’t be verified. It’s also clear at the verification-sharing time that the user is there to use a particular app, whereas at connection-time this isn’t yet known.

Let’s continue with the idea of collecting a fee at the time when a user shares a verification with an app. Verifications are most useful when re-checked with some regularity to make sure that a user hasn’t died or had their verification revoked. We don’t want to discourage frequent checks by charging a fee for each check. It’s therefore preferable that one payment pays for all checks for a single user. This is basically what a sponsorship is. Once an application has paid for a sponsorship for a user, that user’s verification can be checked as often as needed.

Rich Apps / Poor Apps

The final point to consider is: what do we do in the case that an application can’t afford to buy sponsorships for its users? We could allow apps to figure out for themselves how to pay for this expense, but let’s consider what an application in this situation has as valuable collateral: users. It seems to make sense that if we allow an application to send its users to try out another application, this could be a valuable arrangement for both: the first application receives free sponsorships, while the second application receives users they may not have gotten otherwise. This is what we’ve allowed to happen by saying that a user’s sponsorship is good across all applications and lasts a lifetime.

Humanity (re)Fund

The price of a sponsorship is $1 DAI per user per lifetime, is good across all apps, and is stabilized through voting by the BMAIN DAO. This should provide plenty of funding for BrightID indefinitely. BMAIN DAO is disallowed by its articles of incorporation from making a profit. If the time comes that there is more in BMAIN DAO’s vault than what is needed, it will be returned to all of humanity as a refund. Yes, we can do this with BrightID and Hedge for Humanity’s aptly-named Humanity Fund.

Before you go

Some useful links for BrightID all in one place:
* BrightID
* Hedge for Humanity
* Sponsorships and Subscriptions
* BrightID Main DAO’s constitution
* Discord (chat)

BrightID “Sponsorships” was originally published in BrightID on Medium, where people are continuing the conversation by highlighting and responding to this story.