Today, we are delighted to share that after two months of hard work, the .bit RGB++ and DOBs compatibility upgrade have both been successfully completed and is opened for all .bit holders (click to go upgrade now).

As many of you know, .bit was created in the early days of the CKB ecosystem, and its underlying asset type significantly differed from the recently proposed RGB++ and DOBs protocols. However, we chose to invest considerable effort into a complete overhaul, leading the largest community on CKB to actively embrace CKB's new development direction and accelerate the adoption and implementation of these two protocol standards within the CKB ecosystem.

Becoming a Bitcoin Layer 1 DID through the isomorphic binding feature of the RGB++ protocol is a significant step forward for .bit's future development, allowing us to advance towards the goal of becoming the biggest Bitcoin DID protocol with greater confidence.

The Next Chapter of the Grand Voyage

From its inception, .bit has always believed that the key to making a DID protocol stand out is breaking down barriers and lowering entry thresholds. Enabling users from different blockchains, or even those with no understanding of blockchain technology, to use a unified DID system without obstacles is the only way to achieve mass adoption.

Over the past few years, .bit has adhered to this path, leveraging CKB's unique features to achieve technical advantages not found in other DID protocols, such as multi-chain address minting and management, and the use of DID without seed phrases or gas fees. This approach has allowed .bit to carve out a niche in the highly competitive DID field. We have been fortunate to find a group of users who recognize the value of .bit, building a united and dedicated community together.

Our technical advantages have merely realized the first step of our vision. The next question is, how can .bit reach the next hundred thousand, million, or even billion users? This may sound like a pipe dream, as this scale far exceeds the total number of users of all current DID protocols. However, when we return to the starting point of the DID concept—to build the next generation of secure, reliable, and decentralized identity systems for humanity—this becomes a goal we must achieve.

A few months ago, with the introduction of the RGB++ concept, CKB began transitioning towards being a Bitcoin Layer 2 network, which also pointed .bit in the right direction: through isomorphic binding, making .bit a Bitcoin Layer 1 DID, leveraging Bitcoin's strong consensus to achieve .bit's next growth phase.

It seems the .bit team realized, perhaps even before this, that only Bitcoin has the sufficient influence to unify everyone’s consensus on DID. And only through Bitcoin does .bit have the chance to achieve the dream of building decentralized identities for all humanity. RGB++ appeared at this perfect moment, unlocking the door to our next map.

The choice of "bit" as the suffix for .bit was never a coincidence. Our founder Tim once wrote in an article explaining why .bit was built on CKB:

"...Our core team members left their jobs in internet companies to enter the Web3 industry largely because they identified with Bitcoin's foundational narrative and admired its elegant design. We are drawn to things closer to Bitcoin..."

The innate faith of being Bitcoin maximalists, the intuitive choice of CKB, and an unintentional tribute have planted the seeds for today, guiding us almost fatefully onto this path toward Bitcoin.

The new round of competition will be fiercer, and we will face many competitors on Bitcoin with different solutions but the same vision. When we win this round, .bit will dominate the entire game.

What Will the Upgrade Bring to .bit?

From a practical perspective, what benefits will the .bit upgrade bring to users?

Firstly, once users complete the upgrade, the new .bit will fully qualify as a Bitcoin DID through the RGB++ protocol, becoming a genuine Bitcoin Layer 1 DID.

Currently, .bit uses CKB's wallet connectivity library Common Chains Connector (CCC) to help users transfer .bit ownership using BTC or EVM wallets. CCC currently supports JoyID, Unisat, Metamask, and OKX Wallets.

After the upgrade, users can continue to manage .bit with EVM or BTC addresses, enjoying .bit's multi-chain features. Users can also use JoyID to perform the leap operation once JoyID supports the upgraded .bit assets. JoyID’s .bit integration will be completed around mid July.

The upgraded .bit also conforms to the DOBs (Digital Object) standard. In simple terms, DOBs are encrypted assets issued through the Spore protocol on the CKB blockchain. Minting .bit DOBs requires new storage space, occupying additional CKB tokens, which enhances .bit's underlying value.

Each .bit will not only have its unique name and value based on its length but will also have an additional value boost from the underlying CKB. Simply put, it becomes more valuable. Of course, these CKB tokens are not permanently charged. When a .bit DOBs expires, users can melt their .bit DOBs, and the occupied CKB will be refunded to the user.

Adhering to the DOBs standard significantly enhances .bit's trading liquidity. Previously, .bit used its own asset protocol, so users could only buy or sell .bit on specific secondary markets, limiting .bit's circulation beyond existing holders, which hindered the full realization of .bit's asset value potential. In the future, any trading platform supporting DOBs and RGB++ standards can list .bit, helping .bit traders achieve sufficient liquidity. Omiga has already added .bit trading, Dobby will soon support .bit trading as well.

With the development and expansion of the RGB++ protocol, you might soon be able to trade .bit on other popular Bitcoin ecosystem NFT markets. Whether you are a user of the CKB ecosystem or the broader Bitcoin ecosystem, you will have more convenient ways to acquire your first beloved .bit.

DOBs also opens up more exciting possibilities for .bit. For example, Nervape, which is also a DOBs, will be combinable with upgraded .bit. Imagine Nervape clothing, weapons, and accessories with your .bit identity, fully integrating your identity with your digital object image! This collaboration is already in progress, and the first batch of gear airdrops will be released soon. In the future, .bit will collide with more digital objects to create other exciting possibilities.

The true significance of this upgrade for .bit may only become more apparent over time.

How to Complete the .bit Upgrade

The new My DID management page will have two tabs: legacy .bit and DOBs compatible .bit, corresponding to pre-upgrade and post-upgrade .bit, respectively.

Step 1: First, connect the current .bit owner wallet address, which could be Ethereum, BNB, Tron address, or your Passkey. After logging in, you can find all the .bits you want to upgrade in the legacy .bit tab.

Step 2: Switch to the DOBs Compatible .bit tab in the upper left corner. At this point, you will be prompted to connect your JoyID, Metamask, Unisat, or OKX Wallet. After logging in, you will see a CKB address displayed in the top right corner. This address is generated by Common Chains Connector (CCC) and will become the owner of your .bit after the upgrade. You can continue to manage this .bit using your Ethereum or Bitcoin address in the future via CCC.

Click "Upgrade now," then select the .bit you want to upgrade and click the upgrade button. Please note that this operation is irreversible.

Step 3: First select your payment method to pay the CKB fees required for the upgrade (which will be refunded upon expiration). Then you transfer .bit ownership to the newly generated CKB address.

The upgrade process takes about 5 minutes. During this time, you can continue to upgrade other .bits.

At this point, the upgrade is complete. You can find all the upgraded .bits in the DOBs compatible .bit tab. In the details of each .bit, you can see that the owner has become the newly generated CKB address. You can also transfer the upgraded .bit to other CKB addresses, but note that currently, it only supports transfers to other CKB addresses generated by CCC.

Next, you can follow a similar process to set .bit aliases or renewals.

A new chapter is unfolding before .bit and all our holders. It is filled with treasures waiting to be discovered and challenges to be conquered. More Dapp integrations, more ecosystem partners, stronger identity symbols, and more cohesive community consensus...

Display your .bit identity anytime, anywhere. The magnificent next chapter is on the horizon.

Three central themes concerning communities and individuals

We have consistently focused on three pivotal themes associated with communities and individuals. We believe that these themes carry long-term significance.

1. The relationship between the community and the individual.

How can people with shared ideas, values, and hobbies come together to form a community? How will the community recognize its members? And, as part of the organization, how can an individual gain a sense of identity and belonging within the group?

2. Community governance and collaboration.

When individuals from around the globe come together to form a community, the questions arise: How can these members collaborate and co-create seamlessly? And how can different communities work together and govern effectively?

3. Proof of personhood

In an age where AI's capabilities are rapidly expanding, what defines our human uniqueness, and how can we ensure it's recognized?

Historically, these universal, persistent questions haven't received satisfactory answers. Yet, the evolution of cryptographic thought and advancements in blockchain technology are offering fresh perspectives on these challenges. We believe that DID holds the solution.

Rethinking Identity

Historically, individual identities and community memberships were bound to centralized platforms, platforms that are operated in isolation from each other, fragmenting our identities across them. Even more concerning, our digital existence could be readily wiped out from a platform's database due to its vague policies, potentially erasing the brand and social connections we painstakingly established.

We assert that our identity should not be confined or dictated by any singular platform; instead, it should stand independent of any application. An individual's personal identity is their intrinsic asset, just as community memberships and relationships are central assets to the community itself. By detaching identity from applications, we are on a path to genuine ownership and control over our own identities. The emergence of Bitcoin marked the first time we could genuinely control our assets, heralding the dawn of the era of programmable assets. Similarly, blockchain-based DID is set to empower us to truly master our identities, ushering in an era of programmable identity. With the combination of programmable assets and identities, the vision of a programmable society starts to emerge, the vision of a programmable society begins to take shape.

So what exactly is DID? It is a subject that has been discussed for quite some time. Various DID products have surfaced, but none seem to address real-world challenges effectively. Here, we present the model that embodies our understanding of DID:

DID = Decentralized Identifier * Soulbound Tokens * Scenarios

DID is a system wherein each individual starts with a decentralized name, like 'tim.swiftie'. When this individual engages in social activities, the corresponding contributions, achievements, and experiences are attached to this name via SBT. This name, now enriched with these contributions, achievements, and experiences, represents their decentralized identity. This identity becomes their credential for participating in numerous other social activities. Various applications or scenarios will then offer services based on this identity information.

This is somewhat similar to our real world: We are born with a name, and our contributions/achievements/experiences are all linked to this name, molding our individual identities and granting us opportunities to engage in other social activities. However, the distinction lies in the fact that a DID is an identity entirely under our control. DID is trustworthy, enduring, and not tethered to any specific platform. It forms the cornerstone of our approach to the three central challenges.

DID-based Solutions

.bit - Paving the way for DID-based communities

.bit is a Barrier-free DID issuance platform tailored for communities, and also a robust DID system for individuals.

Through .bit, communities can issue their own DIDs with a single click, laying the foundation of a DID-based community. In this framework, a DID bearing a community-specific suffix acts as an exclusive badge of membership, solidifying one's affiliation.

For example, members of the Red Cross could have DIDs like henry.icrc, clara.icrc; fans of Tylor Swift could have tim.swiftie, mia.swiftie. These DIDs with the same suffix clearly define community membership boundaries, simplifying intra-member recognition and fostering a potent sense of identity and belonging. Such a DID-based community represents an innovative approach to consolidating like-minded individuals with shared values, principles and interests into a community.

Soulfrag.xyz - The first DID-based reputation management system, ensuring every community contribution is recognized

In every community, members bring value through diverse contributions. For the vitality and cohesion of a community, maintaining a lasting record of each member's input, achievements, and experiences is paramount. The SBT (Soulbound Token) stands out as the premier medium for encapsulating members' reputations.

An innovative design of SoulFrag is that the SBTs issued via SoulFrag are permanently linked to a community member's DID. Additionally, we offer diverse SBT types to record various reputational aspects. When we view someone's DID, it's not just a confirmation of membership; it paints a vivid picture of their contributions and standing within the community. The DID-based reputation system SoulFrag serves as a powerful motivator, encouraging members to collaborate and co-create effectively.

Voty.xyz - The first DID-based governance system, ensuring every voice is heard and valued.

Historically, community governance systems often struggled, leaving us questioning the legitimacy and contribution of the most vocal participants.

Only those holding a DID with the specified community suffix can both introduce and vote on community proposals. Moreover, the significance of each vote is influenced by a myriad of factors, from tenure within the community and role to individual contributions, as denoted by SBTs awarded through SoulFrag.

Voty streamlines community governance, ushering in an era of transparency and efficacy, ensuring deserving voices resonate.

d.id Profile - A DID-based profile, helping everyone express their proof of personhood

In this age, where AI is rapidly advancing, capable of crafting art, melodies, and literature — once believed exclusive to human creativity — it's clear AI can emulate and even augment our cognitive processes to some degree.

Yet, there’s one domain it can't replicate: our personal experiences. Each experience is unique, immutable and it's what makes us human. We, as social beings, innately seek to share our stories and resonate with others with similar tales. d.id Profile is designed to elegantly showcase these very experiences, contributions, and creations.

These DID-based products aim to address the three major issues to a degree. Yet they are just a start. Our ambition is for these innovations to inspire developers, prompting them to embrace the DID paradigm and collaboratively navigate the challenges at hand."

DID as a Service: Giving every community/brand/individual a DID

The concept of a community is vast and varied, encompassing fan clubs, brand loyalists, gaming communities, DAOs, interest groups, NGOs, and clubs. Central to these communities are the members and their interrelationships, assets that DID embodies perfectly. In an envisioned future, every community will proudly bear its distinct DID, unlocking unprecedented opportunities. Yet, for many, the intricacies of issuing a customized DID and ensuring its widespread applicability can be daunting. To bridge this gap, we're thrilled to introduce "DID as a Service", facilitating seamless DID issuance for any community with one single click, while guaranteeing extensive application compatibility.

Before the advent of ERC20, issuing a token meant building a whole public chain from scratch. However, with ERC20, token issuance became as simple as deploying a contract. This has brought about a huge boom in asset issuance, paving the way for the prosperous Web3 ecosystem we see today.

Similarly, before the launch of d.id's "DID as a service", the issuance of DID required deploying contracts and seeking support across various applications. With our service, all it takes is a single .bit to distribute a DID. This innovation greatly lowers the threshold for communities to issue DIDs, opening doors for countless communities to benefit. We anticipate this will surely create a new wave of prosperity and accelerate our progress towards a programmable society.

Barrier-free Web3

We believe that the value and potential of Web3 should be accessible to everyone, not just tech insiders. Therefore, we'd like to propose the principle of Barrier-free Web3. It is both a commitment to our users and an advocacy for the industry. Its core concepts are: Seedless; Gasless; Decentralized. We implement this principle in all our products. This means that anyone will no longer need to care about private keys, transaction fees, or any technical knowledge related to Web3, but just use d.id's products with ease.

New brand, brand new mission

Helping people better organize, collaborate, and share through DID.

After more than two years of deep reflection and hands-on experience, we are convinced that DID will definitely bring new possibilities to communities and individuals. It promises a reimagined definition of communities and personal identities. We see a future society underpinned by decentralized identities as both valuable and compelling. We are committed to building and exploring DID, we strive to help people transcend the existing information societal structures, enabling them to organize more effectively. We envision a place where we can all organize, collaborate, create and share in ways previously unimagined. Our conviction is steadfast, and we look forward to the rise of DID-based communities and innovations. Let us all build an inclusive Web3.0 landscape together.

d.id Team

2023.09

Basic concepts

Before we begin, we need to understand some terms and what they mean:

• .bit Account: A .bit account is essentially a data container for user sovereignty, with a globally unique and human-readable name. Once a user stores data in it, the application can read the data and provide services to the user.

• .bit Alias: A .bit Alias represents a piece of data (such as a blockchain address). Once a blockchain address has been assigned a .bit alias, this alias can be used to display instead of the address in any context.

• .bit Lookup: This refers to the process of querying data (such as a blockchain address) stored under a .bit account name. It is similar to the Domain Name Resolution concept in the Internet Domain Name System.

• .bit Alias Lookup: This refers to the process of querying the .bit Alias of a piece of data (such as a blockchain address). It is similar to the reverse DNS lookup concept in the Internet Domain Name System.

The following diagram illustrates the process of .bit Lookup and .bit Alias Lookup:

How can .bit Alias make transfers more secure?

Fill in the missing part of .bit Alias required by applications when making transfers

As shown in the picture, in this mode, the asset recipient provides the address and the corresponding .bit Alias to the sender. When the sender sends the asset, they input the recipient's address. At this time, the wallet/exchange will initiate a .bit Alias lookup request to the API service to retrieve the result and prompt the user to "please complete the alias for the recipient address." After the user fills in the information, the wallet/exchange compares it with the retrieved result. The transaction will proceed only if the two match.

Verify .bit Alias for transfers required by applications when making transfers

For small transactions, the wallet/exchange can simply prompt the user with a message such as "The alias for the receiving address is satoshi.bit, please confirm if it's correct."

This is somewhat similar to how we conduct fiat currency transfers in the traditional banking system. We never worry about making mistakes when transferring fiat currency because we need to input the recipient's bank account number and their account name, which must match. If they don't match, the funds will eventually be returned to us. Using .bit Alias as an additional verification mechanism when sending assets achieves the same effect. When the application detects that the alias entered by the user does not match the query result, it will not allow the user to proceed with the asset transfer. This is because the user will not continue with the asset transfer if they find that the alias displayed by the application does not match the one they received. Therefore, the user's assets are always secure.

Understanding .bit Alias

You can read our previous article "In-depth understanding of .bit Alias" for more information.

Further discussion on transfer security

1. What impact does it have if .bit Alias Lookup returns an incorrect result?

Although the probability is low, both .bit Lookup and .bit Alias Lookup require wallet/exchange to request data from API service, which may result in returning incorrect results. However, when the former returns incorrect results, it will directly cause users to send assets to the wrong address. When the latter returns incorrect results, it will only cause users to choose not to send assets temporarily, and they will send them after verifying them carefully, without asset loss.

Moreover, if an API service fails to return any result, the former prevents users from continuing asset transfers, while the latter is merely an auxiliary verification tool for enhancing security, and users can still send assets using the address without such verification.

2. Can ENS Primary Record be used as an auxiliary verification method for sending assets?

The principle of ENS Primary Record is similar to that of .bit Alias, but it is not suitable as an auxiliary verification method for sending assets for the following two reasons:

A. Limitations of Primary Record

ENS is built on top of Ethereum, and its smart contracts can only verify the signature of Ethereum private keys. Therefore, except for Ethereum addresses, other public chain addresses cannot use an ENS as an alias. For wallets/exchanges, even if there are no other design issues with ENS, using ENS Primary Record can only improve the security of Ethereum asset transfers. At the same time, in the design of ENS, only one Ethereum address is allowed to use an ENS as its Primary Record. If a user has multiple Ethereum addresses, their needs cannot be met.

On the other hand, .bit Alias is different. Firstly, any public chain address can set a .bit Alias, which comes from the wide compatibility of cryptographic algorithms that .bit has always been proud of (Learn more here). Secondly, a .bit account can store multiple addresses of the same chain, and multiple addresses can use the same .bit account as their alias. We believe that this is more in line with the actual needs of users.

B. ZWJ vulnerability of ENS

For detailed discussions on the ZWJ defect of ENS, please refer to Zero-width characters pose a security risk and existential threat to ENS.

In summary, any user can create their own "vitalik.eth" by inserting invisible characters. In fact, there are already many "vitalik.eth" in the ENS contract. The existence of this defect makes ENS Primary Record completely unusable as an auxiliary verification method to improve transfer security. When a wallet or exchange queries an address's alias through an API service and it returns "vitalik.eth," users cannot distinguish whether it is the real "vitalik.eth" or "vitalik.eth" containing invisible characters. In this case, it may cause even more serious security problems.

Also, it should be noted that:

1. Other forked ENS projects have also completely forked the limitations and vulnerabilities of ENS. Therefore, they are also not suitable as auxiliary verification methods to improve security.

2. .bit does not have a ZWJ problem.

Best practices recommendations for all parties involved

Security is of utmost importance. Our recommendations are as follows:

• For wallets/exchanges

  • Users should not be able to send assets directly via .bit/ENS or other DID products.

  • To enhance security when sending assets, consider using a .bit Alias solution. See our UX guidelines for more information.

• For asset recipients

  • Set up a .bit alias for your address (see guidelines).

  • Provide both your blockchain address and corresponding .bit Alias to the sender when receiving assets.

• For asset senders

  • Avoid directly transferring assets using .bit/ENS or other similar DID products.

  • Use wallets/exchanges that prioritize user asset security.

About .bit

.bit is the only cross-chain unified DID protocol that can verify signatures using various asymmetric cryptographic algorithms. This unique ability allows .bit to extend its services to a wider range of users, reaching beyond just the Web3 community.

.bit 's mission is to Empower every community and individual to explore new possibilities through sovereign identity.

Contact us for any inquiry: vivi@d.id

In Web3 world, we often need to use various types of addresses, such as Bitcoin addresses, Ethereum addresses, personal addresses, friend addresses, company addresses, and so on. These addresses are often very long and difficult to distinguish. In different scenarios, we often encounter similar problems: Whose address is this? Is it correct? Is it valid? These issues exist for scenarios such as transactions, blockchain browsers, personal pages, game leaderboards, etc.

We wonder: What if we could convert these addresses into human-readable names?

Based on this idea, we introduced the feature of .bit Alias.

What is .bit Alias?

.bit Alias is the ability to associate a blockchain address to a .bit account. With this feature, you can set a globally unique alias for any blockchain address.

For example, you can set an alias “myeth.bit” for your ETH address “0x1D6...485f”. This way, when developers display the address, they can also display the alias of ”myeth.bit” to make it easier for other users to see the owner of the address.

.bit Alias is also sometimes referred to as Reverse Resolution because its initial idea originated from Reverse DNS lookup in DNS, which is used to query a domain name associated with an IP address.

The Difference between .bit Alias and .bit Lookup:

Although both .bit Lookup and .bit Alias involve address substitution, they differ in their input and output.

For .bit Lookup, we see a .bit account and want to know which blockchain address it corresponds to, such as ”satoshi.bit” => “0xabc...def”.

For .bit Alias, we see a blockchain address and want to know which .bit account it belongs to, such as “0x123...456” => “satoshi.bit”.

This leads to different usage scenarios:

.bit Lookup is more commonly used on personal pages, social platforms, and other scenarios where names are more directly involved.

.bit Alias is more commonly used in the scenario of entering addresses during transactions to improve transaction security, as well as in Dapps where addresses are replaced with names to improve user experience.

Usage Scenarios

In the world of Web3, .bit Alias has many use cases, and here are some typical examples:

Avoiding errors when transferring assets through additional verification.

In the blockchain world, tragedies often occur due to the loss of a large amount of assets caused by an error in the transaction address. Here is a common example: When we use a wallet to do multiple transactions, we copy different addresses multiple times and then transfer the corresponding tokens. For example, we transfer 100 USDT to our external partner's address “0x123...456” for the first time and transfer 100 ETH to our colleague Satoshi's address “0xabc...def” for the second time.

However, if the second copy fails, we will paste the result of the last copy into the input box. At this time, we cannot realize that we are transferring to the wrong person. Since addresses are difficult to distinguish by the naked eye, we cannot get reasonable prompts either. The result is that we transferred 100 ETH to the partner “0x123...456” in the end. At this point, if the other party is not a decent person, then our assets will be at risk of loss. However, if we can see that the recipient is “satoshi.bit” at this time, such tragedies will not happen.

Furthermore, for particularly large amounts of asset transactions, wallets/exchanges can even display only a portion of a .bit Alias, requiring the sender to complete it before being able to send the assets. This additional verification mechanism enhances user confidence in asset transfers and actually improves the security of the asset transfer operation.

Behind this is the use of the .bit alias feature, which allows wallets to prompt you with the .bit account associated with the address you are interacting with. This can greatly enhance the security of transfers.

Prevent hacker attacks during transfer

In addition, if a hacker hijacks a user's clipboard (which is a common attack vector), the hacker can easily replace the content you copied and pasted, leading to an attack. However, by using .bit Alias, we can effectively prevent this type of attack.

Check out this real-life clipboard attack case.

Two-Step Authentication

To enable .bit alias, users need to perform two steps:

1. Add the address they want to set an alias for to their .bit data container, or ensure that the owner or manager address of their .bit account is their own address.

2. Open the .bit alias settings page, log in to the address they want to set an alias for, and set the alias to one of their .bit accounts.

Developers, on the other hand, need to follow the following two steps when verifying:

3. Call the .bit alias interface based on the address provided by the user to obtain the corresponding .bit alias.

4. Use the obtained .bit alias to call the .bit resolution interface, then obtain the corresponding .bit account information and resolution records, and see if the address provided by the user exists in the resolution records of the account owner and manager. and check whether the resolution records of the account owner If it does, the alias of the address is considered to correspond to the .bit account; otherwise, the address is deemed to have no valid alias.

Why is two-step verification necessary?

You may wonder why users need to go through two steps to set up .bit alias, and why developers need to follow two steps to query them.

This is because if we only do one .bit alias query, for example, “0x123...456 => satoshi.bit”, a potential attacker could set the alias of their address to someone else's .bit account.

For example, let's say your address is “0xabc...def”, your .bit account is “satoshi.bit”, and the attacker's address is “0x123...456”. The attacker then sets the alias of their address to your account, “satoshi.bit”.

If we only do a simple .bit alias query, other users in the relevant application will see the attacker's address displaying your name, “satoshi.bit”. Your friends might think, "Oh, this is Satoshi's address, let me send him some money." However, in reality, they are sending money to the attacker's address.

To avoid this behavior, we require two steps. After setting up the .bit alias, to make the alias effective, the corresponding address must be in the resolution record of the .bit data container (or the address is the owner and manager of the account).

This ensures that the alias you set is definitely set by you, not by someone else.

Compatible with any address

While applications like ENS also provide similar capabilities (known as Primary Record) to map Ethereum addresses to an ENS domain name, ENS is limited to supporting only Ethereum applications, and other blockchains like BNB, Tron, and Dogecoin cannot enjoy the convenience and security benefits of this feature. Furthermore, due to the constraints of the ENS contract, ENS can only have one Primary Record, so if a user has multiple Ethereum addresses, they cannot have multiple addresses pointing to the same ENS domain name.

However, .bit alias is different. With the open cryptography technology of .bit, any blockchain address can have a .bit alias. Therefore, you can set a .bit alias for any blockchain address, such as your Ethereum address or Tron address. You can even set an alias for Bitcoin and Dogecoin.

This is very useful in practical scenarios!

In fact, due to the powerful compatibility and scalability of .bit, .bit alias can be applied to any public-private key pair, just like any public-private key can have and manage a .bit account. This also means that .bit alias can not only bring us a more secure and user-friendly experience in blockchain, but also play a role in other Web3 scenarios that we have not yet imagined. Imagine that one day in the future, you can set an alias for your SSH public key or OpenPGP public key. Then, when your friends and colleagues see the public key, they can immediately know that it is your account, without worrying about getting the wrong account.

Completely Free

In previous versions of .bit Alias, we charged a storage fee of 201 CKB for each alias. We believe this hindered the adoption and promotion of .bit alias, which in turn was detrimental to improving the security of the entire Web3 world.

Therefore, we are introducing a brand new .bit alias! From now on, you can set an alias for any address without paying any fees!

Go set up now

Developer Guide

If developers need to resolve .bit alias, they can simply use the corresponding SDK or API.

• JS SDK: dotbit.js

• HTTP API: das-account-indexer

If using the API directly, please remember to call the records interface for verification after calling the .bit alias interface. For more details, please refer to: Two-Step Verification.

Looking Forward

.bit is currently the only DID naming system in the industry that can provide alias services for all blockchain addresses. We hope that this feature can provide better user experience and higher security for the entire industry.

In the future, we will support alias services for more public chains. If you have any questions, discussions, or support you would like to offer, please feel free to contact us.

Let's work together to make a greater contribution to the security of Web3!

Now, go ahead and set up your .bit alias to protect your assets: Set up a .bit alias.

About .bit

.bit is the only cross-chain unified DID protocol that can verify signatures using various asymmetric cryptographic algorithms. This unique ability allows .bit to extend its services to a wider range of users, reaching beyond just the Web3 community.

.bit 's mission is to Empower every community and individual to explore new possibilities through sovereign identity.

Contact us for any inquiry: jeff@d.id

Security Risks of Sending Assets Using .bit/ENS

The above diagram is a schematic diagram of the information flow when a user sends assets to vitalik.eth in a wallet. When the wallet detects that the user has entered vitalik.eth when sending assets, it will initiate a query request to the server to query the blockchain address corresponding to vitalik.eth. After receiving the blockchain address returned by the server, the wallet constructs the transaction for the user to sign, then broadcasts the signed transaction to the network to complete the asset transfer.

We call the server responsible for responding to query requests the API Service. It tries to stay in sync with the blockchain network, and whenever a new block is generated, it parses the block data, finds related transactions, and updates its local database accordingly. There are generally three sources of such API services: provided by .bit/ENS development teams; provided by third-party data service providers, such as Infura, and provided by wallets/exchanges themselves. For many wallet/exchange developers, they believe that using their own deployed query service has high security. However, we will analyze that, based on their operating principles, API services of any source have the same risks.

It should be noted that although we use the somewhat centralized term "API Service" here, it does not mean that systems like .bit/ENS are centralized. In fact, they are decentralized, and any developer can deploy their own "API Service" without obtaining permission from others.

The existence of the following risks may ultimately lead users to send assets to the wrong address:

1. Hackers attack the API Service and tamper with the returned results;

2. Internal personnel of the API Service commit wrongdoing and tamper with the returned results;

3. Internal program exceptions in the API Service lead to incorrect results being returned;

4. The blockchain node used for data synchronization within the API Service lags behind the blockchain network, causing the API Service's data to be outdated and thus returning incorrect results;

5. The payee's .bit/ENS is not renewed in time, and after it expires, it is registered by others and associated with a new address. The asset sender does not know this information, leading the wallet to obtain the wrong address.

We have not yet seen any public reports of asset loss due to 1 or 2. However, we believe that as long as users gradually develop the habit of using .bit/ENS to send assets and the value of sending assets through .bit/ENS becomes attractive enough, they will inevitably occur. The risks brought by non-subjective factors such as 3, 4, and 5 are also impossible to completely avoid. As the habit of using .bit/ENS to send assets is formed, it's only a matter of time before non-subjective factors cause asset losses.

In addition, when the API Service fails and cannot return any results, users will not be able to send assets through .bit/ENS. Although this situation does not result in asset loss, it does harm the user experience.

These risks seem to be unavoidable and may cause serious losses. Does this mean that we cannot use .bit/ENS in the scenario of sending assets? The answer is no. We believe that the risks mentioned above do not originate from systems like .bit/ENS themselves, but from the incorrect use of .bit/ENS. Changing the usage method not only avoids the risks mentioned earlier but also makes the asset-sending process even safer.

We will share our in-depth thoughts on this issue and showcase our new solution for it at the Hong Kong Web3 Festival 2023's "Web3 Financial Infrastructure: Digital Wallet and DID" session. If you have questions about the risks mentioned earlier or have further insights, please join our Discord channel to communicate with our development team.

Before wallets and exchanges adopt more advanced measures, we recommend users avoid using .bit/ENS and all other DIDs to send assets directly in wallets and exchanges.

Background

Before further explanation, we need to have a basic understanding of the Nervos CKB, which is known as "customizable cryptographic primitives".

Most existing blockchains use a fixed template script to verify signatures in transactions.

For example, BTC and many other blockchains use the Secp256k1 ECDSA signature algorithm and verify transaction signatures using a fixed Script template (the OP_CHECKSIG opcode uses the ECDSA algorithm).

Relative to BTC's stack-like fixed verification mode, CKB abstracts it into a Turing-complete code. This allows developers to use any signature algorithm, as long as the code does not throw an error, it is considered to have unlocked the assets inside.

If we compare the object that carries blockchain assets to a safe, then on BTC and other chains, the lock on this safe can only be a "Bull" brand lock, while on CKB, you can freely choose the brand of the lock. It can be a "Cow" or "Heifer" lock, even a fingerprint lock or using an audio clip to unlock, or even without a lock (i.e., anyone can spend the assets inside).

Details

To use Dogecoin address to manage a .bit account, we need to solve the following two problems:

1. How to generate the digest?

We know that ECDSA is a signature/verification method for a message (referred to as a "digest" below), and BIP143 specifies the specific rules for converting a transaction into digest. However, .bit is an application based on CKB. Due to the different transaction structures, we can not follow this rule. Fortunately, CKB has its own "BIP143", which is explained in detail in this official document, describing the process of generating digest from a CKB transaction.

2. What is the signature convention?

UTXO wallets have had signature conventions for digest for a long time (for security reasons), which first concatenate some prefixes to the original content to be signed (and these conventions gradually evolved into later EIP191), and then use the ECDSA to obtain the signature result. Now there are implementations in multiple languages, such as a JavaScript implementation: bitcoinjs-lib.

Fortunately, there are ready-made solutions to the above problems, and we only need to do the following:

In terms of signature digest, follow the digest rules of CKB, and then use CKB's ability to customize cryptographic primitives to implement verification according to existing UTXO signature conventions.

In general, no matter what signing method/convention the client uses, the contract side of CKB can adopt the same method/convention for verification. Therefore, theoretically, CKB can support any signature algorithm. The following is the application of various algorithms in blockchains:

Currently, .bit supports both ECDSA and EdDSA signature algorithms. Therefore, in theory, it can seamlessly support chain users who use these two signature algorithms without the need to understand what CKB is, and directly use the private keys of the current chain to manage .bit accounts.

Q&A

1. Why does Dogecoin signature support only come now?

   Previously, there were no good signature clients in the market that supported Dogecoin signatures. TokenPocket wallet recently provided support for Dogecoin signing of messages, and we are very grateful for TokenPocket wallet's contribution to the entire Web3 ecosystem, promoting the ecological development of Dogecoin. Now you can use Dogecoin address to manage your Web3 DID.

2. Does supporting Dogecoin mean that BTC is not far away?

   Yes, BTC will soon be supported. In fact, as mentioned earlier, .bit naturally supports all blockchains that use ECDSA as the signature algorithm.

3. How to use it?

   Because only TokenPocket wallet supports Dogecoin signing of messages at present, you can now use TokenPocket wallet and assess did.id to experience registering and managing .bit accounts.

4. I am a Dogecoin user. Do I need to understand what CKB is to use .bit accounts?

   You don't need to. Thanks to CKB's advanced abstract account implementation, you can still use existing Dogecoin addresses (private keys) to seamlessly experience .bit applications based on CKB.

About .bit

Website: did.id

Twitter: @dotbitHQ

Discord: discord.gg/did

GitHub: github.com/dotbitHQ

Team Blog: blog.did.id

Forum: talk.did.id

Jobs: docs.did.id/we-are-hiring/position-list

All .bit accounts with a length of 4 or more, and are constituted with characters of pure number, pure Emoji, pure Thai, pure Korean, pure Turkish, and pure Vietnamese can be registered.

*Mixture of characters must meet the release rules for the 60%. For example, 😊002.bit and ş👋👋👋.bit does not meet the algorithm rules, and will not be released on Oct 18.

.bit is a public resource. To make .bit has a rather fair system of account distribution is always a goal that we endeavour to achieve. All non-released accounts are not held by the team, and we will gradually release them after we have a certain industry influence. To learn more about our initial thoughts and goals, see here.

More info

.bit Continues to Popularize Web3 Identity and Closes $13 Million in a Series A Funding Round

So far, more than 55k independent addresses have registered for more than 160k .bit accounts, and nearly 100 mainstream wallets and DApps have integrated with .bit (Check here).

Also, the .bit community keeps growing. There are over 90,000 Twitter followers and nearly 50,000 Discord members.

SubDID Helps DAO Thrive: DigitDAO #1 Proposal Approved in 7 Days, Now in Implementation Phase

To encourage people with different cultural backgrounds to use decentralized identity and improve cultural diversity in Web3, we initiate the concept of NameDAO. By handing over a portion of the .bit protocol revenue to the DAOs, the team aims to motivate more people around the world to spread their culture and endow them with better access to Web3 through NameDAO.

Currently, DigitDAO and EmojiDAO are using SubDID of 0x.bit and 😊.bit for governance. on October 9, the first proposal for DigitDAO was approved and is now in the implementation phase. Looking forward to more experimentation and practice with SubDID!

About .bit

.bit Website: https://did.id

NameDAO Website: https://www.namedao.xyz/

Twitter: @dotbitHQ

Discord: https://discord.gg/did

GitHub: https://github.com/dotbitHQ

Team Blog: https://blog.did.id

Forum: https://talk.did.id

On the first anniversary of launching .bit, we are excited to announce that .bit has closed $13 million in a Series A funding round from CMB International, HashKey Capital, QingSong Fund, GSR Ventures, GGV Capital, and SNZ.

.bit, an open-sourced decentralized identity protocol built on the blockchain, is committed to providing permissionless and irrevocable decentralized identity for individual users and DAOs, establishing the awareness of identity sovereignty around the world. With the joint effort from the development team and the community during the past year, .bit has achieved a breakthrough from 0 to 1 and reached rapid growth for both user and active developer communities. So far, more than 38k independent addresses have registered for more than 110k .bit accounts, and nearly 100 mainstream wallets and Dapps have integrated with .bit (please check here).

Users have never really controlled or even owned our identity online or offline. In Web2 world, social accounts used to present who we are or how we relate with others are stored on centralized tech giants, who can easily revoke or tamper with the data. Platforms can block our accounts at any time, refuse to provide services, and thus remove users from their own social graphs.

According to World Bank, nearly one billion people in the world have no form of legal identity, meaning they cannot prove who they are, not able to obtain basic national healthcare or benefits, not able to accept fair education, and not able to own suffrage rights. The exclusion of these people from access to legal identification is one of the most crucial global human rights challenges.

The emergence of blockchain technology, with the permissionless and irrevocable features, makes it possible for us to truly own and control our data and identities. Permissionless means that we can own an identity on the blockchain at any time, and no one can stop us; Irrevocability means that no one can erase the identity we already have. We will thus realize identity sovereignty, both as individuals and as organizations.

We are excited and confident to be a part of the challenging work of building the infrastructure for Web3 identity protocol. 

To construct the leading decentralized identity system and expand the adoption of the decentralized identity, .bit team will apply the funds and resources to the following areas:

Cross-chain

We believe that Web3 is not only about blockchain, and blockchain is not only about one specific public chain. As Web3 citizens, we need a cross-chain unified decentralized identity solution. What makes .bit stand out from its competitors is a combination of cross-chain feature and cryptographic level security. It means any public chain or even non-blockchain users can adopt .bit as their decentralized identities and switch their accounts among chains.

.bit has supported Ethereum, BNB Chain, Tron, Nervos CKB, and Polygon. In the future, .bit will cover all mainstream public chains such as Bitcoin, Dogecoin, Polkadot, Solana, etc., as well as software and hardware devices that support asymmetric encryption algorithms.

Cross-culture

The world is culturally diverse with multiple languages and writing systems. People should be able to register their decentralized identities with the languages they prefer for daily use. However, similar characters shared among different writing systems provide possibilities for fraud.

.bit Team is committed to the challenging task of supporting all the writing systems in the world while preventing scams and frauds as much as possible, so that users from different cultures in the world can own reliable decentralized identities and get equal chance to enter Web3 ecosystem safely.

Cross-verse

Cryptocurrency transfer, decentralized domain resolution, personal profile display, etc. are only parts of the usage scenarios of .bit. As an identity protocol, .bit could be widely used as membership and credential management for DAOs, brands and IPs, celebrities and fans, clubs and communities, etc.

.bit is a unified identity for users to take into different spaces including centralized and decentralized applications. The team will build a series of robust tools to help all types of application developers to integrate with .bit easily, which ultimately provides users with an exceptional experience.

Upcoming Features

NameDAO

To encourage people with different cultural backgrounds to use decentralized identity and improve cultural diversity in Web3, we initiate the concept of NameDAO. By handing over a portion of the .bit protocol revenue to the DAOs, the team aims to motivate more people around the world to spread their culture and better access Web3 through NameDAO.

Visit https://namedao.xyz for more information.

SubDID

We encourage you to issue SubDID to DAO members, brand adopters, fans, etc., to strengthen the bonding within communities in a Web3 style.

Visit https://www.did.id/subdid for more information.

4-9 digits account available to 100%; open up 3 digits account

We always insist on gradually increasing the availability of .bit accounts as the global influence of the project expands. Such a strategy brought an unsatisfactory registration experience to users to some extent, but it also reflects our determination to launch .bit in a fair way.

Now, .bit has integrated with the leading wallets and Dapps, and the community is growing strong and active. We think it is time to further lower the threshold for registering accounts.

We will announce the specific rules on the official Twitter @dotbitHQ very soon.

Let's explore, WAGMI!

Having a name chosen by your parents will be like having a marriage arranged by your parents. It’s not the modern thing to do, and a sign of a very conservative traditional family.

-- 《Non-Assigned Names》Kevin Kelly

If you believe decentralized identity is critical to the future world, and what .bit is doing intrigues or excites you, welcome to join us for discussion through:

Website: did.id

Twitter: @dotbitHQ

Discord: discord.gg/did

GitHub: github.com/dotbitHQ

Team Blog: blog.did.id

Forum: talk.did.id

Jobs: docs.did.id/we-are-hiring/position-list

West.bit’s introduction

Good evening everyone! Welcome to our sharing session with .bit community. I’m an old friend, west.bit, and I’m excited that you are all here for our live chat.

Tonight, we have invited Tim, Founder of .bit, to share with you some latest ideas.

In the first session, Tim will share some interesting updates about .bit community, and what we might do next, including the Web3.0 industry, our progress and plans. This is also the first time this year we have Tim interacting with our community members.

In the second session, we’ll pass the mic to you guys to ask questions. In addition, we will try to keep the whole session within 1 hour, so we will not take up too much of your time.

p.s. There will be an OAT for participants of tonight’s Name DAO meeting. And we have a special incentive for all members that participated in this event, you will receive an airdrop, an exclusive SubDID. So, everyone, please make sure you fill out the appropriate form on the OAT (https://galaxy.eco/dotbit/campaign/GC9UvUtFYm/).

Okay, now we have Tim.

Tim’s Opening

Okay, thanks west.bit.

It’s been a long time since we’ve had a conversation about our .bit product, and I think the last time we talked about it was last year. We started preparing in Jan 2021 and launched the product in July last year, it’s almost one year now.

I will first briefly talk about the progress we have made in the past, and then discuss what we want to do in the future. Then we will mainly discuss with the community one very important topic, and present our ideas.

Finally, we will have a freestyle Q&A session where you can ask any questions you may have, and we will do our best to answer any questions.

Review last year

Recently, the number of registered accounts for .bit has exceeded 100,000, which may not sound like a particularly impressive achievement compared to the ENS that we all know about. However, I think the biggest progress we have made in the past year is our achievement in the level of integration in our .bit ecosystem.

Today, if you look at the integrations in our ecosystem, all mainstream wallets and mainstream DApps have integrated .bit, which I think is one of our most important achievements in the past year.

Some may say, the integrations of the .bit ecosystem seem to be more Asian, and have only a few European and American partners. Well, we don’t need to worry about this. In the coming days, you will gradually read announcements about our integrations with well-known overseas DApps, and please feel free to follow our Twitter (https://twitter.com/dotbitHQ ) for more updates to come.

Also, we have completed the development of some very important features, such as SubDIDs, cross-chain to Ethereum to become ERC721 NFT, and .bit alias, and so on.

SubDID

The SubDID feature has been discussed for a long time, and we are all looking forward to the time when it finally launches.

We are almost ready for the feature of the SubDID. We’ve finished testing, and we are fully ready for the underlying contract-level capabilities. The key point here is that it is very difficult for users to deal with the contract directly. We must provide a tool for users to manage those SubDIDs, and a UI interface so that we can provide convenience for users. And that’s exactly what we are currently working on, a tool and UI interface.

Previously, we saw a tool like SuperDID. After testing, we feel the tool itself has some problems to be solved.

So, we expect that by the end of July or early August, our .bit SubDID will be open for everyone to use, and this is one of the most important features that we are developing.

First of all, there are many application scenarios for SubDIDs. For instance, we often mention the concept of “a member of DAO”, but what exactly qualifies, or what makes someone a member of a certain DAO?

There are several solutions available on the market today.

1. If you are in my community as a member, you are a member of my DAO.

2. This DAO issues ERC20 tokens, and whoever has tokens will naturally become a member of this DAO.

However, not all DAOs will issue tokens, at least not from the beginning. The other problem with issuing tokens is that it makes the right to vote tradable, and it’ll create a series of very complicated problems, such as corruption, and other issues triggered by the financialization of voting rights and governance rights.

3. If I own your NFT, I am a member of your DAO.

However, NFTs are often limited in number. Meanwhile, NFTs themselves are also tradable tokens, and in reality, people speculate in NFTs.

Therefore, a feature like a SubDID will ease the problem, as it’ll give an organization, not necessarily a DAO organization, even a centralized organization, a practical identity management system (IMS).

For example, how can we be regarded as members of Assange DAO? If I donated money to Assange DAO, I would have the right to mint his SubDID. When I have this SubDID, first of all, the name itself is available to use. Secondly, all the functions of the SubDID are intrinsically the same as the parent account, you can use the SubDID wherever you can use the parent account.

So, the SubDID name is useful in the first place. After you get this SubDID, you use it as a nickname, and you can directly demonstrate that you are a member of this DAO. Furthermore, you are actively promoting this DAO. This is a win-win.

And we can take celebrities as another example. We all know Jay Chou, Edison Chen, Shawn Yue have issued NFTs, but their NFTs invariably fell below the issue prices. Why?

Because people will, sooner or later, realize their NFTs have no practical value, they are just pictures at the end of the day. If their stories fail to entice, their NFTs are useless, and people are not stupid when they are required to pay.

So, let’s switch perspectives to re-think it. If someone like Jay Zhou, not necessarily Jay himself actually, could be the administrator of Jay’s Fan Community, or simply a promoter of Jay’s online fan group, he says, “Look, we now own Jay.bit, and we’ll allocate some SubDIDs of Jay.bit to you, so that in the future, whoever attends Jay’s musical concerts, or meets other fellows in offline meetings or parties, your SubDID will be your ticket, your pass.”

It sounds just right. This is a very practical scenario where SubDIDs can be popular among users.

Just imagine, as a fan of Jay Chou, if I had a web3 name that contained both my name and the name of my idol, Jay Zhou, I would be more than willing to use it. Because, this name/ID instantly makes me unique among my friends, and it allows me to stand out among Jay’s fans. This is my “social currency”.

Then, why would Jay or the Head of Jay’s fan club be willing to issue such SubDIDs?

It is important to note that SubDIDs are priced solely by the parent account. I believe that if you have been to our website, you should know that the SubDID is priced by the parent account, and the majority of the income of the SubDID also belongs to the parent account.

Therefore, for these superstars, IPs, brands, and their SubDID are regarded as a kind of accessory of their IP, a kind of “electronic accessories” that brings in annual income. As a parent account, he can decide the specific price of payment to use its SubDID.

If your IP is very popular, then perhaps you can charge $10,000 per year from the users, and if you just started to build your IP, maybe just a hobby group, then you may want to charge $1 a year. So for these scenarios, SubDIDs are also very useful.

In fact, in essence, SubDIDs are created for these existing groups with a common interest, no matter whether it is a DAO organization or a star’s fan group, they are all “a group of people with a common interest”. And we, .bit team, empower them and provide them with appropriate tools to solve their problems.

The aforementioned are some scenarios where SubDIDs can be applied in real life, which is why we have spent a lot of effort on SubDIDs.

Then, what exactly are we working on?

We are primarily working on how we can lower the cost of using SubDIDs.

You may have noticed that ENS has sub-domains recently, and no, we ARE NOT sub-domains. We have made it crystal clear from day one on our official website, “.bit is not a domain name, .bit is an account, it is your Web3.0 ID”. So, we call it a SubDID.

We focus our effort on reducing the cost of using SubDIDs. For example, if you are a parent account owner, you may want to ask, how much does it cost to create a SubDID? Our answer is 1 ckb. This is purely for avoiding dusting attacks.

And when you own this SubDID, you can also go in and add unlimited amounts of data, your address, etc, with no need to pay extra.

If we want more users to use our ID product (yes we do), we need to put ourselves in their shoes. In reality, users of this kind of identity product will consider the cost. So in this sense, .bit SubDIDs have a very solid cost advantage.

This cost advantage applies not only when you register a .bit account for the first time, but also when you use our accounts later on. It costs very little to own a .bit account/SubDID, and when you start using it, there’s no need to pay extra.

And we are also thinking, how can we appear to be not so similar to a domain? Or, how about we be more Web3.0?

You can see from our official website that our SubDIDs have two formats, # Format and Dot Format, and they are essentially the same account. You can see the examples below:

For instance, tim.qq.bit is a Dot Format, and this looks like a domain. But in the future of SubDID, we will mainly promote the format of #, in this case, qq#tim.bit.

Why?

If we look closely, every issued NFT has its unique number, its ID. You have seen numbers like punk#1988, and punk#1688 in OpenSea. And if .bit adopts this similar format with #, what does it mean for all?

For instance, if you own punk#1988, you then will get punk#1988.bit, that means your punk ID is your Web3 ID, with a simple .bit as a suffix. Simple as that.

So we believe, the # format is more in line with the mainstream preference of Web3.0 users. And of course, we also support Dot Format ;)

I want to throw these ideas of SubDID to all of you and hope this inspires your imagination, and I’m welcoming anyone to explore this concept and its possible applications with us together. You can also see many examples on our official website (https://www.did.id/SubDID ). I truly believe we can create some miracles with the idea of SubDID, and this is a top priority in my mind.

_

We have plans for the future, as you can see from our roadmap on our official website (just scroll down to the bottom). I’m attaching a screenshot of our Q2-Q4 priorities here:

The registration and transaction processes of .bit product are already very clear and mature for users. Then, how can we encourage more developers to work with us? How can we drastically reduce the cost for developers to integrate with us? The underlying cost includes a psychological barrier, technical barrier, etc. And we aim to reduce these barriers to provide easy access for more developers to integrate with us and build something wonderful together.

This is what our R&D team is working on.

NameDAO

Next, is a very important idea, something we will do our best to make happen. It is called NameDAO.

Some may think instantly, well they are doing this DAO, and I guess .bit will issue tokens?

We’ve been observing and thinking about DAO, and we believe some public property like .bit, we should let it belong to the community, where it can be directly managed. We’ve noticed that ENS or UniSwap issued “governance tokens” to tackle this problem, but is it the best way to do it? We think this is still worth exploring.

I shall dive directly into the topic of NameDAO. One question, what exactly belongs to a community? Or say, what can be truly owned by the community?

We have a better solution, and that’s NameDAO. 🎉

Then what exactly is NameDAO? For example, people speak different languages, and there are different characters from different languages, like Russian, Japanese, Korean, etc.

And users, like myself, may want to own different .bit accounts across different languages. For instance, if someone speaks Russian and English, and wants to register an English .bit account, then he may also wants to own a Russian .bit account, like любить.bit

We certainly want to encourage people to use different languages on Web3. And there are some rules to be set for this scenario, so we will devise something like “RussianDAO” / “РусскийDAO”.

Then how can someone be a member of RussianDAO?

There may be some simple rules, e.g. you yourself register some Russian .bit accounts, or you invite someone else to register some Russian .bit accounts, then when you meet certain criteria (details to be discussed), you can apply to mint a SubDID of Ru.bit, e.g. RU#001.bit, RU#002.bit. (p.s. RU is the abbr of Russian)

So, simply put, in order to be a member of a certain NameDAO, you will need to meet certain criteria and obey some rules, and these criteria and rules are open for discussion. We are excited to share these questions and possibilities for all of you to ponder.

Perhaps the easiest idea to start with is to invite someone to register Russian .bit accounts, then that qualifies you to mint a Ru.bit SubDID. And when you own a SubDID, you can vote, and you are a member of this DAO.

As we firmly believe in the spirit of DAO, we think, the owners of RussianDAO will get 50% of all the registration fees for .bit accounts using Russian characters. Strictly speaking, the RussianDAO owns 50% of relevant income related to using Russian characters. This applies to account registration, renews, account auctions, or even official secondary market transactions, etc. This is the right owned by this RussianDAO.

This echoes back to our application scenario of SubDIDs. You can use your SubDID, initiate proposals, and vote.

As we have mentioned before, this DAO owns 50% of relevant income, so members can propose doing anything, e.g. promoting Ru.bit, encouraging more Russian-speaking people to own Web3.0 ID, to do anything beneficial to this DAO, this community. Simply put, the better you promote your DAO, the better your income will be.

And this is not only for Russian-speaking individuals, each language character will have one unique NameDAO.

When this DAO starts, perhaps every SubDID owner gets one vote. But as it progresses, this DAO can decide for its own good. For instance, how to allocate the voting rights, how to decide who gets higher weight in voting, and whether some comparatively more valuable contribution can qualify a member to get higher weight in voting power and make him a more powerful member of this DAO. These possibilities are worth exploring.

The right to use 50% of relevant income belongs to this DAO, and .bit has no right to interfere with how to use DAO’s income.

.bit has no right to interfere with how members spend their DAO funds and has no right to manage either. We are only responsible for regularly synchronizing DAO’s income, to extract from the contract address to the multi-signature account of this DAO.

Another idea we can think about is that there should be some initial members for this DAO.

For instance, in order to own a SubDID of Ru.bit, then you should invite 10 Russian account registers to qualify you as a member of the RussianDAO. When the number of DAO members is less than 100 (or a certain number), members cannot vote, considering only a few members somehow disqualify the meaning of voting. Maybe when the number exceeds 100, members can start to vote.

To kick off this NameDAO initiative, our .bit team may consider injecting a certain amount of start-up fund, like $50,000–10,000, as the initial start-up capital to make the DAO up and running.

So, one of the underlying core principles of NameDAO is authorization. We want to authorize the right of governance and management to a group of unofficial team members outside of our .bit core team to run their DAO, in a decentralized autonomous manner.

Some other core principles of the relationship between .bit and NameDAO.

1. .bit makes sure 50% of the income will be transferred to the multi-signature account of this NameDAO.

2. .bit responds to NameDAO’s demands for products, infrastructure and regulations. For example, this RussianDAO may want to change prices for Russian .bit accounts.

3. .bit carries out executions, and NameDAO makes decisions.

And some other ideas around NameDAO.

1. Every language will have its own NameDAO.

2. No one can restrict a person from joining this DAO, and similarly, no one can restrict you from joining multiple DAOs.

3. All of DAO’s income is determined by all members of DAO.

So, these are what we’ve been brainstorming, starting from a small character to endless future possibilities. And we are also exploring how we can better empower communities in our ecosystem, how can we set DAO communities free and running in their own directions.

Welcome to comment and share your thoughts. Thank you.

226 days have passed since July 22th, 2021 when the first .bit account was registered. During these days, DAS has grown faster than we expected. More than 40 DApps have integrated with DAS; the number of registered .bit accounts has exceeded 60,000.

During these days, we never stop thinking about what kind of product we want DAS to be. And we think it’s necessary to share our thoughts with the community. So here we are, telling you guys exactly what DAS is by rebranding it as .bit.

Brand Upgrading

What’s new after brand upgrading:

• New official website and new account manager;

• New domain for official website: did.id;

• New brand name: .bit ; DAS is no longer used;

• New Github organization name and Twitter username: dotbitHQ.

.bit in our eyes

We want to emphasize some concepts about .bit:

1 .bit is NOT a domain.

.bit is a three-character suffix, which looks like .com/.net. Some people often refer to it as “.bit domain” or “the decentralized domain .bit”. But we need to clarify that it’s NOT an internet domain. It’s NOT our intention to improve the mature domain system we already have, though users can visit centralized websites deployed on IPFS through .bit.

2 .bit is a DID (Decentralized Identity).

DID is one of the key infrastructures of Web3.0. It’s essential for any identity system to have a set of globally-unique and human-readable identifiers. Think of the phone numbers, email addresses and Facebook accounts we have. But they are all centralized identity systems. .bit, a set of smart contracts on blockchains, however, is a decentralized system. On top of providing globally-unique and human-readable identifiers, .bit system allows anyone to register .bit accounts as their Web3.0 identities without a number limitation. The registration can be done WITHOUT permission, and the accounts can NOT be deleted by any third party. So we call .bit a DID (Decentralized Identity) system.

3 .bit is a self-sovereign data container.

You can think of your identities / accounts as data containers. Your Twitter account is your identity in this app, in which all of your data in Twitter is stored. In Web2.0, you have different accounts in different apps, which means your data is distributed. And the service providers can delete or temper your data at any time. You do NOT own your data.

.bit accounts are also data containers, where you can store any type of data. What makes it special is that apps can only read data from it. The only one who can manage the data inside is you yourself. To put it technically, .bit accounts is a Key-Value database. Any application has read access to it, but only the user has write access to it. So we call .bit a self-sovereign data container.

4 .bit serves the entire Web3.0 ecosystems rather than one specific public chain.

We have kept this key opinion the whole time that Web3.0 is much more than just blockchains, and the blockchain doesn’t just mean one specific public chain or EVM-compatible chains. The leading technical architecture of .bit system allows users to manage their accounts with any public chain private key (technically any asymmetric encryption private key). In other words, .bit is able to serve the entire Web3.0 ecosystems rather than one specific public chain. This is the key feature that distinguishes .bit from other naming systems such as ENS or Unstoppable Domains.

5 .bit is a community.

The core of .bit is a set of smart contracts. But the actual .bit is a community consisting of so many roles such as .bit team, registrars, marketplaces, data providers, app developers, end-users, etc. Today, this community has already taken shape and is constantly expanding.

It’s .bit community’s shared vision to help everyone take back their data sovereignty by providing them with their own DIDs. We hope the brand new official website and brand image will convey such vision.

Roadmap 2022

What we have achieved so far:

• integrated with public chains such as Ethereum, Tron, BSC, Polygon, Mixin;

• integrated with dozens of leading wallets such as TokenPocket, imToken, MathWallet, Huobi Wallet;

• integrated with more than 40 DApps such as Jike App, NFTGo, NFTSCAN, WePiggy;

• released .bit Alias;

• launched the marketplace for .bit;

• integrated with IPFS;

• cooperated with many third-party registrars;

• more than 60k registered accounts.

New functions and features that .bit aims to launch in 2022:

• Multi-chain: .bit will integrate with more popular public chains, including but not limited to EVM compatible chains, Bitcoin, Polkadot and Solana.

• Multi-language: .bit will support registration in any language.

• .bit Alias: Users can assign one .bit alias for each popular public chain contract address or ordinary address. This will effectively enhance the security in Web3.0.

• SubDID: A .bit account is able to create countless SubDIDs at a low cost. The decentralized and low-cost SubDIDs will serve as an efficient management tool for any kind of communities.

• Newly-designed .bit data management tool: Allow users to manage their data conveniently and efficiently. Also, developers can have write access to .bit if authorized by users.

• Establishing a system of registrars with global coverage.

• Release more accounts for registration. Release previously reserved accounts.

Release more accounts for registration

In consideration of fairness, only 35% of .bit accounts are randomly registrable for now. As .bit integrating with more DApps and .bit’s brand visibility enhancing, we think it’s time to release more accounts. With our brand upgrading, we hereby reveal the plan for accounts releasing.

Plan for accounts releasing:

2022–03–21 12:00PM(UTC+0), release to 40%；
2022–03–28 12:00PM(UTC+0), release to 45%；
2022–04–04 12:00PM(UTC+0), release to 50%；
2022–04–11 12:00PM(UTC+0), release to 55%；
2022–04–18 12:00PM(UTC+0), release to 60%；

Parameters for each release:

release to 40% = 1717986918
release to 45% = 1932735282
release to 50% = 2147483647
release to 55% = 2362232012
release to 60% = 2576980377

Code and parameters for releasing:
- Code of algorithm
parameters of algorithm

The rest 40% will be released gradually according to the number of owner addresses in the future.

Clarifications:

1. Like before, which account names are available is randomly decided by the name themselves. If you want to know whether your favored account name is registrable, you can get the answer by calculating with the above algorithm and parameters.

2. The registration is fair as the contract is impartial. The accounts that are not yet released for registration are not in the possession of or reserved for anyone in the .bit team. We promise that .bit team cannot register those accounts earlier than any other users. Not releasing all accounts does not help boosting the number of registration, but we still have to do it in pursuit of fairness. Learn more about fairness: https://talk.did.id/t/written-before-the-launch-of-das/334